6 ms·
It's absolutely a step back and the Node community is way too harsh on those that point this out. But they are probably making the right call by not forking Ja
by equark 14y ago
It's absolutely a step back and the Node community is way too harsh on those that point this out. But they are probably making the right call by not forking JavaScript. If you want a synchronous style its easy enough with node-fibers. The problem is mostly that there isn't a cultural consensus around a node-fibers based ecosystem of libraries.
- scriby 14y agoFor those interested in the fibers way of doing things, I recommend checking out https://github.com/scriby/asyncblock https://github.com/scriby/asyncblock. It provides an easy-to-use abstraction to get the best of both worlds (straight-line code without blocking). I don't think there really needs to be a fibers based ecosystem. Isn't it best if modules don't rely on fibers such that they can be reused in either context?
- ef4 14y agoThis is absolutely correct. The lack of consensus is the heart of the problem. There are several nice solutions (node-fibers being one), but none of them is dominant, so none of them work out of the box with everything else. I'm convinced the only way you get this kind of consensus is by building a feature into your language's standard library. This is one big reason that languages with robust "batteries included" standard libraries have been successful. It makes it so much easier to interoperate when everyone can just assume the same abstractions are always available.