<story><title>JavaScript: It’s Not Just for Browsers Any More</title><url>http://pragprog.com/magazines/2010-03/javascript-its-not-just-for-browsers-any-more</url></story><parent_chain><item><author>jerf</author><text>I&apos;m really at a loss as to how people seem to just swallow this claim without question. What&apos;s so special about Javascript&apos;s closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What&apos;s Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang?&lt;p&gt;&lt;i&gt;Most&lt;/i&gt; languages used in web development have closures. A large number of them have event-based frameworks. I found quite a few other candidates poking around in the other languages but lacked the skills or time to evaluate whether they were also structured like Node.js.&lt;p&gt;I don&apos;t mind the existence of Node.js, but the people claiming it&apos;s &quot;better than most&quot; make me wonder if they&apos;ve ever used the &quot;most&quot; they claim it&apos;s better than. Erlang in particular. &lt;i&gt;That&apos;s&lt;/i&gt; something that&apos;s &quot;better at the event-driven paradigm than most&quot;. Javascript has nothing on Erlang, Javascript&apos;s just another C-derived manually-chop-your-code-up-to-work-with-callbacks monstrosity by comparison.&lt;p&gt;Edit: No, if I were going to pitch Node.js, I would pitch it as &quot;Use the same language on both the client and the server; it&apos;s adequate on the client, it&apos;s adequate on the server.&quot; OK, &quot;adequate&quot; isn&apos;t the best pitch but it&apos;s honest. The stupidest thing about web development today is needing to know three languages (HTML + browser quirks counts as roughly as complex as a language, client-side JS, server side not-Javascript language) just to get your foot in the door. Having the same language on client and server will probably provide some interesting capabilities, such as the thing mentioned in another comment where your comment formatting code can be run in either place (show on the client &lt;i&gt;exactly&lt;/i&gt; what they&apos;ll get if they submit, run on the server to validate it), or validation code that is guaranteed identical on both client and server, or several other interesting things I can imagine where you can play games with exactly where something is run. Server-side Javascript just shouldn&apos;t be pitched as a &quot;uniquely capable&quot; language in a field full of PHP, Perl, Python, and Ruby... &quot;uniquely capable&quot; is Erlang or a the Seaside framework, not Yet Another (Dynamic) Algol Variant.</text></item><item><author>IgorPartola</author><text>It&apos;s a nice clean language that fits the event-driven paradigm better than most. When every function is an automatic closure, things are much easier.</text></item><item><author>Ygor</author><text>Why do we want javascript on the server side, when we already have so many other options?&lt;p&gt;I&apos;m not trying to imply something against this aproach, this really is a question.</text></item></parent_chain><comment><author>ryah</author><text>Something that&apos;s different, at least from POE, EventMachine, Twisted is that it is attempting non-blocking purity. You can snub your nose at this but it turns out to be very important. It ends up abstracting away a problem in a way that EventMachine or Twisted will never be able to do simply because of the existence of massive amounts of blocking Ruby and Python libraries. The programmer simply doesn&apos;t have to know what non-blocking I/O is - they don&apos;t have to know that if they do &quot;node script.js &amp;#60; hugefile&quot; - that STDIN_FILENO cannot be selected on.&lt;p&gt;Erlang is different. Node presents a different programming model than Erlang - Node handles thousands of connections per process - and keeps itself close to the metal. Erlang is it&apos;s own operating system handling one connection per processes but allowing very many processes. Is Node&apos;s model better? Well at the moment it&apos;s incomparable since Erlang is very much a solid, production ready system and Node is not more than some dude&apos;s hack. But supposing that Node becomes stable and usable at some point, a major advantage of the Node model is that for the first 10,000-1,000,000 concurrent connections the programmer doesn&apos;t have to know anything about concurrency - a single process will just handle it. There is no forking or IPC - it&apos;s just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core.&lt;p&gt;I also wish for less hype around the Node project but I think you&apos;re short changing it by saying it&apos;s same thing as Twisted but in Javascript instead of Python. The main selling point is &lt;i&gt;not&lt;/i&gt; that you can run the same code on browser and server. The main selling point is that you don&apos;t have to know what you&apos;re doing, at least for the first 10,000 concurrent connections.</text></comment>
<story><title>JavaScript: It’s Not Just for Browsers Any More</title><url>http://pragprog.com/magazines/2010-03/javascript-its-not-just-for-browsers-any-more</url></story><parent_chain><item><author>jerf</author><text>I&apos;m really at a loss as to how people seem to just swallow this claim without question. What&apos;s so special about Javascript&apos;s closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What&apos;s Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang?&lt;p&gt;&lt;i&gt;Most&lt;/i&gt; languages used in web development have closures. A large number of them have event-based frameworks. I found quite a few other candidates poking around in the other languages but lacked the skills or time to evaluate whether they were also structured like Node.js.&lt;p&gt;I don&apos;t mind the existence of Node.js, but the people claiming it&apos;s &quot;better than most&quot; make me wonder if they&apos;ve ever used the &quot;most&quot; they claim it&apos;s better than. Erlang in particular. &lt;i&gt;That&apos;s&lt;/i&gt; something that&apos;s &quot;better at the event-driven paradigm than most&quot;. Javascript has nothing on Erlang, Javascript&apos;s just another C-derived manually-chop-your-code-up-to-work-with-callbacks monstrosity by comparison.&lt;p&gt;Edit: No, if I were going to pitch Node.js, I would pitch it as &quot;Use the same language on both the client and the server; it&apos;s adequate on the client, it&apos;s adequate on the server.&quot; OK, &quot;adequate&quot; isn&apos;t the best pitch but it&apos;s honest. The stupidest thing about web development today is needing to know three languages (HTML + browser quirks counts as roughly as complex as a language, client-side JS, server side not-Javascript language) just to get your foot in the door. Having the same language on client and server will probably provide some interesting capabilities, such as the thing mentioned in another comment where your comment formatting code can be run in either place (show on the client &lt;i&gt;exactly&lt;/i&gt; what they&apos;ll get if they submit, run on the server to validate it), or validation code that is guaranteed identical on both client and server, or several other interesting things I can imagine where you can play games with exactly where something is run. Server-side Javascript just shouldn&apos;t be pitched as a &quot;uniquely capable&quot; language in a field full of PHP, Perl, Python, and Ruby... &quot;uniquely capable&quot; is Erlang or a the Seaside framework, not Yet Another (Dynamic) Algol Variant.</text></item><item><author>IgorPartola</author><text>It&apos;s a nice clean language that fits the event-driven paradigm better than most. When every function is an automatic closure, things are much easier.</text></item><item><author>Ygor</author><text>Why do we want javascript on the server side, when we already have so many other options?&lt;p&gt;I&apos;m not trying to imply something against this aproach, this really is a question.</text></item></parent_chain><comment><author>silentbicycle</author><text>Yeah, Lua and Erlang in particular seem better suited to this role. Erlang&apos;s whole model is fundamentally event-driven, and Lua is remarkably similar to Javascript, only without the design errors made permanent, and with a better JIT compiler.&lt;p&gt;Javascript&apos;s already closely tied to the web, though, and it gets plenty of word-of-mouth since web developers already know it. That will probably beat any technical advantage.</text></comment>