[dojo-contributors] Module formats for the browser

Ben Hockey neonstalwart at gmail.com
Thu Mar 25 23:44:11 EDT 2010


i am strongly in favor of having the benefits we would gain by  being  
compatible with CommonJS modules.  i would like to find a way to make  
it work.  i find it valuable to be able to use dojo from static files  
(no server-side processing needed) - imo the greatest value is the  
ease of starting to learn/use dojo.  i think one great solution James  
mentioned is to consider a tool to convert the RequireJS format to  
CommonJS.  basically, the 'raw' dojo code remains suitable for the  
browser and you do a build for the server.

since it's late i'm prone to ranting... and i just cut out a whole lot  
of stuff about how useful it would be for progressive enhancement if  
we could use dojox.dtl on both sides of the wire and parts of pintura/ 
perstore might also be a fit for the client - not sure just  
speculating.  anyway, if you want to hear more of that kind of stuff  
feel free to contact me directly and i'll rant for you personally.   
fair warning, you should also be prepared to hear about how it would  
be interesting to use the jsgi-like app/middleware style on the client  
to handle client-side "requests" generated via the url hash - probably  
and/or dojo.behavior (or similar - eg dojo.live).

another way for us to be compatible with CommonJS modules is if  
CommonJS modules became more suitable for the browser environment.   
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?

ben...


On Mar 25, 2010, at 7:53 PM, James Burke wrote:

> On 3/25/10 8:14 AM, Kris Zyp wrote:
>> This CommonJS module standard format is what I am recommending that  
>> we
>> use for Dojo source code.
>>
>> 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.
>>
>
> But the dojo user's modules may not be CommonJS-compliant. It feels  
> like
> we are setting up a "class" system where the user's modules are  
> inferior
> or require extra work to reuse. I think one of the powers of Dojo's
> codebase is that we use the same tools, the same widget base classes  
> as
> dojo users. Treating their code as "other" does not sit well with me.
> This also gets to my core beef with CommonJS modules:
>
> [start rant]
> I truly believe that CommonJS got the module format wrong. It was  
> wrong
> to treat the browser as an afterthought, and the async capabilities
> recently only help a little bit, and they are still second class.
>
> Functions as a module container fit with JavaScript. Returning a value
> from that function to define the module is also very JavaScripty. The
> exports thing to me is an eyesore, and it boggles my mind that setting
> the exported value was not allowed. Sure there is talk of it now, but
> the APIs for it seem goofy. If it started with a function wrapper, it
> would be a lot cleaner. I know there is a circular reference cost to
> return values, but that cost is very small and easy to work around.
> CommonJS will probably need a setExports at some point and so they  
> will
> have taken that circular reference cost too. The CommonJS format is
> trying to optimize the wrong things.
> [end rant]
>
>> * There is less boilerplate that has to be written (and maintained)  
>> by
>> us as developers than the load-by-function approach.
>>
>
> I believe this is a premature optimization, trying to avoid a function
> wrapper style for modules. At least in the browser. As soon as you  
> need
> to debug, any sort of advantage the non-wrapper solution might have  
> had
> will be eaten up dealing with setting up some sort of sync system that
> can work in an async environment.
>
> Plus, the module pattern in JS code (function(){}()); is very common.
> Given that it is in use, the extra stuff to define a module ends up  
> not
> being that much different. Functions are the natural module system in
> JavaScript. Trying to avoid them feels like trying to avoid the braces
> in JavaScript: that is just how the language worked out. Get used to  
> it.
>
>> * Modules are decoupled from their namespace, making them much more
>> portable.
>>
>
> I can see that renamespacing is a weakness of including module IDs in
> the definition. But we have had that issue in Dojo for a very long  
> time,
> and as I recall it is not onerous to correct. Measure the time needing
> to renamespace some code vs. setting up work for server transforms. I
> believe the work for renamespacing happens much fewer times, and can  
> be
> helped via tools.
>
> Don't get me wrong, I do see the need for module IDs in the format  
> as a
> weakness, but in the grand scheme of things, if it means direct
> debugging and use in the browser, that tradeoff is worth it.
>> Also, the server wrapping process is intentionally extremely simple  
>> and
>> I think could easily be ported to all the platforms we play on. The
>> module that is wrapped does not need to be internally modified at  
>> all. I
>> included the code for a very simple wrapping below. I also have a  
>> small
>> github project that demonstrates more advanced, full server side
>> dependency resolution (packaging multiple modules in one response)  
>> for
>> server side JavaScript servers [2].
>>
>
> It is awesome that you have a server side process, and I know Dustin  
> has
> worked on one before for existing Dojo code. They are definitely  
> nice to
> have, and we should support them, but the support should be  
> optional. We
> need something that works well with just files on disk because I  
> believe
> some mobile platforms server their HTML/JS/CSS like that.
>
> What I would rather see is that we develop our code via RequireJS, and
> we provide adapters that can convert CommonJS modules to RequireJS
> syntax (I have one now), and I really want to get RequireJS running on
> the server. It runs in Rhino now, I want to get a Node fork going at
> some point.
>
> Although I can see that using RequireJS in the server may be
> unrealistic. If that is the case, then perhaps provide some sort of
> adapter that can convert RequireJS formatted modules to the CommonJS
> format. It might be hard given that RequireJS allows setting the  
> export
> value, but maybe by the time we get there, the CommonJS module spec  
> will
> have finally allowed setting export values.
>
> This feedback is a bit strongly worded, and definitely not directed at
> you Kris. I admire the work you have done in the CommonJS group and
> trying to bridge the gaps. If the rest of the dojo contributors feel
> there is value in the CommonJS approach, I will understand and keep  
> out
> of the way for that. I am a bit surprised and disconcerted with myself
> that I feel so strongly about this, but I do. I do not want to code in
> the CommonJS format. It is inferior. I may have to just suck it up
> someday and get used to it, but I am not ready to do that now.
>
> 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