He mentions using CSP with JavaScript:<p>> It's safe to say that it's becoming quite popular (and validated) and I think we need to try it out in JavaScript.<p>To be clear, and he mentions that Clojure has core.async, it's been done in JavaScript (if you will) already via ClojureScript.<p>David Nolen has done a series of posts on it starting at [1].<p>[1] -- <a href="http://swannodette.github.io/2013/07/12/communicating-sequential-processes/" rel="nofollow">http://swannodette.github.io/2013/07/12/communicating-sequen...</a><p>EDIT: And I should have finished reading the post before posting this. He does mention David Nolen's series of posts on ClojureScript and core.async
What would be nice as an addendum to this, especially with the likes of browserify and webpack for node and the browser would be a syntax to start an async channel in a new process/webworker...<p><pre><code> var ch = new echan('moduleName');
</code></pre>
Where the moduleName would be a module that exports a single function that receives two channels.. in, and out for a request/response pattern. An "easy" level of abstraction here where the request/response is only going to pass what works with JSON.stringify/parse, removing circular references.<p>It could work really well for worker handlers... It only needs to be an abstraction around the csp interfaces, as well as the current implementations for web workers and forked processes in node.js<p>More advanced scenarios could use 0mq for passing a worker to multiple processes... all of that said, it's just an idea.<p>I think where this lines up very cleanly is as a means of communication with React and flux.
I translated the pingpong example to use events instead of CSP. <a href="https://gist.github.com/aynik/94c9f3d01139986d2b91" rel="nofollow">https://gist.github.com/aynik/94c9f3d01139986d2b91</a>
Even mentioned transducers, cool! But, I was hoping for a treatment of CSP and react/flux. jlongster teased us about that here[1]. Maybe the next post in the series? (plz?)<p>1. <a href="https://justin.harmonize.fm/development/2014/08/05/om-and-flux.html#comment-1532327194" rel="nofollow">https://justin.harmonize.fm/development/2014/08/05/om-and-fl...</a>
My understanding of Javascript is that it is essentially single-threaded. Maybe I am mistaken, but if that is indeed the case, how does something like JS-CSP or Clojurescript's core.async accomplish concurrency? Has there been a change in the underlying Javascript? Is it just using tricks to make single-thread act like multi-thread?
Why doesn't he state what CSP is upfront, requiring the reader to visit Wikipedia to know what it is?<p>Buzz words and acronyms are getting out of hand on the web.
You've got to wonder why exactly we still (in 2014) have to contort ourselves around a single threaded model. So that we end up with this level of complexity.<p>JavaScript is great with data but is becoming a monstrosity when it comes to concurrency.<p>Can we all stop and have a deep look at how other languages deal with concurrency. I have (like many of you) used many different languages and have played with several different concurrency models. The bottom line for me is that multiple threads + concurrency frameworks (i.e. no exposed concurrency primitives) are still the best solution.<p>I appreciate JavaScript is trying to avoid deadlocking etc. but in modern concurrency frameworks this just isn't an issue.<p>Seriously we're now contorting ourselves around dogma. Please browser folk, come up with a decent solution to save us all of this.<p>VOTED DOWN FOR HERESY :-)