
JavaScript: It’s Not Just for Browsers Any More - hugs
http://pragprog.com/magazines/2010-03/javascript-its-not-just-for-browsers-any-more
======
Ygor
Why do we want javascript on the server side, when we already have so many
other options?

I'm not trying to imply something against this aproach, this really is a
question.

~~~
mechanical_fish
Here's Yegge on the topic:

[http://steve-yegge.blogspot.com/2007/02/next-big-
language.ht...](http://steve-yegge.blogspot.com/2007/02/next-big-
language.html)

... though he doesn't explicitly _say_ he's talking about Javascript, it's
pretty likely that he's talking about Javascript.

1) It's got C-like syntax.

2) It's got the dynamic- and functional-language features that make people
happy.

3) We're stuck with it no matter what. Changing the world's installed base of
web browsers takes about a decade; such is the lesson of IE6. The only
universally-supported client-side language on web browsers is Javascript. Its
successor, should it exist, hasn't even been sighted on the horizon. [1] So
we're in for at least another decade in which every web developer needs to
know Javascript.

4) Because of #3, lots of folks are working to make Javascript fast and
reliable. There are several JS interpreter projects in active competition.
That kind of focus has already paid off in spades, and is going to pay off
even more over time. Those of us who remember the days when Java was
considered painfully slow, to the point where people complained about how
_crippled_ it was, understand what happens when the bulk of the world's
compiler wizards spend a decade optimizing a language's runtime: It tends to
become better. _Much_ better.

\---

[1] The only serious challenger, Flash, is not only proprietary, widely
loathed, suffering from a PR slump, and under direct attack from Apple but is
also... based on ECMAscript, a.k.a. Javascript. Or so I understand. So it's
more of an alternative runtime than a real alternative language.

~~~
imd
ActionScript may be based on ECMAScript, but they look very different:

    
    
      package com.example
      {
          import flash.text.TextField;
          import flash.display.Sprite;
    
          public class Greeter extends Sprite
          {
              public function Greeter()
              {
                  var txtHello:TextField = new TextField();
                  txtHello.text = "Hello World";
                  addChild(txtHello);
              }
          }
      }
    

Also, Flash is more than ActionScript.

~~~
gb
The difference in appearence is because it's based on what was going to be
ES4, you can actually write it like Javascript for the most part if you want
to.

------
27182818284
I have to thank jQuery. Honestly, before jQuery I didn't give Javascript the
time of day let alone imagine non-browser uses for it. I have coworkers that
are in the same boat; It makes me wonder how many people gave JS a second
chance primarily because of jQuery.

edit: It also makes me wonder how many people would give lisp, basic, and etc
a second chance if those languages had the equivalent of "Wow" that jQuery
provided to JS for me and others.

------
scotty79
If I have:

