you shouldn't ever use nodejs anyway
dependencies
slow performance
shit language was never designed for backend anywa
3.00000000000000000000000003
shit libraries
bloated
each line is a reason btw
even when not activating, it's still slower than compiled languages
Speed is a nonsensical reason to not use node. JS vms are pretty fast and the kind of applications that use node are mostly IO bound, which V8's async system is pretty good at.
It is for me when it comes to restarting a service for maintenance reason or for complex code
Thats not how you should be running servers to be honest.
"I won't get downtime because I can restart a server ultra fast" really isn't a sensible plan, even if your server is the fastest thing in the world written in rust
Either you architect your devops to allow zero downtime (multiple nodes, cycling restarts, multi DC maybe) or you live with having to do maintenance on/off hours.
Startup time of node has no impact on that.
As always basically everything has an exception at Google scale and it's not like there aren't valid potshots to take at Node and Javascript, but as a platform it really does excel at IO heavy tasks.
wdym heavy IO tasks?
Well, for example, the majority of the time a webserver spends handling a request is spent in IO. Waiting for a database to respond, sending data to the user, receiving a request.
Maybe it's a websocket thing and you receive from one user and broadcast to others. Either way, the time spent handling that almost always dominates the amount of time spent actually running code in the js thread.
The model of "okay, here is this IO task - give it to another thread and tell me what the results are when it's done" works out pretty well performance wise.
Also, the cold startup for node is only really bad if you compare it to Rust, C, and C++ which isn't really fair.
https://medium.com/@nathan.malishev/lambda-cold-starts-language-comparison-%EF%B8%8F-a4f4b5f16a62
C and C++ require pretty huge tradeoffs in terms of developer speed and possibility of errors, so they really aren't targeted at the same users as node and rust - well rust is a lot better but being super statically typed still has tradeoffs with how quick you can change things which means it won't be the right choice for every "webserver" use case.
okay, here is this IO task - give it to another thread and tell me what the results are when it's done
so bringing go into the equation, go routine workers
Yeah I think go's async model is better too.
But go isn't that monumentally faster than node that you can say "forget node it's too slow" because it really isn't.
Neither is python for that matter. Though python's async and package management story are a lot worse , it is still the reigning king of glue languages.
Some critical path too slow?
Rewrite it in Rust, join the meme.
Python will keep on chugging.
I mean, the GIL stinks, but it's still not "painfully" slow.