3 ms·

It's not clear to me that you actually read the article since a large part of it is about elegantly dealing with streams of UI events such as mouse movement wit

It's not clear to me that you actually read the article since a large part of it is about elegantly dealing with streams of UI events such as mouse movement without resorting to callbacks. Not sure how multithreading even applies here. But if you want to talk about multithreading the model described is exactly the one embraced by a new up and coming language called Go - it's users love this stuff precisely because it's more readable than writing code with explicit threads and concurrent queues.

neilellis 12y ago
So I'll avoid the potential language flame war as best as I can. It is the sync on async part I am talking about (see code snippet in sub thread). The layering of synchronous constructs on an asynchronous model which only exists to support the single threaded browser model is getting very convoluted. That's the part I'm talking about. It is perfectly reasonable and trivial to support a multithreaded model in the browser if the multi-threaded code does not alter shared state. Which obviously is the intention of Web Workers and in there case there state seems to be primarily the DOM, I just feel that this is the direction we and browser developers should be looking into more and where the effort needs to be. And that Web Workers are part of the story not the story. In my experience concurrency can be kept to a remarkably simple level if either the developer or the language/framework author are willing to follow some simple constraints. In my ideal world: var x= concurrent(function(x) { return doSomething(x); })(1000); Would execute the function without any closure or access to globals (like the DOM). Now we have no shared state, so we could run this function in a parallel thread. Now add back access to stateless resources like HTTP requests and we're rocking and rolling. Web Workers just seem to be a heavy handed approach to achieving this. If there is a framework or method available to achieve this and I have missed it out of ignorance please someone correct me and show how this can be done simply. My goal is to have simpler code not to win an argument.

neilellis 12y ago

So I'll avoid the potential language flame war as best as I can. It is the sync on async part I am talking about (see code snippet in sub thread). The layering of synchronous constructs on an asynchronous model which only exists to support the single threaded browser model is getting very convoluted. That's the part I'm talking about. It is perfectly reasonable and trivial to support a multithreaded model in the browser if the multi-threaded code does not alter shared state. Which obviously is the intention of Web Workers and in there case there state seems to be primarily the DOM, I just feel that this is the direction we and browser developers should be looking into more and where the effort needs to be. And that Web Workers are part of the story not the story. In my experience concurrency can be kept to a remarkably simple level if either the developer or the language/framework author are willing to follow some simple constraints. In my ideal world: var x= concurrent(function(x) { return doSomething(x); })(1000); Would execute the function without any closure or access to globals (like the DOM). Now we have no shared state, so we could run this function in a parallel thread. Now add back access to stateless resources like HTTP requests and we're rocking and rolling. Web Workers just seem to be a heavy handed approach to achieving this. If there is a framework or method available to achieve this and I have missed it out of ignorance please someone correct me and show how this can be done simply. My goal is to have simpler code not to win an argument.