The idea in Node is that modules are simple, replaceable and composable: Express is a simple facade to Node's HTTP server (wrapping raw HTTP requests and providing a middleware framework) on which you can plug in new middleware (again, small modules) which do a single job well.
You can build full frameworks out of this system without the hurdle of these frameworks being monsters: just plug in the appropriate middleware for each relevant route and you're done (and, thanks to Connect/Express this plugin will work in every framework using Express as a building block).
There's nothing wrong with it, and it comes with many advantages.
So, to answer your question: yes. Node is not responsible of handling error conditions because that's not Node's job: it's part of userland. Node is just a simple IO engine, not a web server!
The full stack looks like this (similar to RoR's):
That argument is a cop out, because I can apply it to lots of other things that node does do.
Why is the "string" implementation part of Node, and not something that everybody can choose to implement with their own microlibrary? Because strings are something that need to pass between modules all the time, and interoperability dictates that we should all pass the same kind of strings.
Likewise, exceptions flow between modules. They are necessarily part of the interface that other people's code will expose to yours. That's why Exception is part of Node, and that's why it's Node's responsibility to give us constructs to deal with those exceptions cleanly. It tries to do so, with try/catch/finally (which only works on purely synchronous code), and Domains (which can work with asynchronous code, but only if all your dependencies are careful to also use Domains to clean up their references, which most don't).
> Node was created to not handle error conditions? How is that defensible in a HTTP server?
It depends on what you expect, giving the programming language, runtime, and the philosophy of those who developer the former, latter, or both. Erlang is famous for the "let it crash" tenet [0], and I doubt you get something most programmers are comfortable with. However, I doubt most programmers I know (I will not assume about others) can scale to WhatsApp, which more or less runs a REST API on Erlang to great scale. [1]
This is not to say the two things are perfectly related, but there are different methods and philosophies around error handling and conditions. Some are comfortable with Node, others are not.
The idea in Node is that modules are simple, replaceable and composable: Express is a simple facade to Node's HTTP server (wrapping raw HTTP requests and providing a middleware framework) on which you can plug in new middleware (again, small modules) which do a single job well.
You can build full frameworks out of this system without the hurdle of these frameworks being monsters: just plug in the appropriate middleware for each relevant route and you're done (and, thanks to Connect/Express this plugin will work in every framework using Express as a building block).
There's nothing wrong with it, and it comes with many advantages.
So, to answer your question: yes. Node is not responsible of handling error conditions because that's not Node's job: it's part of userland. Node is just a simple IO engine, not a web server!
The full stack looks like this (similar to RoR's):
Node (Async IO) -> Express (Request facade) -> Connect (Middleware handling) -> Middleware and/or Framework -> Your app.