To Node or not to Node, that’s the question!
It all started one afternoon when I got a call from Yoav Nordmann. He wanted to continue a discussion that we just had at the backend-group in Tikal. The discussion was about good and bad use-cases for using NodeJS. But let me take a few steps back.
I was first introduced to Java in the previous century: the year was 1999 and it was my first year on a CS degree and what can I say: I did not fall in-love…
Fast forward to the end of 2017, at this point I have many years of experience with Java and I love it, heck, I even got a gold badge on SO!
During these days I started talking to one of Hippo’s cofounders, we were discussing the possibility of me joining them and then the CTO dropped a bomb: “We are building our backend in NodeJS” he told me. I went silent. Back then, I could not imagine myself working in a non-JVM environment, let alone a language that is not strictly-typed. And to make things worse, it was Javascript!
Let’s admit it, folks, most of us, “conservative backend developers”, are not inclined to touch JS for any reason. We will do it, but only if we have to...
I told him I’d need to think about it.
In fact, it took me a good few weeks and consulting twice with a buddy of mine which I think highly of their opinion. And they kept saying: a programming language is just a tool, get out of your comfort zone and try it, what’s the worst that could happen?
I think that “get out of your comfort zone” is the thing that got me. So I joined Hippo.
To give you a very concise background about the company: Hippo is a startup that was conceived in 2015, and after a seed round, in early 2016 the first lines of code were written.
Fast forward to July 2019 and Hippo completed a D-round with a valuation of 1.5B dollars. Hippo became a Unicorn faster than FB or as I call it: “a Unicorn on steroids”
But how such a small startup, with a small R&D (I joined as the 7th engineer at the beginning of 2018), made it so big and so quick?
In my opinion, a major contributor to the equation was the technologies that we chose to work with. Back then we leveraged many of AWS technologies: Elastic beanstalk, RDS, Cloudwatch, Lambdas, S3, kinesis, step-functions, Firehose, and Athena to name a few. But, the “secret sauce” was NodeJS.
Now don’t get me wrong, I don’t think that NodeJS is a silver bullet, and I still think that JavaScript: The Good Parts being a very short book — is by no accident. Further, I think that backend should, in most cases, be strictly-typed.
NodeJS: the good the bad and the ugly
Well, the bad is obvious, JS. A language that makes it very easy to shoot yourself in the foot.
The ugly: there are so many… here are a few examples: for many years the only way to declare a variable was by using var which is hoisted, what a way to cause bugs… Further, since JS is an async by nature, most of the code used to use callbacks. Async code is not something “natural” for our mind to process, not to mention debug. That said, with the move to promises and then to async/await the code that we write today is easier to “streamline” and process (in our brains). Also, in ES6 var got deprecated when let and const were introduced. That along with arrow-functions, spread operator and some other goodies made the language somewhat less ugly.
So, what is good?
My answer to that question is 2 kinds of speed:
- V8 is a Javascript engine that was developed in Google, and it’s fast, in fact, it’s so fast — almost like
c++(there are trade-offs of course, e.g. inc++you have to manage the memory allocation by yourself while in Node there’s a garbage collector that is doing it for you, with the price of… garbage collecting) - And this point is actually the most important point in this post: developer velocity
The reason NodeJS was the “secret sauce” is that it enabled a very small team of developers to implement many features, small and big, in a relatively very short time!
After years of working with Java, I was mind-blown by the speed our team was moving. Javascript is much easier to pick up compared with Java, it’s very expressive and while it’s also risky (cause of duck-typing and, reasons…) you can very quickly get yourself setup and just focus on implementing!
Until now I was expressing my feelings based only on my experience. But then I found that Stackoverflow survey for 2020 picked Javascript as the most commonly used programming language for the 8th year in a row!
A good question to ask is: where does Javascript as a backend language fail and what can we do to improve it.
A good place to start is with the bad part. How can we improve on something so basic as a language that is not safe?
I think the solution is:
Since Typescript forces strict-typing it helps prevent mistakes such as sending “1” (the string 1) instead of 1, respecting method signatures, interfaces, generics, and all the other goodies that we can catch at compile-time.
Using Typescript is also a trade-off because, in my experience, it will slow you down a bit. But I think that it’s a good trade-off because the slow-down is not major while the benefits are big.
When Yoav and I continued this discussion over the phone we both agreed that NodeJS is wonderful for POCs and for small services but when things start growing they can get very hairy very quickly, and it really helps to have more order/structure in the code, which TS provides. Further, even the most disciplined engineer will make mistakes that TS can (and will) prevent.
As engineers, we always try to measure the trade-offs and pick up what we think is the best option, based on our knowledge of these trade-offs. It’s important to remember that there is no “silver-bullet”, and no such thing as “the best programming language”, it’s all about making a conscious, egoless compromise for the best of the company & the team.
What do you think? Agree? Disagree? Have a different experience? If so, please drop me a line in the comment section!
Also, if you found this article interesting and you’d like to help us solve interesting problems: Hippo is hiring!
