Generators in Firefox now 22 times faster
wingolog.org
wingolog.org
I mean the bane of javascript is the whole async programming with callbacks. Instead of solving the specific problem, this solves some problem which I don't see most apps having. Can someone in the know how care to explain?
yield = await
Also, async/await themselves have a proposal accepted into ES7: https://github.com/lukehoban/ecmascript-asyncawait
For example, var data = await downloadSomething();
function *downloadSomething() { // check somethings
return await http.get('foo.com', function (result) { yield result; });The above won't work since the callback to http.get is not a generator.
You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback.
Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async.
> Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.
I imagine the reason they avoided doing this was to not require browser vendors to make half their browser internals safe for usage in reasonable coroutines ;P. I can also see them having wanted to guarantee that the feature could be implemented using a transpiler rather than requiring it to be a native feature of the browser, and generators being explicitly marked at both the declaration and call sites (or async await with the limitations you mention) have that property by allowing a continuation passing transform to be applied to the generator's code. (Which could be applied to all code, of course, but not native browser code. edit: Well, you could so that as well, but it would violate other assumptions about how the code is supposed to work, and isn't something anyone has infrastructure to accomplish ;P.)
In essence, that's the choice Go made. It's certainly simpler for the programmer. It probably makes optimization trickier, and it probably makes efficient parallelism harder (since real threads are completely abstracted away, the VM needs to understand when to start real threads, and when to use promises).
For a language like javascript, it sounds like these tradeoffs are certainly worth it.
It's a compile-time transform that hoists parts of your function into independently scheduled asynchronous tasks & task callbacks. So it's essentially automatic CPS + promises. That's why functions are tagged as 'async' or not-async in C#; if they are 'async' they produce a promise instead of a value.
On a related note, part of C#'s async/await infrastructure is a scheduling system so that callbacks can be configured to run on a specific thread - i.e. you can kick off async work on the UI thread and the callbacks will run there, instead of on the threadpool thread that completed the work.
Forget about Dart. :-(
Most good JS coders never even have 'callback pyramids'. The pyramid is a symptom of
A) bad modularity and encapsulation in your code and
B) lack of clarity on which tasks depend on one another.
The author ends up with a long 'laundry list' of things that happen to work in a certain order, and needs to ensure they happen in that exact order, using a pyramid.
Having await/async will make node.js programming infinitely better. Lots of programming tasks in server side are really 'step' driven i.e doing a lot of things one by one. Of course, at this point someone will point me to 'async' and 'step' and 'q' modules but that's not the point.
The bane of JS really isn't async programming- it is branching async logic and this is exactly the problem that generators will solve. Moreover, libraries can choose to wrap them into callbacks so they will be backwards compatible.
To get an idea of what this will look like, check out this library I wrote for Luvit (Nodejs for Lua) which relies on callbacks and coroutines to make async code look sync.
This was the rationale behind Kal (https://github.com/rzimmerman/kal/), which effectively provides "await" (called "wait for") in ES5.
That is, unless you use a compiler to convert your generator code into more mundane javascript [1]. It would be nice to see these "emulated generators" in the comparison too.
while that's sort of true, the big distinction is that the features in their "canary" aren't going to hit "stable" for another year or so, which is a lot of iterations of Firefox and Chrome in the meantime.
However, it is fantastic to see where they're headed with IE12.
I'm actually slightly annoyed that I have to run the dev version of node and the --harmony flag to get the new JS options server-side... but seeing what co/koa do with generators is really nice... I'm stuck transforming my client-side scripts for a while... it will be nice when I don't need to browserify/es6ify anymore.
As for the developer tools, I do wish it was closer to either the chrome dev tools or firebug myself, it looks too much like the IE10+ tools, which I find annoying. But that's a matter of preference.
This is a matter of raw performance, not a subjective UI.. FF has made a lot of effort into improving JS at its' core... Chrome has worked to expanding the DOM in interesting ways. IE has taken a pragmatic approach to refining what comes from both, though having their own issues. The browser ecosystem today is so much better than it has ever really been, and I couldn't be happier about it.
You can relatively easily create your own skin against a Firefox base. AFAIK it's still all XUL wrapped around a web view, and pretty easy to get into, admittedly last time I tried was 6+ years ago. Chrome is still my favorite browser, but I do appreciate what the others are doing... the best ideas do get copied, and it works.