JSBuild ensures that CommonJS modules can be used in browser-based applications | Hacker News Reader

JSBuild ensures that CommonJS modules can be used in browser-based applications

github.com

15 points_mnjb9 comments

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.

Open articleView on HN

This 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.

CommonJS also has async module specifications, see http://wiki.commonjs.org/wiki/Modules/Transport/D and/or http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition.

And by using a loader (as you mentioned) these formats also work in browsers.

The 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)

Regards

There 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/ })")

Can anyone comment on how this compares to something like RequireJS? (http://requirejs.org/docs/why.html)

I 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

Thanks, I'll check out Yabble too.

The 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.

If 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

When compiling all it does it does is inline the files you have requir'd.

Reply on news.ycombinator.com