11 ms·
The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism
by edtechre 15y ago
The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server.
NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.
- jrockway 15y agoNodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.
- sausagefeet 15y agoClearly it's not that easy unless you plan for it from the beginning. One benefit of Erlang is that you have to structure you code like a distributed application. You can mess that up, but it's harder.
- ankrgyl 15y agoThat works really well for handling requests for HTML pages, because they tend to render independently of one other. However, you run into trouble when you to make "Nodes" communicate, and the comment that the article is addressing specifically mentions interprocess communication.
- mcantelon 15y agoWith Node you have to manage the 4 cores if you're doing something where they need to communicate.
- thesz 15y agoImagine your app has 16GiB of precomputed tables in memory...
- strmpnk 15y agoNode.js has a heap size limit. One of the biggest weaknesses IMO well before people complain about CPU cores.
- tibbe 15y agoThis allows you to serve more clients simultaneously, but not to serve any given client faster i.e. you get higher throughput but not lower latency.
- khookie 15y agoThere is longevity in nodejs. As long as Javascript remains king on the client-side, you can pretty much guarantee nodejs will have a future.
- ajessup 15y agoSince the early days of node there has been a proposal to dispatch tasks via the WebWorker API, with a callback - as is currently done for calls to OS subsystems. Sounds like that would be a great way of dispatching CPU intensive tasks without breaking the semantics of Node. What happened to this?
- IsaacSchlueter 15y agoSince the early days of node? Node's first commit: commit 9d7895c567e8f38abfff35da1b6d6d6a0a06f9aa Author: Ryan <ry@tinyclouds.org> Date: Mon Feb 16 01:02:00 2009 +0100 add dependencies How old is Erlang? 25 years or so? > What happened to this? There's been some preliminary stuff on giving spawned node processes a more slick API, with the intent of then being able to optimize them in some way. Whether or not it'll end up at the WebWorker API is yet to be seen, but that'd certainly fit with node's "don't reinvent BOM conventions where they fit" pattern.
- cwp 15y agoI used the word "gobbledygook" because the article is poorly written, not because I think he's wrong to criticize Node. Reread the paragraph on Node and tell me it doesn't meet the Wikipedia definition: "text containing jargon or especially convoluted English that results in it being excessively hard to understand."
- moe 15y agopoorly written I had no trouble understanding the paragraph that you complain about and found the article to be very well written. Where do you see excessive jargon or convolution?