[dojo-contributors] Module formats for the browser

Bill Keese bill at dojotoolkit.org
Fri Mar 26 03:43:59 EDT 2010


And what does "sad panda" mean anyway?

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
>    


More information about the dojo-contributors mailing list