Why I was wrong and right about node

It isn't often that I'm wrong, it only happens a couple of times a day. For years I despised Javascript as a whole but more specifically as a backend technology. I had the pleasure or the misfortune of using it full time for a year at my day job and at first I wasn't over the moon about it. However, it was good that I was forced to use it for so long because it did open up my eyes as to why you would use it and more importantly why you wouldn't.

Why you would

I spent years thinking that anyone who picked node as their backend language of choice must be insane or really hate paying for backend developers. After a year of using why would I use node?

• Ease of deployment

• One language front and back

• Typescript

• A library to do anything

• Endless tutorials and documentation on anything and everything Javascript related

• Shear mass

Ease Of Deployment

Whether you're using it in a serverless environment or using it with traditional servers you can bet that there will be a million tutorials and a million platforms that support the hosting of a node application. This makes it ideal for proof of concepts or for startups looking to get into market quicker as any sized company from your AWS to your Digital Ocean will support node and usually in the most drag and drop fashion.

There has to be something said for ease of deployment, which I guess is why serverless has come around. There are just so many platforms that are set and forget when it comes to node deployments.

One Language Front and Back

A good developer should be able to pick up a technology in a fairly short period of time and once you have been doing it for long enough there is a good chance you have worked in both the front and backend for some time. Thus comes the sentiment that you should be able to work on any part of the stack. Although I don't believe this to be the best use of developer time as the context switching is quite harsh. I do believe that a good developer should be able to chop and change in different areas of the stack which is why having one language front and back helps tremendously with the reduction in context switching. Sure there are different concepts in the backend than there are in the frontend, but at the end of the day its all just Javascript. It minimises the amount of context switching by not switching entire languages.

Typescript

Javascript sucks, I think we can all agree that in 2021 plain Javascript is a terrible choice for anything serious. I can't tell you the amount of times that I have small bugs just from there being zero typings. I can not and will not build anything for production without using Typescript. Which is exactly what you want for your backend. An API is inherently going to need a lot more typing in order to stay readable, maintainable and at least somewhat bug free. Now you don't have to have types in your API if you use a functional language like Elixir there is a much lower reliance on typing because of the nature of the language. However, in the case of Javascript, if you're not using Typescript on the API and I would also argue on the frontend as well then you are doing yourself a disservice.

A Library To Do Anything

The beauty of JS is that there is a library to do anything, or more commonly 20 competing libraries, which is both a plus and a minus. Yes you can do anything but you will need to spend some time working out which is the best library to do it. I would rather have to many than too little as you can at least swap and change if you don't like one. There is no question that if you have a problem there will be a JS library out there that can solve it for you, and most of the time it has types too.

Tutorials And Documentation

For any beginner there are a million and one tutorials out there in JS. You can build a GraphQL api or a REST one. You can build anything your heart desires and there will be a tutorial for it. This is incredible helpful when learning a new technology and it's one of the defining factors when people go to pick up a new technology. With node and JS in general its dead simple to find what you need and quickly.

Drawbacks

You can do everything in Javascript which makes it a jack of all trades and a master of none. This makes it great for a proof of concept and with some cool frameworks like NestJS you can really structure your API well. However, most node API's turn to hell because for the most part they won't use frameworks or don't have the structure to truly grow into a large codebase. If you have a serverless architecture then it probably doesn't matter as much but when it comes to something more traditional like a monolith then it really does matter how you structure it, how you lay everything out, how everything interacts with each other.

The more I use it as a backend technology the more I enjoy it, yet I still keep going back to Elixir for anything serious. I hate the ORM's that node has, they just don't work nearly as well as Elixir's semi-orm ecto. I keep going back to the defined structure that is Elixir, the set way of doing things. The fewer decisions I have to make about styling, structure, or what else that really doesn't matter too much the better. It's not that these decisions are hard it's the philosophy that these things are taken care of, which shows in other codebases. It's extremely hard to jump from one node project to another because everything is laid out completely differently, the styling is different, everything is just different from one project to another.

My choice

I won't knock anyone who chooses a node api for most general purpose API's but you have to keep in mind that it will require more overhead to keep it neat, organised and scaleable than something like Elixir with its strong structure. It simply comes down to Node having a million ways to do something and Elixir having only a few. Its the philosophy of the language or the framework which to me plays a bigger part. If you can instil a strong philosophy in how you build software then it doesn't matter what language or framework you choose. However, it helps that with Elixir you simply don't have to worry as much as the language pushes you in that direction.