I am under the same impression as Dustin: node is not very easy on windows.
Also, some (me, for example), find the Java dependency implied with Rhino +
Rhino's horrible performance relative to others even more obnoxious.
I hope that it is possible to build a win executable of the loader that can
ship as a self-contained unit. Also, as hot as node is, it will almost
certainly be on win sometime this year (there was a project to port to MSVC).
Bottom line: I agree/support with your approach, James.
fwiw, with bdBuild (https://github.com/altoviso/bdBuild) I've taken the
(https://github.com/altoviso/bdParse) which opens the possibility of doing
lots of very cool things that are hard or impossible to do by manipulating
AST's from other solutions. It is also very fast: bdBuild reads, parses,
resolves dependencies and has-optimizes dojo + dijit + a small app in about 5s
(freebsd on a vmare on kubuntu on old dual core laptop with 3G). Expect alpha
release/announce of this over the next week.
Re using a parser rather than using ASTs from other applications:
It's often hard to hook into the token stream (which usually discards
comments) and the AST often has more/less than you would like because that
tree is being built with a particular use case in mind. It's also often harder
interpreter) that does a great deal more than just generating an AST. All this
prohibits leveraging the parser to build "enhanced" ASTs to include things
like dojo's inline documentation. In fact, with a proper parser, the
documentation generation stuff could be easily rolled into the builder and we
could generate docs in less than 10s rather than taking 2.5 hours. We could
also roll things like Aptana help, code completion bundles, code browsers,
etc. Finally, the current build pragmas can be made safer/better when you
tokenize and parse the input rather than just using regexs.