[dojo-contributors] Module formats for the browser

Eugene Lazutkin eugene at lazutkin.com
Fri Mar 26 03:28:10 EDT 2010

Heh. I read the CommonJS group daily and work with CommonJS code on a
daily basis. This is my impressions of the group:

1) They are kind of going in circles starting from full denial of
asynchronous module loading and coming back to it after several months.

2) There are some mysterious "specs" --- nobody knows who writes them,
how to write them, nobody votes on them, yet they are a major point of

3) Some "reference" code is produced for "specs", yet usually it goes
far beyond the "spec" making the "reference" code idea completely moot.

4) Still the ground is shaky even with "specs" and "reference" code. For
example, ".then()" has to go from Promises now 8-0:
http://groups.google.com/group/commonjs/msg/85cd98cc9748bfa4 --- let me
remind you that our Deferred/Promise hybrid is scheduled to be released
with 1.5 beta in less than 2 weeks.

5) Any kind of "reference" code is extremely wordy and is measured in
hundreds of lines --- who cares when you load this code locally in the
server? If you want to use it in a browser especially on a mobile
platform --- tough.

6) And of course there is a guy, who is an "expert" on everything
CommonJS, who makes final proclamations frequently using a language you
cannot understand without a non-free subscription to Merriam-Webster
Unabridged, and even after you got all 15 meanings of his word, it is
still unclear what he tried to say. Oh well. ;-)

7) In general the browser is not appreciated. The group pooh-pooh
realities of life that:

a) We (Dojo as well as any major JS client-side library) have much more
active users then all ServerJS platforms combined, and we cannot change
everything in one day without infuriating and alienating our users.

b) Our technical realities (asynchronous loading, expensive roundtrips,
expensive loading).

c) Our development culture (no servers without deep technical reasons,
just for the heck of it). Server-side guys already have a server by
definition, they can use it for some auxiliary needs. Client-side guys
usually are server-agnostic, and use a wide variety of web servers and
web applications --- the chances are we either have to provide proper
servers for 20 different platforms, or convince to install something
else == an extra bloat if you don't use it already. And at that point
Windows guys come and it all becomes really complicated to
provide/setup/support. (No, running a batch process with Rhino/1 jar
file is not the same as setting up and managing a server on different

And so on.

8) The whole idea of participating in the group actively seems
counter-productive to me --- I don't see much technical arguments or
discussions of statistically meaningful use cases, but a lot of ego
parading, and "I got it! Let's do it my way!". Hence the result --- a
lot of energy spent with a minimal useful outcome. But in general the
results are improving albeit very slowly.

Eugene Lazutkin

On 03/26/2010 12:56 AM, James Burke wrote:
> On Thu, Mar 25, 2010 at 8:44 PM, Ben Hockey <neonstalwart at gmail.com> wrote:
>> kris/james - is there anything we can do to work towards influencing
>> CommonJS in a way that would make the modules more suitable for the
>> browser or have they reached a critical mass in the direction they
>> have taken?
> I have tried participating, but I probably joined too late, and I
> think the mindset of the people in the group are more server based.
> And at this point I am concerned about coming off as a troll on their
> list. I do not agree with some base assumptions that drove their
> module spec, so it is really hard to be effective.
> So depending on your viewpoint, if you take the three CommonJS specs,
> the basic module one, the transport one and the require.async/ensure
> one, you could claim that CommonJS modules work in the browser, as
> long as you like running a server that can transform code for you. Or
> you like extra compile steps.
> James

More information about the dojo-contributors mailing list