<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 20, 2013, at 12:47 PM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/20/2013 12:15 PM, Kris Borchers
wrote:<br>
</div>
<blockquote cite="mid:07B9E42E-C4D5-4A49-863F-981037595CE1@redhat.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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.
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>Better modularization between the pieces of code in
AeroGear.js</li>
<li>Better dependency management by specifically defining
those dependencies in each module</li>
<li>A better base for our custom build process</li>
</ol>
<div><br>
</div>
</div>
<div>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.</div>
<div><br>
</div>
<div>I would be glad to hear if anyone has any thoughts or
concerns around this.</div>
</blockquote>
Any recommended reading?<br></div></blockquote><div><br></div>Sure. I would take a look at this. Hopefully that would give some insight into AMD. <a href="http://requirejs.org/docs/whyamd.html">http://requirejs.org/docs/whyamd.html</a></div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
What will the end user experience look like and how is it different
than the way aerogear.js is used now?<br></div></blockquote><div><br></div>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.<br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote cite="mid:07B9E42E-C4D5-4A49-863F-981037595CE1@redhat.com" type="cite">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev</blockquote></div><br></body></html>