
The secrets of Node's success - fogus
http://radar.oreilly.com/2011/06/node-javascript-success.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+oreilly%2Fjavascript+%28O%27Reilly+News%3A+Javascript%29&utm_content=Google+Reader
======
6ren
A failing with programmers is we tend to focus on solutions rather than
problems. Perhaps it's partly because, to be a good programmer, you need to
immerse yourself in the code. Unfortunately, this takes your attention away
from the bigger problem that the code solves.

In this article, it's interesting that though "Node solves a problem" is
stressed as key to its success, compared with the many other JS server-side
projects, they don't explicitly mention the problem, except obliquely at the
end! (The problem is _efficiently handling massive concurrencies in network
connections_.)

It's because of this short-sightedness of programmers that there will always
be easy pickings available to anyone who actually looks at problem. Be a
problem-person, not a solution-person.

~~~
jshen
And it doesn't define "massive" :/

I still don't see a compelling reason to use node. I think the jvm is a better
choice all around.

~~~
superjared
"Massive" in this case is terribly subjective. I think the typical definition
is concurrency between 10k and 50k. Whereas when we (at Urban Airship) wanted
to hit 500k, the only reasonable way to do that without resorting to pure C
was by using the JVM.

~~~
baudehlo
It depends what your clients are doing. I've written perl servers (using
epoll) that can cope with 300k concurrent connections, as long as they're not
all talking at once. I've written perl servers coping with 50k concurrent
connections where they are all talking at once too. And v8 is MUCH faster than
Perl.

~~~
jshen
And slower than the JVM

~~~
baudehlo
Meh, sure basic operations are always going to be slower due to lack of type
information, but for most work it's going to be pretty close to the JVM in
terms of I/O, database access, etc. For compute specific tasks, sure it may
not be the right tool for the job.

~~~
jshen
I'll be that clojure is faster and it isn't statically typed. I have far more
confidence in the JVM handling heavy load that V8 which wasn't designed as a
server side technology.

------
rbranson
Node.js is neat, and I have contributed some things to the community, but it
has a long way to go honestly if it's to be taken seriously in the performance
and infrastructure realm. Articles like this don't help it's image either.
It's as if a naive PHP developer suddenly discovered long-running processes,
eliciting a chorus of rolling eyes from those who've written server software
in the last 30 years.

Ryan and team are talented people, but they're mostly dependent on the V8
team, which is focused on building a JavaScript interpreter for a browser.
Node.js/V8 has come tremendously far in the last 18 months, but still hits
some particularly nasty walls when it comes to massive concurrency and
managing big pools of memory in non-trivial applications. It will take some
serious time for these challenges to be overcome. The JVM, Erlang/OTP, and C
are particularly good platforms for this type of software because they're
mature and well tested in these environments.

I really hope for the sake of the project that the hype surrounding Node.js
blows over and the hipster crowd moves on.

~~~
bergie
The PHP community _is_ just now discovering long-running processes. Yesterday
we made TYPO3 run on AppServer-in-PHP, and this simple setup change gave a
2-4x performance boost depending on complexity of request

------
MatthewPhillips
I don't see a lot of merit to the "sharing code" idea as the purpose of server
side code and client side code are completely different. There are 2 possible
exceptions where I can see some use:

1) Utility libraries. I have a clone method I use a lot, an would work equally
well in both environments. I'm sure math libraries would be the same way.

2) Models. _Maybe_. Personally, my server side models contain get and save
methods which make database calls. I don't want or need those on the client
side. If for no reason other than wasted bandwidth.

* note: I'm a node user, but I don't share any code between server and browser.

~~~
dualogy
Since I compile all my CoffeeScripts into JavaScripts at node program start,
code sharing is a breeze. For each file, I make a client version and a server
version and use simple preprocessor lines:

#if client

#if server

#endif

for the pieces that only apply to the client side or the server side, with
shared pieces staying outside these "tags". I won't go back. This is
especially cool as I have a templating system that can run on the server or on
the client. So for JS-enabled browsers, all HTML template rendering is done on
the client by building all HTML tags out of very small simple JSON structs.
For non-JS clients (spiders, bots, paranoid non-JS enterprise legacy browsers)
the "pages" get fully rendered old-school by the server-side -- both sharing
the same rather simple custom-made JSON-driven templating functions and
producing essentially almost the same HTML output. Of course there are some
added complexities going on with things like scripted onclicks, but you get
the general idea. (This is mostly done for indexing spiders and human non-JS
clients just simply have to put up with a limited, degraded, basic
experience.)

~~~
Andi
I do it similarly. And it's the way to go ...

------
gvnonor
From a couple of presentations I watched and reading online, nodejs advertises
that it makes writing web servers easy. Do everyday programmers actually need
node or is it meant to be a niche language?

~~~
andrewcooke
it's not a language at all. it's a library for writing server-side code in
javascript. it's event driven, like python's twisted. in fact, it's hard (if
you assume people are rational [edit: and have perfect access to information])
to see why people find nodejs so cool, yet have been ignoring twisted for
years.

~~~
nxn
I think it was a combination of things. One, the timing was nice because
JavaScript was getting more and more attention as its engines were starting to
seriously compete for speed. Two, I think the fact that it was JavaScript on
the server really helped get it a lot of buzz as it was somewhat
"controversial". "Controversial" because I can't think of another language
whose users are so split between liking and hating it. Having it invade the
server meant a lot of people's blood began to boil as they thought of having
to potentially deal with it outside the browser, and a lot of other people who
were excited about being able to use it outside the browser. Either way, the
combination of love and hate gathered a lot of talk and attention in my
opinion.

Now to contrast this with python: I personally have never heard of Twisted
before all the talk of Node came about. Mind you, I'm not a python developer
and if someone's blog title doesn't grab my attention by having some
connection to me, or what I do, I'll probably just skip over it.

------
samlittlewood
And another thing .. Buffers, which is partly down to V8's external indexed
data, and node's wrapping of that in the Buffer classes which are then used by
the various async. IO operations.

This means that content can flow through a node service with being touched by
javascript, and without adding work to the garbage collector.

------
dreamdu5t
The secret to Node's success? The V8 engine. ;)

~~~
pavlov
But would anyone really notice if Node used WebKit's JavaScriptCore (a.k.a.
"Nitro") instead?

There isn't a huge performance gap between the two engines these days... But
V8 is easier to embed in C++, I think.

~~~
grayrest
The js team at mozilla mentioned that they had a jagermonkey version running
internally as part of a test for the embedding api updates they're working on.

