Couple of things to think about here...<div><br></div><div>1.  I am *not* advocating that Dojo 2.0 be a browser-only toolkit.  If that were the case, I would have jumped on the feature detection bandwagon a while ago.</div>
<div>2.  I am also *not* saying that using a package format is a bad idea either, though I&#39;m still undecided on the way CommonJS has defined it.</div><div><br></div><div>What I *am* saying is that if there is to be packages, we *cannot* force people to download and use a tool just to get started with anything that is not &quot;in the box&quot; for Dojo 2.0.  If there&#39;s no alternate ways of setting up packages, such as easy manual setup, a web-based tool (i.e. zero-install), or any other methods (which I think is part of the point of this thread), then we lose.</div>
<div><br></div><div>We have to remember that we are not the only consumers of the toolkit, and more tools is not the answer to common problems that developers using DTK have.  I think the confusion surrounding the current build system--and the common answer we give to problems that say &quot;just do a build&quot;--is a perfect example of this.</div>
<div><br></div><div>If there is to be a package manager, that&#39;s fine.  At the same time, the submitted patch to allow a developer to load a package on the fly should be there...there&#39;s no reason why someone shouldn&#39;t be able to just get up-and-running without having to use an auxiliary set of tools to do so.  Javascript overall wins because all you really need is a browser, a text editor and (probably) a web server; the more tools we inject into that process, the more we place barriers in front of a typical developer to use what we&#39;ve written and I would submit that that is bad, bad, bad.</div>
<div><br></div><div>So to reiterate my point: any external/auxiliary tools that we may offer to aid in the development process *must* be optional; if possible, we should offer zero-install web-based tools that any developer can use easily.</div>
<div><br></div><div>Regards--</div><div>Tom<br><br><div class="gmail_quote">On Tue, Aug 24, 2010 at 8:48 PM, Eugene Lazutkin <span dir="ltr">&lt;<a href="mailto:eugene@lazutkin.com">eugene@lazutkin.com</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">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>Allow me to illustrate the James&#39; vision of the Dojo 2.0.<br>
<br>
Imagine that there a developer, let&#39;s call him Tom, who decided to<br>
produce a package, which can be used in browsers, and on other<br>
platforms. The example of such module can be something like<br>
dojox.collections, dojox.encoding, dojox.math, dojox.string, or any<br>
other generic things: json, xml, date, color utilities, or some generic<br>
language-specific stuff. So naturally Tom wants to cover a lot with<br>
less. And he thinks: &quot;Wait a second! I can develop a CommonJS package,<br>
so it can be used by server-side folks immediately, *and* I can import<br>
it as a RequireJS module later, to use in RequireJS-based frameworks,<br>
including Dojo 2.0!&quot; The decision is made and Tom faces a simple task<br>
- --- developing the package in question. Amazingly he cannot do it in the<br>
browser with Dojo 2.0, and he is forced to use any other CommonJS<br>
platform no matter how terrible it is. But he knows that if he needs to<br>
change anything, he works with one format: CommonJS. The rest is<br>
automatic due to the RequireJS&#39; importer (part of the package manager).<br>
<br>
Alternatively he develops everything with Dojo 2.0 and back-ports it  to<br>
CommonJS manually, which appears to be relatively simple. Now Tom<br>
supports two versions. Every time he makes a fix/enhancement in the<br>
master package, he has to back-port the change. If he found a<br>
platform-specific error, and forced to modify the CommonJS copy first,<br>
he&#39;ll have to propagate it forth too.<br>
<br>
See Tom run. To some other platform. From Dojo 2.0. Run, Tom, run!<br>
<br>
In this scenario I see Dojo an exclusively browser-based toolkit. I<br>
don&#39;t say it is bad, just that it contradicts our stated directions to<br>
establish Dojo as a multi-platform JavaScript toolkit. When I asked if<br>
we support anything outside of a browser in the Dojo 2.0 thread, we got<br>
3 votes for Yes (Adam, James, and I), 0 votes for No, and 0 for Maybe.<br>
It concerns me a lot.<br>
<br>
Cheers,<br>
<div class="im"><br>
Eugene Lazutkin<br>
<a href="http://lazutkin.com/" target="_blank">http://lazutkin.com/</a><br>
<br>
</div>PS: If somebody feels that my CommonJS story is incorrect, please tell<br>
me where I am wrong --- I hope it is all a misunderstanding, or I am<br>
missing something.<br>
<div><div></div><div class="h5"><br>
<br>
On 08/24/2010 02:58 PM, Tom Trenka wrote:<br>
&gt; &quot;XHR+eval loading has<br>
&gt; extra baggage, and frankly I believe CommonJS module format optimized<br>
&gt; for the wrong things. The typing differences between the formats are<br>
&gt; not that great, particularly when considering the spent trying to<br>
&gt; debug evaled code in the browser. Sure, not every developer needs to<br>
&gt; do work in the browser, but many do, and having a consistent format<br>
&gt; that works well across environments in the end is more important.&quot;<br>
&gt;<br>
&gt; I would submit (having a lot of &quot;old&quot; experience on this one) that the<br>
&gt; needs of a server dev is not the same needs of a client dev.  Trying to<br>
&gt; meld the two is already leading to trouble (witness the traffic on these<br>
&gt; threads), and maybe...just maybe...having a single loader system for<br>
&gt; both is not such a good idea.<br>
&gt;<br>
&gt; It sounds to me like James is advocating a Linux-like package system<br>
&gt; (i.e. one shot, aimed at a developer with the tools needed to actually<br>
&gt; grab said package), and everyone else is remembering that (before<br>
&gt; loaders like Dojo, Closure, and LAB) you just needed to ask for the<br>
&gt; specific resource.  I can understand (and agree with) most of the<br>
&gt; stories told here, but the reality is that the higher the barrier to<br>
&gt; entry, the less people will work with the system in question, unless<br>
&gt; forced to.<br>
&gt;<br>
&gt; I personally don&#39;t want to be associated with &quot;being forced to&quot;, so I&#39;d<br>
&gt; have to agree with Kris on this one, but I&#39;d suggest that maybe the<br>
&gt; whole package.json is not the answer either; elements of it might be.<br>
&gt;  Lots of good arguments on all sides, and I&#39;m enjoying the debate =)  In<br>
&gt; the end though, barrier-to-entry is key, and *any* tools that we require<br>
&gt; people to try to download and use are a barrier to entry, especially if<br>
&gt; the devs in question feel that they are forced to use said tools.<br>
&gt;<br>
&gt; Dumb question: has anyone ever considered a server-side solution (not<br>
&gt; necessarily Rhino-based) that might collect a set of JS files from a<br>
&gt; development app (aka HTML file or whatever) and attempt to assemble a<br>
&gt; build based on that?  I threw that at Alex a long time ago, but it got<br>
&gt; lost in the noise.<br>
&gt;<br>
&gt; Regards--<br>
&gt; Tom<br>
&gt;<br>
&gt; On Tue, Aug 24, 2010 at 2:06 PM, James Burke &lt;<a href="mailto:jburke@dojotoolkit.org">jburke@dojotoolkit.org</a><br>
</div></div><div class="im">&gt; &lt;mailto:<a href="mailto:jburke@dojotoolkit.org">jburke@dojotoolkit.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     On Tue, Aug 24, 2010 at 11:44 AM, Eugene Lazutkin<br>
</div><div><div></div><div class="h5">&gt;     &lt;<a href="mailto:eugene@lazutkin.com">eugene@lazutkin.com</a> &lt;mailto:<a href="mailto:eugene@lazutkin.com">eugene@lazutkin.com</a>&gt;&gt; wrote:<br>
&gt;     &gt; Hmm. Why? Censorship? ;-) Just by saying that you are cutting off<br>
&gt;     users,<br>
&gt;     &gt; who want to develop traditional CommonJS modules with Dojo. Is it<br>
&gt;     really<br>
&gt;     &gt; worth it?<br>
&gt;     &gt;<br>
&gt;     &gt; I suspect that if/when CommonJS goes to masses, the said masses would<br>
&gt;     &gt; prefer a browser environment to debug modules --- mostly because of<br>
&gt;     &gt; Firebug and other debugging tools already available and relatively<br>
&gt;     &gt; mature. By cutting them off we serve them to our &quot;competitors&quot;.<br>
&gt;     Even now<br>
&gt;     &gt; there are several tools of different quality, which load regular<br>
&gt;     &gt; CommonJS modules into browser.<br>
&gt;<br>
&gt;     Right, and all of those loaders are inferior. XHR+eval loading has<br>
&gt;     extra baggage, and frankly I believe CommonJS module format optimized<br>
&gt;     for the wrong things. The typing differences between the formats are<br>
&gt;     not that great, particularly when considering the spent trying to<br>
&gt;     debug evaled code in the browser. Sure, not every developer needs to<br>
&gt;     do work in the browser, but many do, and having a consistent format<br>
&gt;     that works well across environments in the end is more important. And<br>
&gt;     the amount of typing is really not that much different. And for crying<br>
&gt;     out loud, JavaScript started in the browser. Damn it. OK, flame off.<br>
&gt;<br>
&gt;     In short, I am doing this package work because I believe the RequireJS<br>
&gt;     syntax is better. I can reuse CommonJS modules but those modules are<br>
&gt;     not as flexible or JavaScripty as RequireJS ones (setting exported<br>
&gt;     value to a function is standard in RequireJS). By being able to reuse<br>
&gt;     and transform CommonJS modules for a system that works well in the<br>
&gt;     browser, I am making a bet that it will become the dominate syntax for<br>
&gt;     modules.<br>
&gt;<br>
&gt;     I appreciate though that it may ultimately end in failure, which is<br>
&gt;     fine. I do not think it will be utter failure, it will just mean that<br>
&gt;     CommonJS modules will always be something different, but the ability<br>
&gt;     to transform CommonJS modules means that RequireJS-based projects can<br>
&gt;     still thrive on their own. If CommonJS gets a standard way to set<br>
&gt;     exports, there can be a tool to convert back to CommonJS format too.<br>
&gt;<br>
&gt;     I can fully appreciate if the Dojo community does not want to come<br>
&gt;     along for that ride. So feel free to disagree, so we can work out what<br>
&gt;     is best for the Dojo folks.<br>
&gt;<br>
&gt;     &gt; Somehow I missed app.js --- what is it? Could you give me a link so I<br>
&gt;     &gt; can read up on it? Both links in your original email do not<br>
&gt;     mention it,<br>
&gt;     &gt; and I couldn&#39;t find any mention of it in this thread.<br>
&gt;<br>
&gt;     I keep thinking app.js, but I used main.js in the package writeup here:<br>
&gt;     <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>
&gt;<br>
&gt;     So please s/app.js/main.js/, sorry for mixing it up.<br>
&gt;<br>
&gt;     James<br>
&gt;     _______________________________________________<br>
&gt;     dojo-contributors mailing list<br>
&gt;     <a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
</div></div>&gt;     &lt;mailto:<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a>&gt;<br>
<div class="im">&gt;     <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dojo-contributors mailing list<br>
&gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
&gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
</div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<div class="im">Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
</div>iEYEARECAAYFAkx0dmkACgkQY214tZwSfCt4iACgwDnJYApO+WMksO+p1FUvNsZh<br>
ko4Anj4XWsTOMIB1dOkXZkwPZ2FVA2h/<br>
=aG9k<br>
-----END PGP SIGNATURE-----<br>
<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>