Looking through the Zone API documentation, this is a reimplementation of what most Promise libraries already provide (Zones even support "then" and "catch" methods, but don't follow the chaining standard). The only new feature is "Gates," which the documentation admits are awkward and need to be revisited — and many Promise libraries already provide simple mechanisms for sharing resources similar to what Gates allow, but with more-consistent APIs. Zones also don't work several important Node-core libraries (cluster, fs, zlib, and more), whereas Promise libraries solved interop long ago.<p>Promises/A+ is already standardized and is shipping in browsers. Yes, Promises/A+ is more complicated than it needs to be, and I wish a simpler, more monadic approach had won out. But this is an unnecessary flow-control fork, and it's not even a particularly good one by comparison. If Zones were built on top of the ES6 standard, all ES6-compatible promise libraries would immediately work with it (and there are many mature ones that already exist). No existing libraries work with Zones, and the existing ones will need to be amended to add Zone-specific interop.<p>God knows nobody needs a zone-to-promise converter; there are enough ways to do asynchronous flow control as it stands. This blog post seems to hope that Zones will some day make it into Node core; I sincerely hope they don't in their current state.
I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
I highly recommend listening to JavaScript Jabber's Zone.js interview [1] with Brian Ford that came out yesterday. He mentions collaborating with this NodeJS Zones project and the possibility of convergence.<p>I also recommend watching his ng-conf talk [2] on Zone.js to get a better understanding of what zones enable.<p>[1] <a href="http://javascriptjabber.com/110-jsj-zones-with-brian-ford/" rel="nofollow">http://javascriptjabber.com/110-jsj-zones-with-brian-ford/</a><p>[2] <a href="https://www.youtube.com/watch?v=3IqtmUscE_U" rel="nofollow">https://www.youtube.com/watch?v=3IqtmUscE_U</a>
> We’re waiting eagerly for node v0.12 to be released.
> Unfortunately, the release may not happen soon since there are about 800 open bugs and about 180 pull requests waiting to be reviewed.<p>Is it a real problem? Seems that other popular projects like Ruby on Rails have a similar number of opened issues and it's not stopping them from releasing new versions.<p>Does the Node core team have any plans how to prevent this situation in the future?
Any error handling that forces me to add extra lines into my code is one I see as too obstructing. First and foremost, asynchronous exception handling and propagation, and "long" stacktraces that go with it, should be a core part of the JavaScript language, and I'm personally waiting for that to happen at some point.
In the meantime, the best solution I was able to come up with is "LAEH2". See it here: <a href="https://github.com/ypocat/laeh2" rel="nofollow">https://github.com/ypocat/laeh2</a>