do_thing_A_and_after_that_call(function() {
do_thing_B_and_after_that_call(something); }

do_thing_C_and_after_that_call(function() {
do_thing_D_and_after_that_call(something); }

what should I do to execute some E after both B and D is finished?

I think that non-blocking effectively means introducing easy syntax for
parallel execution while complicating syntax for sequential execution.

I think parallel and sequential execution should be easy: on T1 and T2 do E
where T1 = (A; B), T2 = (C; D)

~~~
Periodic
If A, B, C, and D truly are asynchronous then I believe you're going to need
condition variables and (at a lower level) locks. I agree that such syntax
should be baked in and handled at a lower level.

If you can guarantee that a given variable can only be modified by one process
at a time, it is easy to do something to take care of this for individual
processes, and wouldn't be hard to generalize.

(note, I was last using prototype.js, and my javascript is a bit rusty)

    
    
        wait_list = [];
    
        function wait_for(entry) {
            wait_list.push(entry);
        };
    
        function done(entry) {
            wait_list.splice(wait_list.indexOf(entry), 1);
            
            if (wait_list.length == 0) {
                do_C();
            }
        };
    
        function do_A () {
            wait_for("A");
            // do stuff
            done("A");
        };
        function do_B () {
            wait_for("B");
            // do stuff
            done("B");
        };
    
        function do_C () {
            // Stuff that comes after A and B
        };

~~~
rictic
Nope, no locks needed in Node. This is one of the little joys of javascript:
no threading at all. None. With Web Workers you can have processes, but there
isn't shared state; everything is done through message passing.

All parallelism is cooperative in javascript, meaning that you don't have to
worry about control flow switching out from under you at arbitrary points,
just when you explicitly yield it by returning from an event handler or from
the top level of your program.

Finally, to answer the grandparent question, the easiest answer is a promise
group. A promise group is basically a promise that emits a success event once
all of its child promises have emitted success events. There are a few
implementations floating around, though it's just a handful of lines of code
to write and makes for a good exercise.

So assuming that A and B are rewritten to return promises (or wrapped, I
believe that isaacs has a library which will wrap functions which take a
callback to return a promise instead), you can do the following:

    
    
        var promise_a = do_A();
        promise_a.onSuccess(do_C);
        var promise_b = do_B();
        promise_b.onSuccess(do_D);
    
        var promise_group = new PromiseGroup([promise_a, promise_b]);
        promise_group.onSuccess(do_E);

~~~
scotty79
> Finally, to answer the grandparent question

I don't event have a kid! ;-)

Thank you, that was the thing I was looking for. My question now: What happens
if one of the promises fails? Is a promise group disposed then? Solution
offered by Periodic would wait forever.

~~~
simonw
It depends on the promise library implementation - most will let you specify
an "errback" (like a callback, but called if there is an error) and will
trigger that if any of their children fail. Alternatively, some may let you
specify a timeout and call your errback if that time elapses without all of
the children finishing.

------
zokier
OpenJS-project <[http://www.openjs.org/>](http://www.openjs.org/>); might be
of interest to HN peeps too.

------
fizx
node.js + coffeescript is the new sexy! It's going to kill my weekend :)

~~~
hugs
Agreed! (It's already killed a few weekends for me. :-) CoffeeScript has "Most
Favored Executable" status in my terminal window these days. On a related
side-note... here's the "Hello World" Node.js web server ported to
CoffeeScript: [http://github.com/jashkenas/coffee-
script/blob/master/exampl...](http://github.com/jashkenas/coffee-
script/blob/master/examples/web_server.coffee)

------
matthijs
We're using node for increasingly more projects. It's much easier to create
rather complex projects that would take way more time to create when we'd use
other languages.

For example a simple comet style notification system can be created less than
100 lines of code.

------
asolove
Hot code loading in NodeJS has been implemented many times, see e.g.:
[http://romeda.org/blog/2010/01/hot-code-loading-in-
nodejs.ht...](http://romeda.org/blog/2010/01/hot-code-loading-in-nodejs.html)

~~~
hugs
Thanks for the link. I think, though, auto-restart is a nice little feature
that's important enough that it should be baked-in by default. I just take it
for granted that's it already there in other frameworks.

------
scotty79
How do you break Node.js? And if you break it how much it is broken?

With mod_php even if you kill or freeze single apache process your app is
still up and running for other users. What happens if Node.js crashes or
hoards resources?

~~~
simonw
Off the top of my head: run several Node instances (one per core would
maximise potential performance) and load balance between them. Have the load
balancer / some other monitoring script periodically check each instance to
see if it's hung and remove from load balancer, kill and restart it when that
happens.

------
mark_l_watson
Last night I watched most of Ryan Dahl's 1 hour video on Node, built it, and
played with a few examples. I must admit that I like it much more than I
thought that I would. The video is good (but too long) for understanding the
motivation of event oriented processing, but if you are short on time, just
spending a few minutes building Node and running some examples is informative.

------
garply
Security issues aside, I'd be more interested in a browser that supported a
more powerful javascript than another language I can run on my server.

------
erlanger
This is a couple months late but nails it. NodeJS was the spark to the
powderkeg.

    
    
      > During development, one small, yet important, feature that Node lacks is the
      > ability to auto-restart when a change is made to the server’s source code.
    

Hm...sounds like a good application for Node's file-watching capability, so I
don't see why this needs to be built-in. Start your app indirectly with a
script that monitors the source files.

------
sabat
Strangely enough, Netscape Corporation once marketed javascript as a
lightweight server-side language. IIRC the browser-side javascript thing was
an afterthought.

~~~
btilly
You are right that Netscape used JavaScript as a lightweight server-side
language. However my memory from the times is that JavaScript was invented for
the browser and then ported to the server.

~~~
rapind
I think it was called LiveScript. I'm pretty sure it came along after
JavaScript as part of Netscape enterprise server or something (kind of like a
coldfusion)

~~~
btilly
LiveScript is what they called JavaScript before the Sun deal involving Java.
See <http://en.wikipedia.org/wiki/JavaScript#History> for more.

------
voodootikigod
JSConf FTW!

