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