

Generators in Firefox now 22 times faster - jsnell
https://wingolog.org/archives/2014/11/14/generators-in-firefox-now-twenty-two-times-faster

======
general_failure
On an aside: what javascript really needed was async/await instead of
generators. I have no clue why something as abstract as generators is being
pushed.

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?

~~~
thezilch
generator = async

yield = await

Also, async/await themselves have a proposal accepted into ES7:
[https://github.com/lukehoban/ecmascript-
asyncawait](https://github.com/lukehoban/ecmascript-asyncawait)

~~~
general_failure
From what I can tell, The generator pattern requires you to make all your
functions generators. My understanding is that you can use yield only inside
generators.

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?

~~~
munificent
> My understanding is that you can use yield only inside generators.

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.

~~~
saurik
This is only true if you are building the implementation of async/await as a
compilation hack (maybe a "transpiler", as people now like to say) rather than
as a feature of the virtual machine. You don't need "threads" to implement
this, you just need the ability to work with multiple stacks and then have use
the techniques from coroutines. (Some people call this "green threads", but
that's not the kind of "threads" you would refer to when saying C# has
threads.)

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

~~~
emn13
To condense what you're saying to its core: you can avoid the need to make
callers async if you simply make everything async.

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.

------
barbudorojo
The author shows a micro benchmark in which the state of the generator is a
single variable and discuss the history of generators from the first tier
(interpreter code) to the second tier (using the Jit). Perhaps some more
complete examples with should be analyzed since the case discussed here seems
to be the simplest and so the 22 times faster perhaps doesn't hold except in
very simple cases.

~~~
lucian1900
The benchmark is mostly superfluous anyway. It's enough for me to know that
generators no longer bail out to the interpreter.

------
amelius
Of course generators are completely unusable until other browsers start to
support them.

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.

[1]
[https://facebook.github.io/regenerator/](https://facebook.github.io/regenerator/)

~~~
rictic
Generators will be on by default (not behind a flag) in Chrome 39, which will
be released to stable in the next couple of weeks I believe.

[https://www.chromestatus.com/feature/4959347197083648](https://www.chromestatus.com/feature/4959347197083648)

~~~
amelius
But what about IE?

~~~
niutech
IE is lagging behind, as usual. See the HTML5 Test.

~~~
dmethvin
That's not true. If you look at [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/) you'll see IE11 preview
(their "canary") has more green than any other browser including Chrome or
Firefox. Yes, even more than Firefox nightly or Chrome canary.

~~~
magicalist
> _their "canary"_

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.

------
hartator
Nowadays, every time!, I am hearing some news about Firefox getting better, I
feel that's a lie. I feel Firefox is actually getting worse and worse, from
disappointment to disappointment. Either when it's a new feature or new UI
modifications (I loved to have a separation between the URL and the Google
search != Chrome), or new web services (Mozilla "Labs"?), or new dev. tool
(Firefox inspector is at best full of small bugs and seems to be an ugly copy
and paste from Firebug). Hopefully the Mozilla CEO being fired will make
things better but I feel now being mediocre it's new culture trend @ Firefox.

~~~
tracker1
I'm not sure I completely agree... Honestly, there are many developers each
working on stuff they are either required to do, or want to do. The only time
I find the unibar in chrome annoying is when I'm searching for something
specific to google... and effectively have to type google twice (first time
sets the search site to google).

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.

