The secrets of Node's success | Hacker News Reader

The secrets of Node's success

radar.oreilly.com

79 pointsfogus43 comments

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.

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.

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

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.

And slower than the JVM

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.

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.

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.

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

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.

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

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

Sharing the utility libraries are a huge win though and should not be underestimated. For example on one project alone:

- Input Validation

- Asynchronous loop patterns

- Promise pattern implementations

- markup logic & output

- A* pathfinding

More and more use cases will pop up over time, and it's really unique to the node.js environment. This alone would not make me pick node.js over another solution but I feel it is still an advantage.

I spend about 50% of my dev time on writing / working with utility libraries as writing these libraries takes far more effort than writing handlers, models, etc.

Ian Bicking does a great job of debunking the many of the alleged advantages of code sharing: http://blog.ianbicking.org/2011/03/30/js-on-server-and-clien...

    Validation on the client is primarily a user experience concern,
    where you focus on bringing attention to problems with a form, and
    helping the user resolve those problems.
    
    Once the form is submitted, if you’ve done thorough client-side
    validation you can also avoid friendly server-side validation. Of
    course all your client-side validation could be avoided through a
    malicious client, but you don’t need to give a friendly error
    message in that case, you can simply bail out with a simple 400 Bad
    Request error.
    
    At that point there’s not much in common between these two kinds of
    validation — the client is all user experience, and the server is all
    data integrity.

With the right abstractions the code for validating on the client and for validating on the server can be identical. For example take a look at Luna/Lunascript.

This is not easy by just using Node, and it's not necessary that the language you use is Javascript. A better approach IMO is that you have a language X that is nicer than Javascript, and compiles both to server side code and client side Javascript.

For the case of validation here is a hypothetical language (ignore the bad regex):

    <form action="/foo/bar">
      <input type="text" name="email" />
      <%= if not email ~ "[a-z]+@[a-z]+.[a-z]+": invalid("Email is not valid") %>
      <submit>
    </form>

From this code you could generate real time JS validation and server side validation.

That's some nice theory, and it's obvious the author hasn't had much experience implementing real applications where sharing code is possible.

Example: You are building an editable list. The client insert and delete items from the list, which is then synchronized with the database. Now you need the HTML generating code on both the client and the server.

Another example: validation. You want to validate on the client for responsiveness, but on the server for integrity.

Being able to reuse content generating code can be especially useful when you don't realise that you will need it on both the client and server when you write it, or you have to move it from one to the other.

Code sharing really only becomes a compelling argument if you're building browser games or something similarly interactive (i.e., really bloody interactive). In this case, you need to run the same logic on the client (to reduce latency) and on the server (to validate and actually update game state).

Otherwise, you really have no excuse for putting logic on the client. Even with something like validation, I think its much more sensible to have your renderers pump out generic validation event handlers than to reconstruct the whole model class on the client.

I definitely am in the same camp on the "sharing code" argument, but could see careful structuring make models sort-of work. Obviously the basic persistence behavior needs to change, but if you reduce validation and some of the business logic to something more composable/interchangeable you could share it between the two.

Obviously then you'd need some way of distinguishing validation that is only important to one of the two ends from that which is meaningful to both, but I can see it being possible.

That said, I'm still not convinced it's worth it. Especially when you look at the state of libraries in node compared to something like Python/Ruby.

IMHO, the merit of sharing code really shines with templates. You can have full-featured Haml-js templates that are rendered on the server and the client. This means your client can make RESTful calls to your JSON api and has full rendering capability in the client.

I do that by using RDFa as the "templating language". This way the same templating information is usable on both client and server, and also external tools like search engines can benefit from it

Could you explain? Right now I'm using Jade on the server and Jquery Templates on the client. I'd love to use the same templates on both.

Most of templating is relatively simple rules: put attribute foo of object bar inside this div, repeat members of collection baz here.

These can just as easily be described using RDFa as using TAL or Jade or whatever. The benefit of RDFa is that the templating information stays with the page, so client-side can also utilize it.

The library I made for this is https://github.com/bergie/VIE

