Hacker News Reader

I think "always async" is the main advantage of node.

My general (perhaps wrong) impression is that other languages commonly used in backends are moving toward async io, usually through maturing libraries.

View on HN

It's not that I don't like async (I think it's a defensible choice for JavaScript), but that in my experience backend logic for e.g. e-commerce apps doesn't benefit from using it. Projects which expose services to web frontends are often implemented in an architecture where only one-shot, aggregated service calls (and often times REST-y services) are exposed to Node.js, with the actual business processing and granular service calls being implemented in eg. Java web services in a synchronous programming style. I actually like that architecture because it gives front end devs leaway to define their browser-facing head server backend, rather than enshrine a dogmatic frontend/backend architecture upfront.

It's true that other languages add async models (or emphasize those that they already have), but eg. in the case of Java you're sitting on 20 years of synchronous library and custom code, and it's not clear moving to async is worth it at this pont.

Most services that might be considered "backends" (ie databases, queues, cloud services) end up being in written in languages that can safely use async techniques for I/O and still use real threading or some other method for managing CPU bound problems.

Many of the applications people think of for node.js end up being "glue", much like python, and can live within this constraint for a very long time, where the I/O optimization is a nice benefit.

Reply on news.ycombinator.com