It’s right at the end of 2016 and I’ve leapt into a new startup as the only engineer. My first big decision is what technology stack to build our product with. I’ve picked nodejs and here is why.
It’s what I know best
This is the main reason, and one that’s almost always the best one when starting something from scratch. There’s lots of really interesting languages and frameworks out there. I’m really interested in functional programming and loved my time working in Ruby so Elixir and Clojure were two things that sprung to mind.
I’ve reached professional proficiency in a few languages now, so I don’t think it would take me long to get to grips with either of those. It’s not that simple though: all languages come with their own idioms, frameworks, package mangers, devtools and deployment issues. For Clojure, sure I can code LISP, but I know nothing about running the JVM in production.
Turns out I’m not Rich Hickey.
Sticking to what I know means that I don’t need to lose any precious time learning new tricks or troubleshooting problems of my own making due to not understanding the stack in depth. I cut out a big chunk of risk too. I know what I’m getting myself into. When doing an early stage startup there will be so much that you can’t know — it makes sense to cling to what little you do.
You can build things quickly with it
While not quite as productive as Ruby on Rails, you can still move very quickly. There is a module for pretty much anything you can imagine for nodejs thanks to the amazing npm ecosystem. I’ll save time by using other people’s modules. Not all of them are very good but I can tolerate the odd shabby implementation for now. I will write my own later if and when I have problems that aren’t “Having no product” or “Having no customers”.
It’s not cool anymore
Nodejs is now mature and battle tested and is being used by a great many of big technology companies such as Netflix and Paypal. Even Microsoft are keen to join the party. This means that money is being spent on keeping it stable and making it better. I can be confident that it’s not going to be abandoned or neglected any time soon.
Lingua franca
Back in 2007, Jeff Atwood wrote another of his influential blog posts. In it he coined a phrase:
JavaScript is the lingua franca of the web. Ignore it at your peril.
Since 2007 this has only got more true. The way I like to think of it is this:
Javascript is the English of programming languages. It might not be the best, it’s certainly loaded with quirks but it’s easy to pick up and it gets the job done. More pertinently it’s absolutely everywhere now and there’s nothing anyone can do about it.
Javascript comes to the server.
The one certainty of making a web application is there will be javascript in it somewhere, if only as the output of a transpiler. Things that can’t be avoided should be embraced. If you are stuck with something, you might as well learn to get the best out of it.
It helps me keep things simple
I want to keep my life as simple as it can be. By picking nodejs I can use one language right the way through all of my stack rather than having something for the client and something for the server. We stick with the classic web triumvirate of HTML, CSS and javascript.
I can hire engineers of all stripes so long as they know a bit of javascript and almost all web developers do.
There’s other nice things, like being able to share code across the browser and the server. Something that reactjs makes reasonably straightforward.
It will last me a long time
Nodejs is plenty fast enough to scale pretty nicely, and when I have out grown it, I will be a long way from where I am now. This is a problem I would dearly love to have. When that day nears, it won’t be the end of the line for nodejs. I see it being a part of my system in perpetuity.
As I said, right now I want to keep things simple. This goes for my architecture too so my app will be a monolith for now. One codebase, one deployment, everything in one place. Microservices are a great solution for problems involving scale and complexity; For productivity, not so much. Time spent messing with service discovery, load balancing and the rest is time I’d rather be using to create product.
The monolith. It’s not very fashionable, but it is very simple.
One day though, my monolith will start to creak, some bits will be too slow and the whole thing will become unwieldy due to it’s sheer size. I’ve been at startups that got to this point with their Rails application. Attempts to extract functionality and encapsulate it out of process or fully distributed were successful, but brought substantial drawbacks. Ruby is single threaded and blocking. When a Rails app makes a call on the network, the whole thread waits for the response before doing anything else. The more services you add, the longer you wait.
This meant that in the transition period, things got pretty slow, and the further into the transition we went the worse it got. It also resulted in a near extinction of Ruby in the codebase. While Ruby and Rails enabled the team to move quickly in the early stages, later on Ruby didn’t seem the best choice for a distributed system. All the team’s Ruby knowledge was wasted post transition and it made the Rubyists sad.
With a nodejs system, things are a bit easier. While it is single threaded, it’s also asynchronous and non blocking. This means that while we wait for the network to do it’s thing other requests will be serviced. Adding distributed components does not destroy performance.
Better still, javascript will never completely go away. As more services are extracted, the nodejs tier will gradually shrink into a anaemic web tier. It will have fewer responsibilities than in the monolith days but will still have a vital role aggregating calls to the services, rendering html managing sessions and other web stuff. There will be plenty of server side javascript too.
While many of the services may well end up being written in a new language (maybe I will get to play with Elixir and Clojure after all!), the institutional javascript knowledge will not be completely wasted.
It take a a village of services to build a system. All safely behind a thin wall of nodejs.
In summary
- It’s what I know best
- Supported by the wider industry
- It’s really productive
- Everyone knows javascript
- Sharing code across client and server is nice
- There’s no avoiding it anyway
- It’s good enough for now, but leaves a pathway to different things
I guess we will see over the coming years if I live to regret my decision. In the mean time, I’m also hiring the first member of my engineering team. So if you fancy hacking on nodejs, drop me a line: dom@terriertech.io