Hacker News new | ask | show | jobs
by cloakandswagger 4210 days ago
I see this more as a return to reality from Node.js's astronomical levels of hype.

The use cases for a single-threaded web server are specific and limited in the real world. Node.js will continue to solve those use cases (simple web server for static content or I/O bound apps) but the resultant decline will lead some to believe that the framework is dying.
3 comments
bhouston 4210 days ago
> The use cases for a single-threaded web server are specific and limited in the real world.

We use Node.JS to run https://Clara.io. Clara.io isn't at all a simple website. I think you are underestimating Node.JS's flexibilities and capabilities.

link
tracker1 4210 days ago
Perhaps you could name some website/app servers that aren't mostly i/o (or event-timing) bound? I wouldn't say the use cases are limited at all.

You can always run multiple process instances, and communication between processes isn't really so different in practice than inter-server communication... Which just means you are scaling horizontally by design earlier in development.

link
cloakandswagger 4210 days ago
I worked on some web-based project management software which was highly CPU-bound.

A typical scenario would be the application querying a database for financial figures, doing a large amount of calculations on those figures and then generating an HTML report from them. I imagine any application with large amounts of business logic like this will be the same.

link
jessaustin 4210 days ago
Could you describe the sorts of calculations those were? Are these regressions or similar? Do PMs really look at that sort of thing? Maybe they were basing a TSP on the latest financial figures? b^)

It seems possible that was a mostly IO-bound system, and the things which could have been conceivably CPU-bound should just have been batched and cached.

link
tracker1 4207 days ago
I would suggest that what you are describing is the exception to the rule... Most queries, in such a case could either be done in the database or pushed to the browser... Generally if you're doing something CPU bound that isn't video processing or gaming, you push that out of process through a worker queue anyhow.
link
uptownJimmy 4210 days ago
I have come to believe that the truth about Node is somewhere in the middle: not severely limited, as you imply, but probably not fit to dominate the server ecosystem, either.

I develop on .NET all day, every day, building enterprise CRUD apps with fairly cutting-edge capabilities, for small-to-medium-sized companies. I suspect that Node would fit the server role quite handily if we bothered to port our hand-rolled client-side framework to it. But, as the lady said: "Ain't nobody got time for that."

link