On 08/20/2013 12:15 PM, Kris Borchers wrote:

As AeroGear.js gets larger and more complex, it makes sense to revisit our build strategy as well as our dependency management strategy since that affects the build.

I was thinking, and after discussing with Luke I believe he agrees, that we should investigate the use of AMD (Asynchronous Module Definition). What this provides for us is:

1. Better modularization between the pieces of code in AeroGear.js
2. Better dependency management by specifically defining those dependencies in each module
3. A better base for our custom build process

I think all of those reasons point to the need for this implementation. That being said, it doesn't come without a cost. We would need to reorganize the repo and modify each file to make it a proper AMD module. This will take time but I think it is time well spent.

I would be glad to hear if anyone has any thoughts or concerns around this.

Any recommended reading?

Sure. I would take a look at this. Hopefully that would give some insight into AMD. http://requirejs.org/docs/whyamd.html

What will the end user experience look like and how is it different than the way aerogear.js is used now?

End-user experience should not change unless they want it to. The custom builder would still give them the pieces they want via point-and-click or they can download the full build just like they can now. However, this would also offer another option in that people could include just the pieces of the library they want via require.js or similar build tools/processes.

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev