[XD-1231] Investigate if we should use RequreJS with Angular Created: 14/Jan/14
Updated:
06/Feb/14 Resolved: 27/Jan/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Done
Spring XD
None
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Story
Mark Pollack
Complete
None
Not Specified
M6
Priority:
Assignee:
Votes:
Minor
Ilayaperumal Gopinathan
0
Not Specified
Not Specified
Develop basic build process, CI automation, and initial port to Angular of
Admin UI
6
Story Points:
Rank (Obsolete): 832
Sprint 21
Sprint:
Epic Link:
Comments
Comment by Eric Bottard [ 16/Jan/14 ]
I'm sorry I did not comment on this on the call, but was in the subway.
My gut feeling about this is that it is not worth the trouble:




it does add a certain amount of complexity
the admin app is certainly meant to be used "behind the firewall" and it can tolerate a
certain initial delay to load
so we'd rather go for the "concatenate and minimize everything" rather than the "smart"
approach
UNLESS we plan in adding a lot of javascript features (which may happen if we do
dataviz)
Anyway, exemples of this can be found eg here https://github.com/elsom25/angular-requirejshtml5boilerplate-seed/tree/master/app/js
Comment by Mark Pollack [ 16/Jan/14 ]
In terms of future work, we will quite likely have data visualization and some other stream
related features - also be grouped together with other spring projects that may have a UI. Excuse
my ignorance here, but i don't see how require.js excludes the "concat and min everything"
approach...
Comment by Eric Bottard [ 17/Jan/14 ]
The idea of require.js is that you split your dependencies and defer their loading until they're
needed (require handles the transitive knowledge of what is needed, etc). This is to minimize the
initial loading time (especially for internet facing home pages, etc), at the risk of having a net
total bandwidth usage that is superior to the some of the parts (but each bundle, especially the
first one you need, is far less than the total)
We're speaking here of a behind the firewall admin app. So while not antagonist to the
minimize and concatenate the libs that are used together, it is quite opposite to the brute
force approach of "concatenate everything"
Comment by Mark Pollack [ 17/Jan/14 ]
There is also the feature of 'not polluting the global namespace', which seems quite important as
the app gets bigger and more and more components come into play.
http://stackoverflow.com/questions/12022930/what-are-the-advantages-of-using-an-amd-likerequirejs-or-commonjs-modules-in-ja
Comment by Brian Cavalier [ 22/Jan/14 ]
IMHO, the real benefits of proper modules are about good software engineering:





clear definition of exported module APIs,
you get private module scoping for free,
dependencies are explicit rather than implicit (read: no polluted global namespace
spaghetti),
ability to run unit tests in node (read: fast unit testing!),
there's more
Async loading can be a speed benefit during dev time, but in reality, you're probably going to
build (concat & minify) your app for production whether you're using modules or not.
In the case of script tags, though, you have to manage the process by which you switch from
many script tags to one script tag in dev vs. production. That can be automated, but can have
version control implications. Cram and curl help you with that, since you only have 1 script tag
(for curl) in the first place (see spring.io). So your index.html doesn't have to change for dev or
production. If you're dynamically generating it, then you'd still have to have a switch whereby
you generate the multi-script-tag dev version or the one-script-tag production version.
Comment by Mark Pollack [ 24/Jan/14 ]
Thanks Brian, this video also helped a lot in my understanding http://www.youtube.com/watch?v=4yulGISBF8w
Comment by Brian Cavalier [ 06/Feb/14 ]
Thanks for the link, Mark, I hadn't seen that video before.
With all due respect to the presenter, though, I think there are some problems with the
information in the video. I do think using proper JS modules and Angular together is a great
idea. It solves a real problem since Angular doesn't provide any load time dependency
management.
However, I think the solution presented in the talk is overly complicated. There's absolutely no
need for headjs. Popular loaders like RequireJS and curl.js can already load non-modular
JavaScript. Using headjs to load RequireJS, which you then use to load modules is really just
adding extra unnecessary moving parts. I recommend just using RequireJS or curl.js, without
headjs.
Also, AMD isn't the only viable JavaScript module format. I've come to prefer the CommonJS
format. It requires no boilerplate (ie, there is no `define` wrapper), and imho, keeps your code
cleaner. curl.js can load CommonJS modules, but RequireJS currently cannot. It’s also the
native module format in Node, so CommonJS modules are easily reusable outside a browser.
For example, you can unit test them in Node. CommonJS is also closer to the coming
EcmaScript 6 module format.
John Hann and I have been looking at Angular and JavaScript modules a bit lately, and we have
some ideas about good patterns for using them together. We’d be happy to discuss, if you guys
are interested.
Comment by Mark Pollack [ 06/Feb/14 ]
Thanks for the feedback. If you can review how we are approaching things in the new code
base, that would be helpful. We need to settle on a pattern of usage very soon.
https://github.com/spring-projects/spring-xd/tree/master/spring-xd-ui
Generated at Fri Feb 05 12:36:52 UTC 2016 using JIRA 6.4.11#64026sha1:78f6ec473a3f058bd5d6c30e9319c7ab376bdb9c.