

JSBuild ensures that CommonJS modules can be used in browser-based applications  - diamondhead
http://github.com/azer/jsbuild
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
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.

~~~
tlrobinson
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_
/ })")

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

~~~
tlrobinson
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>

~~~
samstokes
Thanks, I'll check out Yabble too.

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

