[dojo-contributors] Module formats for the browser

Eugene Lazutkin eugene at lazutkin.com
Fri Mar 26 02:20:08 EDT 2010


Inline.

On 03/25/2010 10:14 AM, Kris Zyp wrote:
> 
> So why would we use the CommonJS module format if it necessitates server
> side wrapping? I know there is extra burden for server side wrapping,
> but I believe there are several key reasons this is advantageous:
> * All Dojo modules can be CommonJS compliant modules, and easily be
> reused on any CommonJS platform.

While I am a vocal proponent of that, I have my doubts too. Let's define
two things you put in the bullet point:

"Any CommonJS platform" --- mostly "ServerJS". There are some
CommonJS-pseudo-compliant loaders and I work with one on a regular
basis, but it is mostly a rarity --- not many browser-based projects
even plan to use it.

And it sucks to run specialized server to load a project. The whole
logistic of it is screwed up: if you have several projects you work
frequently on you have to set up either several servers (e.g., started
manually when needed), or fiddle with a complex configurations of one
server responsible for doing all this. Personally I found it cumbersome
that Firefox security restrictions forced me to use a web server to
serve static files. The CommonJS support is much more than that.

To sum this point up: barriers of entry will be higher for Dojo. We can
pooh-pooh the necessity for a build for more-or-less realistic projects,
we can blame Firefox for the necessity of a web server, but this one
will be artificial "we designed stuff you cannot work on without a
server-side web application". Nevermind that it is a CommonJS thing ---
it will repel from Dojo (unless all our "would be competitors" do the same).

"All Dojo modules" --- how many Dojo modules are useful in "ServerJS"?
Not a lot. Dijits are gone, all UI/HTML/CSS code is gone too, all
graphics is gone. We have some language extensions, dojo.data, and some
math from DojoX. Is it really worth it to inconvenience everything else?
IMHO a conversion routine to CommonJS would be much more practical.

> * There is less boilerplate that has to be written (and maintained) by
> us as developers than the load-by-function approach.

Yes, any kind of server-side preprocessing makes sense only if it helps
to reduce the boilerplate. This part is true, but bear in mind that it
is not free.

> * Modules are decoupled from their namespace, making them much more
> portable.

This is another thing I am not convinced of.

1) Dojo modules are not decoupled, yet I never had problems/bugs with
this particular feature.

2) Working with CommonJS on daily basis I still need to figure out how
to load other modules. Their "decoupleness" is irrelevant for that. In
fact I already had a problem with this feature when module names in
different branches clashed and I loaded the wrong thing --- hilarity
ensues. Existing Dojo modules would throw an exception in such situations.

> Pseudo code for server side module wrapping:
> 
> var content = getFileContents(path);
> var depsObject = {};
> content.replace(/require\s*\(\s*['"]([^'"]*)['"]\s*\)/g, function(t,

Aren't you afraid that regex-based parsing can play hard-to-debug tricks
in some cases? And effectively it makes "require" a reserved word.

Eugene

> moduleId){
>   depsObject[moduleId] = true;
> });
> write("require.define({" + JSON.stringify(path.substring(0, path.length
> - 3)) + ":function(require, exports, module){");
> write(contents);
> var deps = [];
> for(var i in depsObject){
>   deps.push(i);
> }
> write("},[" + deps.join(",") + "])");
> 
> Thanks,
> Kris


More information about the dojo-contributors mailing list