JavaScript: It’s Not Just for Browsers Any More

For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front.

It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.

Here's Yegge on the topic:

http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

... 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.

Currently, JavaScript is the only thing I can actually convince customers to use in place of PHP, which has various weaknesses that make it a terrible choice for certain apps. The killer argument is that there are lots of people who already know JavaScript.

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)

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