undefined | Better HN

0 pointscloakandswagger11y ago0 comments

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.

0 comments

bhouston11y 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.

tracker111y 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.

cloakandswaggerOP11y 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.

jessaustin11y 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.

tracker111y 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.

uptownJimmy11y 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."

j / k navigate · click thread line to collapse

0 comments

bhouston11y 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.

tracker111y 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.

cloakandswaggerOP11y ago

I worked on some web-based project management software which was highly CPU-bound.

jessaustin11y 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.

tracker111y ago

uptownJimmy11y 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.

j / k navigate · click thread line to collapse