Farewell Node.js

I’ve been fighting with Node.js long enough in production now that I don’t enjoy working with it anymore, so at least for now this my formal farewell! And more importantly I need maintainers

Node does some things well, but ultimately it’s not the right tool for the type of software I’m interested in these days. I still plan on using Node for web sites, but if you’re interested in maintaining anything let me know. Just leave a note with your GitHub username and NPM username! As usually all I ask is that you don’t drastically change existing APIs, if you’re doing that then you might as well just start a new project ☺.

Koa is the one project I’ll continue to maintain (along with Co and friends).

The Holy Grail

I’ve always loved C, but anyone who works with C knows that it can be both rewarding and error-prone. It’s hard to justify as the language choice for day-to-day work since it’s not exactly the quickiest to work with. The simplicity is something I’ve always admired about it, however without a large amount of boilerplate you won’t get far.

The more I’ve been working with distributed systems, the more I’m frustrated by Node’s direction, which favours performance over usability and robustness. In the past week I’ve rewritten a relatively large distributed system in Go, and it’s robust, performs better, it’s easier to maintain, and has better test coverage since synchronous code is generally nicer and simpler to work with.

I’m not saying Go is the holy grail, it’s certainly not, there are things I don’t like about it, but for the languages that exist today Go is a great solution for me. As more of these “next-generation” languages such as Rust and Julia find their place and mature, I’m sure we’ll have a lot more great solutions.

Personally I’m most excited about Go because of its iteration speed, it’s exciting to see that they’re eager to reach 2.0 and from what I hear, they’re not too afraid to start breaking things already which is great.

Why Go?

Node is still a nice tool and if it’s working for you then you have nothing to worry about, but if things are bothering you, don’t forget to step out of your box and see what else is out there — within the first few hours of using Go for production work I was already hooked.

Again — I’m not saying Go is the absolute best language out there and that you must use it, but it’s very mature and robust for its age (roughly the same age as Node), refactoring with types is pleasant and simple, the tooling Go provides for profiling and debugging is great, and the community has very strong conventions regarding documentation, formatting, benchmarking, and API design.

The Go stdlib is something I thought was awful when I first heard of Go, being so used to ultra-modularity in Node, and having experienced most of Ruby’s stdlib rot. After getting into the language I realized that most of the stdlib is pretty essential to programs these days, compression, json, IO, buffered IO, string manipulation and so on. The bulk of these APIs are well-defined, and powerful. It’s pretty easy to get by writing entire programs with nearly only consuming the stdlib.

Third-party Go packages

Most Go libraries look and feel similar, most of the third-party code I’ve worked with so far is high quality, which is sometimes difficult to find with Node since JavaScript attracts a wider range of skill levels.

There’s no central registry for Go packages, so you’ll often see 5 or 6 packages of the same name. This can be a little confusing at times but it has an interesting side-effect, you really have to review each one to determine the best solution. With node there are usually canonical packages such as “redis”, “mongodb-native”, or “zeromq”, so you may stop right there and just assume those are the best ones.

Go verses Node

If you’re doing distributed work then you’ll find Go’s expressive concurrency primitives very helpful. We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there. Without separate stacks error handling & reporting will be mediocre at best. I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.

Error-handling in Go is superior in my opinion. Node is great in the sense that you have to think about every error, and decide what to do. Node fails however because:

• you may get duplicate callbacks
• you may not get a callback at all
• you may get out-of-bound errors
• emitters may get multiple “error” events
• missing “error” events sends everything to hell
• often unsure what requires “error” handlers
• “error” handlers are very verbose
• callbacks suck

In Go when my code is done, it’s done, you can’t get re-execute the statement. This is not true in Node, you could think a routine is completely finished, until a library accidentally invokes a callback multiple times, or doesn’t properly clear handlers, and cause code to re-execute. This is incredibly difficult to reason about in live production code, why bother? Other languages don’t make you go through this pain.

Future Node

I still hope Node does well, lots of people have heavily invested in it, and it does have potential. I think Joyent and team need to focus on usability — performance means nothing if your application is frail, difficult to debug, refactor and develop.

The fact that 4-5 years in we still have vague errors such as “Error: getaddrinfo EADDRINFO” is telling of where the priorities are at. Understandably it’s easy to miss things like that when you’re so focused on building out the core of a system, but I think users have expressed this sort of thing over and over, and we’re not seeing results.

Streams are broken, callbacks are not great to work with, errors are vague, tooling is not great, community convention is sort of there, but lacking compared to Go.

Again this is not a personal attack on anyone, lots of really talented people work with, and on node, but it’s not something I’m interested in anymore so please speak up if you’re interested in maintaining anything I’ve worked on.

Moral of the story, don’t get stuck in your own bubble! See what else is out there, you just might enjoy programming again ☺.