Some early thoughts on Node.js

I’m pretty late to the Node.js party but I’ve found myself with some imposed free time this week so I thought I would spend some time getting across this newcomer. To get thing started I watch this video featuring Ryan Dahl. What follows is some reflection on what I see as the state of the platform.

Node.js is a Mashup

The first thing to remember is that Node.js is standing on the shoulders of giants. It hosts Google’s open source JavaScript engine (V8), so the runtime and the language are a known quantity – this is good! JavaScript performance has come a long way since I first starting dabbling with it.

Because they haven’t invented their own language, and because they haven’t invented their own execution engine I put Node.js in the mashup category – and in doing so made JavaScript easily available as a server-side programming language. Of course, no modern web platform is completely without a package management tool – here you’ll find this space filled by NPM.

Process Model and Hosting

Even though Node.js seems to be the new black, I think that is has some major hurdles to overcome around its process model. Each node process has one thread, so you might have a fantastically powerful box, but you aren’t going to be able to leverage it unless you are into cross process communication. Its easy enough to get Node to balance incoming requests across multiple processes using the “-balance” switch but if you do want to share data between those processes you need to serialise transmit and deserialise the data.

When you start working at massive scale those tend to be some of the problems you need to deal with anyway, especially in the area of distributed caching, but these are also problems that not everyone has. A vast majority of software developers out there work within enterprises writing relatively low-load applications that just get uploaded to a server somewhere and tick along. Mind you, by that logic a single process with a single thread might serve their purposes just fine 🙂

Ultimately – the thing that worries me is the assumption that server == application == process. When you have a dedicated web server infront of your web application platform it can do useful things like sharing the same port/URL space with multiple applications. You can patch through specific requests to Node JS and I see this becoming the most common hosting scenario for Node.js considering the kind of site density you get on some hosting providers.

Overall – I can’t see why Node.js won’t be a viable web development platform moving forward. I think problems are being solved almost as quickly as they are being discovered which is what happens when you start trying to solve real problems with a new technology.


I’m actually very spoilt. I do most of my development with Visual Studio targeting the .NET platform, and Microsoft has bar none to most powerful debugging experience in any tool that I’ve ever used – so when I see things like “debugger;” in code I just want to cry. I suspect that debugger UX and debugger support are two completely different things. See, the UX that Microsoft has in Visual Studio has evolved for over a decade. The UX has been enhanced to support dealing with things like concurrency and adding first class support for TPL. Its hard for a newcomer to compete with hundreds of man years of investment, if I want to play with Node.js, I need to deal with a limited debugger experience.

What I didn’t know, and what I do find interesting however is the way that the V8 engine exposes debugger information in the form of a JSON messages. In theory you could build a bridge between Node/V8 to Visual Studio and end up with quite a powerful combination. The model is a lot like the profiler API in .NET actually.


Node.js by itself isn’t that interesting. Its got the fundamentals to get a server up and running, but if you commit to Node.js, you are also committing to learn at least half a dozen other frameworks in order to do something productive – same old story with any platform I guess.

A Final Thought – Why Bother

I think the novel thing about Node.js is the fact that it is a viable server-side JavaScript execution environment. I don’t think its process model has any special scalability benefits (at least not beyond what I am experience with in .NET), so for a .NET developer I have to ask the question – why would I bother? Natural geek curiosity is the first part of the answer, but a lot of good comes from investigating other platforms. Sometimes you pick up new techniques can be migrated back to your home turf, and vice-versa, and of course if Node.js really takes off (its getting some hot press these days) then you’ll be better prepared.


