&quot;<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">XHR+eval loading has<br>extra baggage, and frankly I believe CommonJS module format optimized<br>for the wrong things. The typing differences between the formats are<br>
not that great, particularly when considering the spent trying to<br>debug evaled code in the browser. Sure, not every developer needs to<br>do work in the browser, but many do, and having a consistent format<br>that works well across environments in the end is more important.&quot;</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><span class="Apple-style-span" style="font-size: 13px; "></span><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I would submit (having a lot of &quot;old&quot; experience on this one) that the needs of a server dev is not the same needs of a client dev.  Trying to meld the two is already leading to trouble (witness the traffic on these threads), and maybe...just maybe...having a single loader system for both is not such a good idea.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">It sounds to me like James is advocating a Linux-like package system (i.e. one shot, aimed at a developer with the tools needed to actually grab said package), and everyone else is remembering that (before loaders like Dojo, Closure, and LAB) you just needed to ask for the specific resource.  I can understand (and agree with) most of the stories told here, but the reality is that the higher the barrier to entry, the less people will work with the system in question, unless forced to.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I personally don&#39;t want to be associated with &quot;being forced to&quot;, so I&#39;d have to agree with Kris on this one, but I&#39;d suggest that maybe the whole package.json is not the answer either; elements of it might be.  Lots of good arguments on all sides, and I&#39;m enjoying the debate =)  In the end though, barrier-to-entry is key, and *any* tools that we require people to try to download and use are a barrier to entry, especially if the devs in question feel that they are forced to use said tools.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Dumb question: has anyone ever considered a server-side solution (not necessarily Rhino-based) that might collect a set of JS files from a development app (aka HTML file or whatever) and attempt to assemble a build based on that?  I threw that at Alex a long time ago, but it got lost in the noise.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Regards--</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Tom<br></span></font><br><div class="gmail_quote">On Tue, Aug 24, 2010 at 2:06 PM, James Burke <span dir="ltr">&lt;<a href="mailto:jburke@dojotoolkit.org">jburke@dojotoolkit.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Tue, Aug 24, 2010 at 11:44 AM, Eugene Lazutkin &lt;<a href="mailto:eugene@lazutkin.com">eugene@lazutkin.com</a>&gt; wrote:<br>

&gt; Hmm. Why? Censorship? ;-) Just by saying that you are cutting off users,<br>
&gt; who want to develop traditional CommonJS modules with Dojo. Is it really<br>
&gt; worth it?<br>
&gt;<br>
&gt; I suspect that if/when CommonJS goes to masses, the said masses would<br>
&gt; prefer a browser environment to debug modules --- mostly because of<br>
&gt; Firebug and other debugging tools already available and relatively<br>
&gt; mature. By cutting them off we serve them to our &quot;competitors&quot;. Even now<br>
&gt; there are several tools of different quality, which load regular<br>
&gt; CommonJS modules into browser.<br>
<br>
</div>Right, and all of those loaders are inferior. XHR+eval loading has<br>
extra baggage, and frankly I believe CommonJS module format optimized<br>
for the wrong things. The typing differences between the formats are<br>
not that great, particularly when considering the spent trying to<br>
debug evaled code in the browser. Sure, not every developer needs to<br>
do work in the browser, but many do, and having a consistent format<br>
that works well across environments in the end is more important. And<br>
the amount of typing is really not that much different. And for crying<br>
out loud, JavaScript started in the browser. Damn it. OK, flame off.<br>
<br>
In short, I am doing this package work because I believe the RequireJS<br>
syntax is better. I can reuse CommonJS modules but those modules are<br>
not as flexible or JavaScripty as RequireJS ones (setting exported<br>
value to a function is standard in RequireJS). By being able to reuse<br>
and transform CommonJS modules for a system that works well in the<br>
browser, I am making a bet that it will become the dominate syntax for<br>
modules.<br>
<br>
I appreciate though that it may ultimately end in failure, which is<br>
fine. I do not think it will be utter failure, it will just mean that<br>
CommonJS modules will always be something different, but the ability<br>
to transform CommonJS modules means that RequireJS-based projects can<br>
still thrive on their own. If CommonJS gets a standard way to set<br>
exports, there can be a tool to convert back to CommonJS format too.<br>
<br>
I can fully appreciate if the Dojo community does not want to come<br>
along for that ride. So feel free to disagree, so we can work out what<br>
is best for the Dojo folks.<br>
<div class="im"><br>
&gt; Somehow I missed app.js --- what is it? Could you give me a link so I<br>
&gt; can read up on it? Both links in your original email do not mention it,<br>
&gt; and I couldn&#39;t find any mention of it in this thread.<br>
<br>
</div>I keep thinking app.js, but I used main.js in the package writeup here:<br>
<div class="im"><a href="http://github.com/jrburke/requirejs/blob/master/docs/design/packages.md" target="_blank">http://github.com/jrburke/requirejs/blob/master/docs/design/packages.md</a><br>
<br>
</div>So please s/app.js/main.js/, sorry for mixing it up.<br>
<font color="#888888"><br>
James<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
</div></div></blockquote></div><br></div>