4 ms·

It cites the reasons for Node overload as: - The convenience of using the same language in the client and server - The speed of Node.js It unfortunately does

It cites the reasons for Node overload as: - The convenience of using the same language in the client and server - The speed of Node.js It unfortunately does not state why it shouldn't be used in the server, or offer any more suitable alternatives.

arcturus17 6y ago
Well it does mention that its single-threaded nature makes it a poor choice for heavy compute workloads, which I agree with. I also think it’s fine for pretty much everything else.
- zumachase 6y ago
  I'm not sure I would agree with this. As with all things, it depends on the task, but "compute heavy" these days means likely working with a distributed framework that abstracts away the underlying process architecture, letting the user define lambda-esque tasks which are deployed across a stream/batch processing model. I think a much better critique would be that the lack of fine grained primitives, and the surrounding ecosystem, are not the best choice for compute heavy tasks.
  - arcturus17 6y ago
    It doesn’t have multithreading, period. You can compute in parallel and work around it by using serverless functions or worker threads or whatever, but often it feels like you’re going against the grain and/or reinventing the wheel. I definitely see the merit in preferring another language with a clear, native multithreading model - and with perhaps significantly better general performance to boot. If anything, the critique in my opinion misses how the Node web frameworks tend to be really unopinionated and non-prescriptive which can be great for some teams and projects but really bad for others (they do mention that NestJS is a technology to watch and that they use it widely, so I actually think they’re of the same opinion)
manojlds 6y ago
Not sure if you read it fully or not: > When Node.js became popular, it was the first major framework to embrace a nonblocking programming model which made it very efficient for IO-heavy tasks. (We mentioned this in our write-up of Node.js in 2012.) Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js.
- orange8 6y ago
  I did read it, just looks like I failed to fully parse that long winding sentence. So it is not a good choice for compute-heavy workloads, like a webapp that does video/image processing? Multi-threading could be added to the runtime for back-end applications (https://news.ycombinator.com/item?id=15498219 https://news.ycombinator.com/item?id=15498219)

arcturus17 6y ago

Well it does mention that its single-threaded nature makes it a poor choice for heavy compute workloads, which I agree with. I also think it’s fine for pretty much everything else.

zumachase 6y ago
I'm not sure I would agree with this. As with all things, it depends on the task, but "compute heavy" these days means likely working with a distributed framework that abstracts away the underlying process architecture, letting the user define lambda-esque tasks which are deployed across a stream/batch processing model. I think a much better critique would be that the lack of fine grained primitives, and the surrounding ecosystem, are not the best choice for compute heavy tasks.
- arcturus17 6y ago
  It doesn’t have multithreading, period. You can compute in parallel and work around it by using serverless functions or worker threads or whatever, but often it feels like you’re going against the grain and/or reinventing the wheel. I definitely see the merit in preferring another language with a clear, native multithreading model - and with perhaps significantly better general performance to boot. If anything, the critique in my opinion misses how the Node web frameworks tend to be really unopinionated and non-prescriptive which can be great for some teams and projects but really bad for others (they do mention that NestJS is a technology to watch and that they use it widely, so I actually think they’re of the same opinion)

manojlds 6y ago

Not sure if you read it fully or not: > When Node.js became popular, it was the first major framework to embrace a nonblocking programming model which made it very efficient for IO-heavy tasks. (We mentioned this in our write-up of Node.js in 2012.) Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js.

orange8 6y ago
I did read it, just looks like I failed to fully parse that long winding sentence. So it is not a good choice for compute-heavy workloads, like a webapp that does video/image processing? Multi-threading could be added to the runtime for back-end applications (https://news.ycombinator.com/item?id=15498219 https://news.ycombinator.com/item?id=15498219)