7 thoughts on “Some early thoughts on Node.js

  1. Mitch Denny Post author

    Hi Liam,

    Are there any adoption numbers? Just trying to get a sense on what popular really means for Node.js. I found Douglas Crockford’s presentation very interesting. But I think that he probabbly glossed over a few things on the whole Event Loop vs. Threads thing.

    Firstly it doesn’t have to be a binary choice. Windows applications have been successfully using the Event Loop for quite some time, and, when you need to do something long running, you spin it out on a thread and get a callback with the result. It is nowhere near as complex as what he makes out.

    Dealing with things like deadlocking and concurrent access to variables are things that need to be considered but even in my experience not a completely impossible thing to cope with.

    The thing that made me laugh was once he finally addressed the issue of where you run your long running operations – he said push it out into a seperate process. But that has all the same issues of possibly introducing deadlocks, and dealing with race conditions – conceptually a thread and a process are very similar in that they provide independent streams of execution.

    We are obviously heading into a bit of a Node.js frenzy, but I hope people don’t start becoming blinded by the purist arguments about Event Loops being awesome. It might work 90% of the time, but then so do other web platforms.

  2. Joe

    It will be interesting if Microsoft attempts to copy this model by porting WinRT (which is also asynchronous as a rule) to the server side and mix it with a heavy helping of the new ‘await’ keyword.
    Add to that a sprinkle of Roslyn compiler as a service for enhanced code generation and I think you would have quite a powerful platform.

  3. eh

    As a seasoned developer (most fond of .NET), I never get the hype behind projects like node.js. I just can’t see why/how anyone would leave mature, robust environments like .NET or Java (or even PHP, comparatively speaking) for something like this.

    I’m sure it has its very specific niche uses, but I’m already seeing posts like “.NET is dead, long live node.js!” Give me a break… Granted, I’ve only briefly went over the node.js docs, a few examples, and some basic overviews, but (even with the “performance” nodes is touting), it looks like a low-level, quick-and-dirty way to instantiate web clients/servers and communicate back and forth — with JavaScript on the back-end. Sure, of course there are helper classes, etc. in there, but still… this is not ground-breaking by any means.

    I think you were spot on when you said “Why Bother?” I develop for a living, and I develop for enjoyment. While some people may enjoy using the “hot language/platform/whatever” du jour, when it comes to developing for a living, I need robust tools that are productive on all fronts — not just *performant*.

    It also boggles my mind when people agonize over how many ms. they can save here or there per request. Sure, I’m all for optimization and performance, but are there really that many people that have such high-traffic sites that their foremost concern is how to shave a few ms. from a page request? Not to be snide, but I often have to wonder how many of the people who blindly jump into the “fan club” of these newest technologies actually develop working software for a living.

    To me, it’s about developing quality software/websites, quickly and productively that attract (and please) users, grow, and ultimately make money. Constantly taking these “backwards steps” in the name of being “hip” makes no sense. Let these folks look at my “outdated” tools and say, “dude, so five years ago!” They still work, they still work *well*, and they still enable me to be as productive as is needed.

  4. Alex

    I’m going to throw out an opposing view from many expressed here. I’ve done c# for as long as I care to remember and have made a lot of money doing so. It is still my bread and butter. However, when I was asked to build a heavy duty REST interface about a year and a half ago, I decided to test all my options because c# did not have the latency the client required. I tested things like Clojure and Scala and Go and C and Node. For a variety of reasons, we decided to use Node and have never once been upset by the choice.

    If your app MUST support high concurrency and low latency with low resource usage, Node is a better choice than c# (significantly better – ~15-20% – with the latest versions) DEPENDING upon what database you are using. The drivers in c# are far more mature and stable and you need to heavily benchmark the node DB driver otherwise all that performance savings I mentioned above can be thrown out the window and you may actually see worse performance.

    Packages – the package ecosystem between c# and node just can not be compared. I think NPM just went over 20k packages. Need a particular piece of functionality? There’s probably 5 different ways to accomplish the same thing available on NPM already. Does not mean that they are all great? No, you REALLY must look under the hood of any you want to integrate into a project. But they are often more tightly focused than what exists in the c# world which fits the nature of Node – plugging together small, distributed and decoupled functionality to create a greater whole. However, my comment about db drivers holds true here too – our experience is that the libraries for c# are often more mature and stable.

    Debugging – totally agree with you. Debugging in VS is a dream compared to node although tools such as webstorm are changing that. And node has the ability to take advantage of DTrace which is a level of application traceability that goes far above what is standard in the c# world.

    As for closure vs. thread handling argument, I think its both a personal choice and a question of what the project demands. I have grown to love the closure model and it can be easily tamed with libraries such as async. It is simple and there are no edge cases – its easy to get right and then forget about. Try saying the same about await which, as simple as it is, can really make your head hurt at times due to edge cases you didn’t consider. On the other hand, the closure model is simple and places you in a straitjacket where you wish you had proper threads to do something in the background. The best way around that is to pass messages to different node processes but that can get messy very quickly and you have to create an entire infrastructure to handle the inherent headaches while c# has already built that threading infrastructure for you.

    Now, after a year and a half, I find that we are migrating some client work to node that I would have previously done in c# but the majority of our work is still c#. Its basically a case of now that we know and understand node, we can pick and choose what fits the bill of a particular engagement.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s