<story><title>CommonJS effort sets JavaScript on path for world domination</title><url>http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars</url></story><parent_chain><item><author>jerf</author><text>The biggest problem with &quot;Javascript on the server&quot; right now is that Javascript has no concurrency story whatsoever. You could easily hack in shared-state threading, but there would be no faster way to turn me off of Javascript forever than to do that. You could hack in message-passing, but it won&apos;t be clean and you&apos;re still going to have terrible fun trying to not pass mutable references, which, again, if you leave that in I will run screaming. STM isn&apos;t exactly going to be easy to stick in either.&lt;p&gt;(I say I will &quot;run screaming&quot; not merely because I don&apos;t want to deal with it, but because I don&apos;t want to deal with yet more libraries based on shared-state concurrency. No. I&apos;ve left that behind and I&apos;m not going back, and certainly not in a space where I&apos;ve got an abundance of languages to choose from.)&lt;p&gt;Without a solution to that problem, I see this as a terribly, terribly wrong move, and a terrible time for JS to try to be picking up the server. Servers are &lt;i&gt;in&lt;/i&gt; the multicore age and have been for a couple years now.&lt;p&gt;(And if your answer is &quot;well, we&apos;ll just keep all the tasks simple and we won&apos;t need multiple threads&quot;, I would remind you that you&apos;re running &lt;i&gt;on the server&lt;/i&gt;, which often needs to do, you know, &lt;i&gt;actual work&lt;/i&gt;. A language that can&apos;t do that may have a small niche, but it&apos;s going to be an uphill battle against entrenched competitors.)</text></item></parent_chain><comment><author>rictic</author><text>One solution that will almost certainly get implemented is WebWorkers.  From that you get string-only message passing (though it&apos;d obviously be easy to do json-encoding of data in messages) between js processes.&lt;p&gt;That, combined with event based non-blocking apis for managing multiple tasks neatly covers more or less everything you can do in many other mainstream languages like Python and Ruby (excluding some magic in native code extensions).</text></comment>
<story><title>CommonJS effort sets JavaScript on path for world domination</title><url>http://arstechnica.com/web/news/2009/12/commonjs-effort-sets-javascript-on-path-for-world-domination.ars</url></story><parent_chain><item><author>jerf</author><text>The biggest problem with &quot;Javascript on the server&quot; right now is that Javascript has no concurrency story whatsoever. You could easily hack in shared-state threading, but there would be no faster way to turn me off of Javascript forever than to do that. You could hack in message-passing, but it won&apos;t be clean and you&apos;re still going to have terrible fun trying to not pass mutable references, which, again, if you leave that in I will run screaming. STM isn&apos;t exactly going to be easy to stick in either.&lt;p&gt;(I say I will &quot;run screaming&quot; not merely because I don&apos;t want to deal with it, but because I don&apos;t want to deal with yet more libraries based on shared-state concurrency. No. I&apos;ve left that behind and I&apos;m not going back, and certainly not in a space where I&apos;ve got an abundance of languages to choose from.)&lt;p&gt;Without a solution to that problem, I see this as a terribly, terribly wrong move, and a terrible time for JS to try to be picking up the server. Servers are &lt;i&gt;in&lt;/i&gt; the multicore age and have been for a couple years now.&lt;p&gt;(And if your answer is &quot;well, we&apos;ll just keep all the tasks simple and we won&apos;t need multiple threads&quot;, I would remind you that you&apos;re running &lt;i&gt;on the server&lt;/i&gt;, which often needs to do, you know, &lt;i&gt;actual work&lt;/i&gt;. A language that can&apos;t do that may have a small niche, but it&apos;s going to be an uphill battle against entrenched competitors.)</text></item></parent_chain><comment><author>nkurz</author><text>What use cases are you envisioning where threading will be essential?  Or aiming in the opposite direction, what use cases are people envisioning for server-side Javascript at all?&lt;p&gt;I presume its anticipated niche is as a CGI-type replacement --- relatively light-weight &apos;programs&apos; executed per request.  If that&apos;s the case, is there much need for multithreading?</text></comment>