4 ms·
JSBuild ensures that CommonJS modules can be used in browser-based applications
JSBuild ensures that CommonJS modules can be used in browser-based applications (on the web) without any need of source code modification. It’s a new Python library and a command-line utility that builds specified CommonJS modules and packages by generating unobtrusive Javascript code.
- illumen 16y agoThis is the worst thing about CommonJS. By default, it can not work in browsers - the most common environment for javascript. You either need a special loader, or you need to package the code into a wrapper. The other bad part about it is that it is not async. Which means your code blocks whilst it loads. Loading code off a slow hard disk, or off the network? Blocked. I'm not sure why they have made these design decisions. CommonJS seems a step backwards to me.
- arthurschreiber 16y agoCommonJS also has async module specifications, see http://wiki.commonjs.org/wiki/Modules/Transport/D http://wiki.commonjs.org/wiki/Modules/Transport/D and/or http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition. And by using a loader (as you mentioned) these formats also work in browsers.
- diamondhead 16y agoThe only limitation with CommonJS' Modules spec is that we can't import CommonJS modules by writing script tags during development. On the other hand, CommonJS provides lazy evolution for web apps, with a great module mechanism design. BTW It's possible to load CommonJS code asynchronously by splitting your built code into separate parts. You may be interested at the other project I'm working on, named DOMLoader (http://github.com/azer/domloader http://github.com/azer/domloader) Regards
- tlrobinson 16y agoThere are a lot of misconceptions about CommonJS modules in the browser. You've touched on most of them. Of course you need a loader or packaging script, any module system that wants to handle dependencies will. Script tags are inadequate for anything except the simplest cases. You can load your modules asynchronously, even though the main "require()" API is synchronous. Simply load the modules and their dependencies up front before executing them. This is what we've been doing for years in the Objective-J loader, and several CommonJS browser loaders already do it. Also, I believe "require.async(id, callback)" is part of the spec now too, and they're working on an "async module definition" spec, which allows loading in script tags with minimal boilerplate ("require.def(id, function() { /module/ })")
- samstokes 16y agoCan anyone comment on how this compares to something like RequireJS? (http://requirejs.org/docs/why.html http://requirejs.org/docs/why.html)
- tlrobinson 16y agoI can't really tell how JSBuild works because the docs aren't very helpful and I don't feel like diving into the code right now, but I can tell you RequireJS only supports modules in one of the wrapped "transport" / "async module definition" formats, NOT all CommonJS modules. The author is very opinionated about this so I wouldn't expect that to change any time soon. Yabble does support unwrapped modules, so you might want to take a look at that: http://github.com/jbrantly/yabble http://github.com/jbrantly/yabble
- samstokes 16y agoThanks, I'll check out Yabble too.
- diamondhead 16y agoThe basic difference between JSBuild and the other alternatives is that JSBuild generates unobtrusive code for specified CommonJS packages or apps. You may check the "How It Works" section in thee user guide for details.
- chrislloyd 16y agoIf you are using CoffeeScript, I wrote a little tool which essentially does the same, but is much less complex (IMHO): http://github.com/chrislloyd/roast http://github.com/chrislloyd/roast When compiling all it does it does is inline the files you have requir'd.