[dojo-contributors] Module formats for the browser

Dylan Schiemann dylan at dojotoolkit.org
Fri Mar 26 06:08:52 EDT 2010

Hash: SHA1

I'd prefer we stay on topic, not get into the CommonJS politics, and let
Kris handle objections that are technical in nature, not based on a
dislike of the people or history of CommonJS.  Or I suggest
asking/answering the bigger question of "what do we want out of Dojo?"
and let that inform the decision process.

Kris believes in the value of leveraging CommonJS, in no small part
because he's been part of that process and working on the things he
believes we need in Dojo and Persevere.  That does not mean anyone else
from Dojo needs to participate actively in that group... let's use our
time and efforts wisely please.

- -Dylan

on 3/26/10 1:03 AM (GMT-07:00) Eugene Lazutkin said the following:
> On 03/26/2010 02:43 AM, Bill Keese wrote:
>> And what does "sad panda" mean anyway?
> I assume it is related somehow to "precluding promiscuously the
> perceived proclivity while preserving the permeated propensity"...
> Eugene
>> On 3/26/10 4:28 PM, Eugene Lazutkin wrote:
>>> 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
>>> reference.
>>> 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
>>> platforms).
>>> 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
>>> http://lazutkin.com/
>>> 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
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list