Do you want me to explain Haml-JS shared across both or the parent of your comment to explain RDFa? If you email me - aaron.blohowiak@gmail.com - I'll write up a tutorial and send it to you when its ready.

The way I've heard it argued is that as more and more things happen in the client, you want some level of data validation there. But as we all know, it's not enough to just validate the data in the client - you need to do it on the server too. So hence code duplication.

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?

Yes and no, I've spent the last two weeks building and launching a node.js project and it's really really fast.

Blazingly so.

I've got a PHP project at http://fstr.net and its pageloads take about 4 to 5 seconds under normal load. With my other project pageloads are less than a second most of the time (though there seems to be some variability when dealing with the first connection).

Both projects do essentially the same thing (query database, present list). It's really shocking just how much faster node.js is.

Another nice aspect of NODE with a MongoDB solution is that I can scale it very easily. On AWS I can send all traffic into a load balancer, then as the server's load increases I can just fire up additional (CLONE) instances and add them to the load balancer.

A reserved Amazon micro instance costs ~$5 per month or a 'high CPU' instance comes in at $17. Scaling node is really as easy as turning on another machine (or running multiple instances of the application on a machine with multiple cores).

Compare the performance of almost anything to PHP and you're going to be delighted.

Yes, the V8 engine is fast. That's what it's designed for. But that's only remarkable because it's a JavaScript engine. You can get the same performance from Go (with better memory utilization to boot) or even Java.

> I've got a PHP project at http://fstr.net and its pageloads take about 4 to 5 seconds under normal load.

Whatever language you are using, if loading a page takes >1 second, you are doing something very wrong.

I have built web apps out of shell scripts that perform hundreds of forks and open dozens of files per request, and still easily managed <200ms response times while running on a crappy xen server.

>I have built web apps out of shell scripts that perform hundreds of forks and open dozens of files per request, and still easily managed <200ms response times while running on a crappy xen server.

With how much concurrency?

You're probably very right there. FSTR could definitely be 'tuned' to be faster, but since this one and the other have all other things held constant in terms of programmer skill, then doesn't it come down to the language?

I mean if I'm doing something wrong in PHP, then I'll likely make the same mistakes in node.

You are right though, PHP+apache can be just as fast as anything else. I'm told that apache has a lot of overhead because of all the modules that come enabled by default. Apparently by removing all but what you need, you get a system that's a lot faster.

That's a bit more advanced though - while node's quick by default.

Anyways, I'm far from a language zealot in any way. I've loved every language that I've worked in.

I'd love t see some of the stuff you're talking about that's lightning fast with hundreds of forks... sounds like something I could learn from :)

I clicked through and the site feels quite fast in comparison to a lot of other similar sites. It's the external social media stuff that takes ages to load.

Anyway, I think we all want to know more about those forking web apps you've made. They sound quite impressive.

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.

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.

twisted - "A completely different set of batteries included."

I have deployed services using both twisted and node - some off the cuff points:

- Twisted is large, and includes many new concepts and vocabulary, with somewhat patchy documentation. There is a big hump to climb over before being productive. I was pretty much there with node on one 35 minute train ride.

- The twisted async. mantra only flies within the (albeit large) twisted cloud of classes. I often find myself deferring to threads etc. for synchronous file IO etc.

- Writing plugins for node is very approachable (including things that interact with the event loop). I use ctypes + .so for the same work in python land, but it took some experimentation and discovery (albeit not very difficult) to arrive at a good pattern for this.

Once you understand it - twisted is an enormously powerful resource, and I am still writing complex services using it. Node gets used for wrapping up computation services.

From my point of view, it's down to a combination of good marketing and 'right place at the right time'.

I've never heard of twisted - but I feel like I'm getting in on the ground floor with node. Additionally, I was positively salivating to learn a new language when it started 'emerging'.

I think part of it comes down to the fact that I was already very comfortable with Javascript, so I started with node.js knowing that I at least knew some of the basics ... and thank got I did, because programming in node is very different from what I'm used to.

It's sometimes difficult to know which lines of code are blocking and which aren't.

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.

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

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.

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.

All of the native extensions that would break would notice.

Node hooks into it quite neatly.

Reply on news.ycombinator.com