

The Node Ahead: JavaScript leaps from browser into future - gustaf
http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of_node_dot_js/

======
jimmyjazz14
Node is really good, until it's not.

I've actually spent a lot of time with Node since the company I work for was
an early adopter. This all based on opinion but, my general feeling about Node
is that the underlying concept is great but, Javascript is an awful language
to do it all in. The lack of real support for continuations (and/or
coroutines) means there is no escape from the callback hell and tracking down
errors can be a real nightmare. Ultimately for simple projects Node works fine
but reach a point where your application becomes at all complex and things can
get hairy real fast (of course this statement could be made about client side
Javascript as well).

I say this not to discourage anyone from trying Node because for many projects
Node may be just what you need but, there are some downsides one should
probably keep in mind.

~~~
dpritchett
After reading your post I struggled to decide whether I truly believed that
coroutines were better than callbacks. This HN thread provided some useful
discussion for me: <http://news.ycombinator.com/item?id=1549168>

I still don't know enough to take sides, but the thread I just linked helped
me to better understand the issue.

~~~
jimmyjazz14
I don't think one really needs to take sides one simply needs to know their
tools and know that they can be dangerous if not used properly. Both sides of
the coin have merits. Personal I am a big Haskell user so my views on IO
should probably be disregarded.

~~~
pjscott
On the contrary, as a Haskell user your views on IO should be kept in a thunk
waiting for evaluation if they're ever needed. Unless you're one of those guys
who've figured out how to do iteratee IO, in which case I tip my hat to you.

------
SandB0x
One page version:
[http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of...](http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of_node_dot_js/print.html)

------
chapel
Although the ideas and technology behind node.js aren't entirely new, the
fusion of a well known client side language like Javascript and a robust
server-side event based architecture really makes node.js great.

I really enjoyed the article because it approached node.js as it should have,
as the new way of doing things on the server. I see node.js becoming as
ubiquitous as ruby/python/perl are on the server (maybe even for desktop
applications).

Even if node.js doesn't become as big as I think it will, I feel that the
shift is has helped cause is a positive one for the server space and we will
all benefit from it.

------
gustaf
If you're into Node.js and Redis we (Voxer) are actually hiring engineers.
We're building a Walkie Talkie for iPhone and Android. In more technical terms
Voxer is a low latency messaging system for voice, images, and text. We have
an iOS client in the App Store, and an Android version is in the works. We've
had explosive growth in the last couple of weeks and are now in top 25 in a
bunch of app stores and we are looking for someone to help us develop the
server side components and make the system scale.

Email me gustaf@voxer.com if you want to know more and I'll connect you with
the right person.

Our servers are built out of Node.js, CouchDB, and Redis. If you are excited
about node, server-side JavaScript, and new databases, this is an opportunity
to work on this technology full-time.

~~~
younata
any intern possibilities?

~~~
gustaf
yes, send me an email gustaf@voxer.com

------
lalc
This is going to provoke massive eyerolling over at the Erlang industry.

~~~
JonnieCache
Somehow I don't think rolling their eyes at developers discovering a need for
what they have to offer will do the Erlang community any good.

If they sincerely believe that Erlang offers a superior alternative to Node
for what the influx of new Node developers need, then they should be looking
to provide resources to help these devs "graduate" to erlang.

Not once have I seen a blog post saying "Like Node.js? Then you're going to
love Erlang! Let me show you why it's better, with some snippets to compare
and contrast."

~~~
lalc
Oh, I agree. Every time someone advocates Erlang they mention how it was used
to build super-reliable telecoms and they start mentioning three-letter
acronyms and immediately everyone's eyes glaze over. It just isn't sexy like
node (yet?).

