[dojo-contributors] Module formats for the browser

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

Hash: SHA1

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


> 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
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list