3 ms·

Looking through the Zone API documentation, this is a reimplementation of what most Promise libraries already provide (Zones even support "then" and "catch" met

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

piscisaureus 12y ago
I'm sorry if it wasn't clear enough from the blog, but the attempt here is not to write a flow control library that solves the callback hell problem like promises does. You should think of it more as an asynchronous try-catch block, where resources created in the "try" block are automaticially cleaned up. I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co https://github.com/visionmedia/co for example.
- reissbaker 12y ago
  Okay. But Promises already provide asynchronous try/catch blocks, and you could have used those as the basis of your API (and as first-class objects that get returned), rather than inventing a new API and set of objects. > I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co https://github.com/visionmedia/co for example. Generators and promises are both types of flow control that will be used in the future: they're both in the ES6 standard. In fact, visionmedia/co already supports promises.
  - piscisaureus 12y ago
    A Zone object could be a "subclass" of a Promise. It's something I have considered but I didn't think it'd be necessary for the first release. > But Promises already provide asynchronous try/catch blocks They do, if all you use is modules that return promises, and the node ecosystem currently has many modules that don't. For example: zone.create(function MyZone() { // Within MyZone setTimeout(function() { // Within MyZone throw new Error("Oh noes!"); }); }).catch(function(err) { // Back in the parent zone. // Handle the error here. }); The above won't work with promises unless you use a promisified version of setTimeout and return that promise from the constructor function. Conversely, with zones, chaining callbacks is hard to define conceptually: zone.create(function MyZone() { // In MyZone }).then(function() { // Which zone are we in? }).then(function() { // Which zone are we in? }); But if you have a great idea here, bring it on.
    - reissbaker 12y ago
      From an admittedly brief look through the source, it looks like the zone module does two things: 1. Creates the "Zone" and "Gate" abstractions, and, 2. Monkeypatches Node to use Zones and Gates. To make setTimeout work, the zone module monkeypatches global.setTimeout and replaces it with a version that uses Zones and Gates. Rather than do that, what you could do is not use Zones and Gates at all, and monkeypatch global.setTimeout and replace it with a version that uses Promises. And: there, Promises work with setTimeout. Just as easily as Zones and Gates do. (Alternatively, what many Promise libraries do is offer ways to generate "promisified" versions of individual non-Promise functions and encourage you to call those instead, rather than monkeypatching globals.) My objection to zone is just the new abstractions, Zones and Gates. They don't seem to offer much (anything?) over Promises, and they seem needlessly incompatible with them. Instead of the two-part module, where you introduce Zones and Gates and also monkeypatch everything to use them, you could just have a one-part module that monkeypatches everything to use Promises. It would be less code and it would interoperate with the existing JS ecosystem. I don't have a particular love for the Promise abstraction: it's just that everyone is going to have to learn and work with Promises anyway (since they're in ES6, and already in V8), and there's no reason to invent a new abstraction for asynchronous try/catch when one already exists. There are lots of Promise-supporting libraries, and no Zone-and-Gate-supporting ones, save for zone itself. Why bother with the fork?

piscisaureus 12y ago

I'm sorry if it wasn't clear enough from the blog, but the attempt here is not to write a flow control library that solves the callback hell problem like promises does. You should think of it more as an asynchronous try-catch block, where resources created in the "try" block are automaticially cleaned up. I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co https://github.com/visionmedia/co for example.

reissbaker 12y ago
Okay. But Promises already provide asynchronous try/catch blocks, and you could have used those as the basis of your API (and as first-class objects that get returned), rather than inventing a new API and set of objects. > I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co https://github.com/visionmedia/co for example. Generators and promises are both types of flow control that will be used in the future: they're both in the ES6 standard. In fact, visionmedia/co already supports promises.
- piscisaureus 12y ago
  A Zone object could be a "subclass" of a Promise. It's something I have considered but I didn't think it'd be necessary for the first release. > But Promises already provide asynchronous try/catch blocks They do, if all you use is modules that return promises, and the node ecosystem currently has many modules that don't. For example: zone.create(function MyZone() { // Within MyZone setTimeout(function() { // Within MyZone throw new Error("Oh noes!"); }); }).catch(function(err) { // Back in the parent zone. // Handle the error here. }); The above won't work with promises unless you use a promisified version of setTimeout and return that promise from the constructor function. Conversely, with zones, chaining callbacks is hard to define conceptually: zone.create(function MyZone() { // In MyZone }).then(function() { // Which zone are we in? }).then(function() { // Which zone are we in? }); But if you have a great idea here, bring it on.
  - reissbaker 12y ago
    From an admittedly brief look through the source, it looks like the zone module does two things: 1. Creates the "Zone" and "Gate" abstractions, and, 2. Monkeypatches Node to use Zones and Gates. To make setTimeout work, the zone module monkeypatches global.setTimeout and replaces it with a version that uses Zones and Gates. Rather than do that, what you could do is not use Zones and Gates at all, and monkeypatch global.setTimeout and replace it with a version that uses Promises. And: there, Promises work with setTimeout. Just as easily as Zones and Gates do. (Alternatively, what many Promise libraries do is offer ways to generate "promisified" versions of individual non-Promise functions and encourage you to call those instead, rather than monkeypatching globals.) My objection to zone is just the new abstractions, Zones and Gates. They don't seem to offer much (anything?) over Promises, and they seem needlessly incompatible with them. Instead of the two-part module, where you introduce Zones and Gates and also monkeypatch everything to use them, you could just have a one-part module that monkeypatches everything to use Promises. It would be less code and it would interoperate with the existing JS ecosystem. I don't have a particular love for the Promise abstraction: it's just that everyone is going to have to learn and work with Promises anyway (since they're in ES6, and already in V8), and there's no reason to invent a new abstraction for asynchronous try/catch when one already exists. There are lots of Promise-supporting libraries, and no Zone-and-Gate-supporting ones, save for zone itself. Why bother with the fork?