~~~
drdaeman
There are always Efene and Reia if you want sexy things. (However, I find it
somehow disturbing that there are almost no documentation on Reia beyond the
examples on its site's start page.)

One could compare Node.js to Twisted, Tornado or EventMachine. However,
comparing Erlang to Node.js is somehow weird as they have different paradigms
— Erlang is highly-concurrent with its "green" processes, while Node is
single-process single-thread with "asynchronous" paradigm.

(However, there are some aspects, that could be compared. Erlang has "let it
crash" motto, while in Node.js one has to be careful with any exceptions.
Erlang is distributed and Node.js has no notion of processes.)

------
Legion
Was the problem really that Python was slow, or did they not discover event-
driven until finding Node?

~~~
pohl
Just as this story came up I was watching the video of Ryan Dahl explaining
Node.js (someone had shared this link in the recent thread about the event
loop)

    
    
        http://developer.yahoo.com/yui/theater/video.php?v=dahl-node
    

In it, Ryan makes an important point about JavaScript being a natural fit
because it was designed for a constrained environment. In particular, there is
no way of doing I/O in JavaScript's traditional browser environment without
providing a callback argument (I'm not counting interacting with the DOM as
I/O here, and a couple of pedantic exceptions pointed out by judofyr below),
and for the way in which the browser guarantees that only one callback will be
executed at a time.

I think this idea of a constrained environment is very important. If blocking
I/O functions are strewn about the APIs you have at your disposal, then
programmers tend to default to using them.

The other point he makes is that often evented APIs are just missing from the
underlying platform. Does every way of doing some sort of I/O in the universe
of Python APIs have variants that take callback arguments? Even if the answer
is 'yes' (which would surprise me) there is a minefield of blocking calls one
would need to avoid in a disciplined manner.

...which may not be easy. Tell me: does myAwesomeFunction() do some blocking
I/O under the hood? You can't tell from the name. Do the docs always make that
clear, and provide an alternative with a callback?

 _Edited to include judofyr's exceptions — which bolster rather than undermine
the point, because note that window.prompt's raison de'etre is to block for
user interaction, and document.write is a RAM operation rather than disk or
network I/O._

~~~
judofyr

        There is no way of doing I/O in JavaScript's traditional browser environment
        without providing a callback argument.
    

What about `window.prompt`? Or `document.write`?

~~~
randylahey
I would hardly call window.prompt and document.write i/o since they never hit
disk or network (to over-simplify). They're more like manipulating an object
in memory.

For real i/o in JavaScript, look at AJAX: Callback based.

~~~
Ramone
Conversely, some might say that input from the user and output to the user are
really the only important i/o.

------
drdaeman
Not too long ago I've written some simple CAPTCHA service with Node.js, node-
redis and node-canvas. It was a simple application that generated a word from
a specific grammar, saved it to Redis for further reference and returned a
PNG.

While being ridiculously fast it leaked memory like crazy. So I've found that
there were almost no debugging tools (except for old good gdb) to find out
what was going on. (I've heard that there are some changes like `node debug`,
though. Should dig the archives and try code with latest Node version.)

I believe this was an inherent consequence of JavaScript and V8 being tailored
to short-lifetime (milliseconds of DOM operations, then lazy waiting for
events to fire) applications with low amount of events (user in-browser
activity).

~~~
jrockway
_I believe this was an inherent consequence of JavaScript and V8 being
tailored to short-lifetime (milliseconds of DOM operations, then lazy waiting
for events to fire) applications with low amount of events (user in-browser
activity)._

Nope, it's just bugs. Every programming language has memory-related bugs...
just less of them as they get older.

------
mcantelon
>We're still a long way from a 1.0 release. Version 0.4 arrived just last
month.

If memory serves, 1.0 is not so far way... half a year? When node hits 1.0 and
there is a perception of API stability, third-party development will likely
explode.

~~~
dennyferra
And there's plenty of third-party development already happening:

<https://github.com/joyent/node/wiki/modules>

------
bnchdrff
The author coined "developerati" and I gagged.

------
tluyben2
Node.js is great stuff. It's not new (as far as concepts used), but really
nice to work with. Javascript tools and runtimes are growing up very fast;
it'll probably go on to surpass Erlang for this purpose if the libs are stable
enough. Node.js was the killer framework for JS anyway.

~~~
evgen
_Javascript tools and runtimes are growing up very fast; it'll probably go on
to surpass Erlang for this purpose if the libs are stable enough._

I don't know whether to laugh or to cry... Node/JS may replace
EventMachine/Ruby or Twisted/Python for quickly whipping up an evented app or
service, but it will be quite a while before anyone would consider moving an
erlang project to node. Node is little threat to the distributed, fault-
tolerant, concurrent niche that Erlang occupies -- within that realm there is
nothing you can do in node that can't be done better in erlang and a great
deal of bulletproof infrastructure in the frameworks built up around erlang
and its vm that node will never come close to.

~~~
randylahey
Holy FUD! I'm sure all the Lisp and TCL fanboys thought the same of their
supposedly superior runtimes all the way to eventual irrelevance.

Hubris much?

~~~
SamReidHughes
Um.

What he says is basically true. Node is never going to replace Erlang for the
same reasons it will never replace C++. Erlang is simply _different_ from
Javascript and no amount of runtime improvement can change that.

~~~
gtani
Not sure what "replace" and "threat to erlang" means, but: for shops that
already run the JVM and .NET, I think many'd be inclined to look at akka (or
scala actors) and asynch workflow as available today in F# (and promised for
C# 5/.NET 5). But the important thing is that erlang is no static target,
development is going very strongly: read the release notes for e.g. R14A, B
and B-01.Ask questions on the mailing list if you're not sure what something
is, they're very friendly. (maybe someday they'll fix apache not to give out
direcotry listings like this ;->

<http://www.erlang.org/download/>

------
jderick
It seems like event based programming would be really cumbersome in comparison
to having lightweight threads ala Erlang. Perhaps Javascript needs lightweight
threads?

