{"action":"created","issue":{"url":"https://api.github.com/repos/jpaulm/jsfbp/issues/14","labels_url":"https://api.github.com/repos/jpaulm/jsfbp/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/jpaulm/jsfbp/issues/14/comments","events_url":"https://api.github.com/repos/jpaulm/jsfbp/issues/14/events","html_url":"https://github.com/jpaulm/jsfbp/issues/14","id":57388972,"number":14,"title":"jsfbp that doesn't use fibers?","user":{"login":"tlrobinson","id":18193,"avatar_url":"https://avatars.githubusercontent.com/u/18193?v=3","gravatar_id":"","url":"https://api.github.com/users/tlrobinson","html_url":"https://github.com/tlrobinson","followers_url":"https://api.github.com/users/tlrobinson/followers","following_url":"https://api.github.com/users/tlrobinson/following{/other_user}","gists_url":"https://api.github.com/users/tlrobinson/gists{/gist_id}","starred_url":"https://api.github.com/users/tlrobinson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tlrobinson/subscriptions","organizations_url":"https://api.github.com/users/tlrobinson/orgs","repos_url":"https://api.github.com/users/tlrobinson/repos","events_url":"https://api.github.com/users/tlrobinson/events{/privacy}","received_events_url":"https://api.github.com/users/tlrobinson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":14,"created_at":"2015-02-11T22:40:41Z","updated_at":"2015-02-17T20:10:48Z","closed_at":null,"body":"Fibers are neat, but the majority of node.js developers don't and won't use them, and they don't work in browsers at all. It would be nice if we could provide a \"classical FBP\" system that works using standard JavaScript APIs.\r\n\r\nActually, after reading http://www.jpaulmorrison.com/fbp/noflo.html I'm pretty confused about how JSFBP is considered more \"classical\" than NoFlo. That page suggests the key difference is that NoFlow is single-threaded (because JavaScript is single-threaded) and thus not suitable for CPU-intensive programs, but then admits JSFBP is also single-threaded. So is the main difference actually the synchronous vs asynchronous style of programming?\r\n\r\nSelective reading of ports and backpressure can both be accomplished in an asynchronous style. For example, Node-style Streams have `pause` and `resume` methods for handling backpressure. The port could buffer up to a fixed number of IPs then call `pause` on the stream when the buffer fills up. The port could have a `read` method that takes a callback (or returns a promise) which gets called when the next IP is available, and calls `resume` on the stream if the buffer is no longer.\r\n\r\nTo take advantage of multiple cores you could use something like WebWorkers, though I think a generic system based on a standard IPC mechanism (e.x. ZeroMQ) and serialization protocol (e.x. Protocol Buffers) would be even cooler, allowing you to write components in any language, or even distribute processes across machines.\r\n\r\nBut anyway, there are several options for sync and async styles in JavaScript:\r\n\r\nAsynchronous style:\r\n\r\n1. EventEmitters or Streams (see above)\r\n2. raw callbacks: probably Node-style `callback(err, result)` callbacks. This is my least favorite option, but is still the most popular style in Node.js. I probably wouldn't bother with this.\r\n3. promises: promises are gaining a lot of traction in the JavaScript world lately, but they're still a very asynchronous style\r\n\r\nSynchronous style:\r\n\r\n1. generators (ES6, can be transpiled to ES5): not available in browsers except via transpiling\r\n2. await (ES7, can be transpiled to ES5): lets you write synchronous style code that `await`s on promises\r\n3. some other synchronous-style transpiler: e.x. streamline.js\r\n\r\nAlso this may be useful relevant reading:  https://github.com/kriskowal/gtor\r\n\r\n\r\nEDIT: task.js is another possibility: http://taskjs.org/"},"comment":{"url":"https://api.github.com/repos/jpaulm/jsfbp/issues/comments/74742939","html_url":"https://github.com/jpaulm/jsfbp/issues/14#issuecomment-74742939","issue_url":"https://api.github.com/repos/jpaulm/jsfbp/issues/14","id":74742939,"user":{"login":"tlrobinson","id":18193,"avatar_url":"https://avatars.githubusercontent.com/u/18193?v=3","gravatar_id":"","url":"https://api.github.com/users/tlrobinson","html_url":"https://github.com/tlrobinson","followers_url":"https://api.github.com/users/tlrobinson/followers","following_url":"https://api.github.com/users/tlrobinson/following{/other_user}","gists_url":"https://api.github.com/users/tlrobinson/gists{/gist_id}","starred_url":"https://api.github.com/users/tlrobinson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tlrobinson/subscriptions","organizations_url":"https://api.github.com/users/tlrobinson/orgs","repos_url":"https://api.github.com/users/tlrobinson/repos","events_url":"https://api.github.com/users/tlrobinson/events{/privacy}","received_events_url":"https://api.github.com/users/tlrobinson/received_events","type":"User","site_admin":false},"created_at":"2015-02-17T20:10:47Z","updated_at":"2015-02-17T20:10:47Z","body":"@alfa256 I don't believe `yield` can be moved inside of `receive` because it's a special keyword for use in generator functions (`function* whatever(){}`), but I don't think that's desirable anyway. Ideally the FBP kernel/framework should work without generator functions, but would support them as an extra layer of syntactic sugar in components.\r\n\r\nNote that the only code in my proof of concept that's aware of generator functions or `yield` is the component itself. I think it should stay that way, it's up for debate."}}