INTRODUCTION
"NodeJs is better than Php", "I would rather use Flask in my sleep cause Python >>>(greater)", "No vex, but Golang is clear" etc. We have heard so many arguments go on and on about things like this and it almost seems like there will never be an end to it.
Then there are the neutral guys that go, "Use what you know to start", then God will help you through the remaining journey. And to be honest, it might just be good advice because sometimes, worrying might be a bottleneck or we never really worry about how the language choice affects us. We mostly think, once our users go up, we scale vertically(finally leave AWS free tier plan and start paying😥😥😥) or/and we scale horizontally(we deploy more instances) and that is the headache of the Cloud Architect. As a Backend developer, let me just CRUD, funny how this actually means nonsense, no wonder some PMS disrespect us and say "how are you spending a week doing crud?".
This article will mainly be my thoughts on "why or why not Nodejs" though, hope you have a good read.
*P.S : Any word with an asterisk has a short definition at the end of the article. *
NodeJs
Generally, the NodeJs community has been getting larger and everybody wants a piece of it, and mostly for good reasons, my friend just finished a thirty minute Youtube video on Javascript(not Nodejs) a week ago, and he subscribed to "Team Php Slander" this week.
Like I said though, they do love it for the right reasons.
- It is fast.
- Quick to learn as we already learnt Javascript for Frontend.
- Amazing community(slightly toxic to the Php guys).
- We love to say I use MERN or MEAN stack.
Even with all the good choices, there are times when Nodejs should not be our go-to, even if we do use it, we start worrying about handling a lot of other things we won't with a different framework.😥😥
The computer is bound by two types of tasks mainly, they are simply
- I/O Bound
- CPU Bound
I/O BOUND
You have most definitely heard about I/O in the programming business, maybe you have and can't remember but it simply means input/output, something Computer teachers touch at least once in Js2 or 8th grade, not that I was listening.
In simple terms, Inputs are data received by the computer while Outputs are data sent out of the computer.
Any task that involves receiving data by the computer or sending data is typically an I/O task. Examples include reading from a database, sending requests to a network etc.
These type of tasks typically take time and increases the latency* of what we are doing, taking time does not mean you wait two weeks, but big companies spend a lot of money to save their users as low as 40ms, so every ms counts.
NodeJs is a single-threaded* non-blocking framework designed to handle these I/O tasks like a boss, and it does amazingly well at this task because of its nature, it's Event-driven* and this allows it to handle a series of events without worrying about multi-threading or thread-locks*.
Meaning multiple I/O tasks are a breeze to NodeJs, runs through them like a pro, therefore the speed we talked about up.
This is why all real-time activities favor Node Js as they should. Most of the time our mid-level tasks are I/O bound by the way, so Nodejs shines, why they are rushing Node Js developers these days.
P.s : This is not a Javascript stan account, frameworks like Tornado in Python, tend to do well in tasks like this too, I have tried it and can say it's really efficient but would not be recommended for the Google type of idea your startup has cause of the smaller community behind it, if you face an error not on stack-overflow, it's you and the frameworks developer that knows.
P.s : Other languages are not a bad choice for I/O tasks, Nodejs just does better and also saves you the complexity of handling threads and the issues that come with it
CPU Bound
I am assuming we know what a CPU is, and to cut a story short, a CPU bound task is a memory-intensive task, anything that has to do with large computing will be dragging the energy of our CPU.
These type of tasks are generally bad news for your Nodejs project, reason is the same with why it shines so well in I/O bound tasks, it is single-threaded, it is designed to handle every request extremely fast blocking out other requests in this time frame, the moment your requests are CPU bound and start taking a little time for the computer to compute it's final result, single threaded have cause problem.
The PHP guy is probably nodding and laughing at the NodeJs guy thinking, this is where I shine😂😂😂. I will leave no comment on that as I love PHP myself and will tolerate no PHP slander but Golang will generally be a really good choice in this aspect, we will discuss why maybe in a different article.
Python has also proven to do well with CPU bound tasks like Machine learning in production.
P.s : There are ways around this for Node Js developers like splitting into sub-processes and some developers even think it's a really good choice CPU Bound task, check out this article, but generally on surface level, it isn't.
CONCLUSION
Picking an appropriate Backend framework for your language makes your life easier in the long run. But do not spend too much time when the resources are limited, you can always improve later. But if you can make a choice, the type of tasks to run is something to think about.
Layman explanation of some Terms
Latency : This is simply the time it takes to process a user's request. We always want smaller latency
Scalability : This means handling more requests without sacrificing latency
Event-Driven : It means reacting to events that occur, rather than running the code line by line. An event occurs, then an action gets dispatched, here's a good read.
Thread-Lock : This is when a thread holds on to a task, so other threads cannot mess with it, here's a good read.
Top comments (4)
While this is a hotly debated topic (and I've been in more than enough debates about it)... you, my good sir/ma'am... have hit the nail on the head.
Node.JS is perfectly fine, if you only run in one CPU core and if you don't need Inter-Process Communication (IPC). That is, if you're in the perfect nirvana world of microservices.
For everyone else, the Event Driven design of Node.JS probably causes more harm than good. The difficulty for everyone not using Node.JS, is that orchestration & synchronisation is a challenge - though, tools exist no matter what language you're writing in (including the times I have to write a cronjob that works in zsh, etc).
FWIW, most of my work is in Java, and thanks to native compilation in something like Graal, we can now produce smaller Docker images & use less memory than other teams of ours that use Node.JS (and our build pipelines are ~15x quicker, thanks mostly to TypeScript compilation).
Everything has trade-offs somewhere, and that isn't limited to IT work.
Thank you..
Very true.
A few days ago, I read an article about Rust being faster than C now. Some perf charts in the article showed that PHP was slower than Node.js and Go being just a tiny bit faster than Node.js.
While I agree with you that you should choose the appropriate technology for your backend, if CPU loads are really a problem for your Node.js app, you probably get better results with C/C++/Rust (compared to Node.js) than with PHP/Go.
I agree with you.
I did not pick PHP over Node.js though, you might have misinterpreted that part.
The point of the article is not to say one is better than the other, but to make you rethink your choice with Node.js on CPU bound projects or features. I gave an example of something that might work better for you with Go. Rust, Erlang, C++, even Julia tends to do better on memory intensive apps than Node.js, Go was just one example, doesn't mean it's best.