

ECMAScript 6 support in Mozilla - matt42
https://developer.mozilla.org/en/docs/Web/JavaScript/ECMAScript_6_support_in_Mozilla

======
pjmlp
This is an area where Mozilla is ahead of Chrome in terms of support.

[http://kangax.github.io/es5-compat-
table/es6/](http://kangax.github.io/es5-compat-table/es6/)

Not surprising, given Google's stance for other languages.

~~~
ahoge
> _Not surprising, given Google 's stance for other languages._

No, the reason is that Mozilla just added lots of stuff way before it got into
the ES specs.

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/New_...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/New_in_JavaScript/1.7)

That's from October 2006. It includes things like let/const, generators,
iterators, and destructuring assignment.

For reference, ES5 was published in December 2009.

So, it's kinda like applauding Microsoft for supporting text-overflow:ellipsis
first. It's something they added with IE6. It became part of the standards
much later with CSS3.

~~~
gsnedders
To be fair, quite a lot of these things have had to have relatively
significant changes to match the ES6 spec.

------
mrspeaker
I vowed to switch to the first browser that implemented arrow-function syntax.
Sooo, been using Firefox as my primary browser for the last 6 months, and am
loving using ES6 features in my personal projects (without needing stinky
transpilers messin' up my workflow)! Next up, hanging out for Module support.
C'mon modules!

~~~
apaprocki
FYI we (Bloomberg) also want arrow syntax and are sponsoring Adrian Perez at
Igalia to work on adding it to v8. Work is coming along...

[https://codereview.chromium.org/160073006/](https://codereview.chromium.org/160073006/)

(If any other companies are wondering how to help out, I can't recommend
Igalia highly enough!)

~~~
cpeterso
Bloomberg also sponsored Andy Wingo's work on ES6 generators and array
comprehensions for Chrome [1] and Firefox [2].

What is Bloomberg's motivation for sponsoring browser feature development? How
does Bloomberg prioritize what they would like to fund? It's exciting to see
companies, not just contributing changes back to open-source projects they
use, but actually funding new development. Thank you! :)

[1] [http://wingolog.org/archives/2013/05/08/generators-
in-v8](http://wingolog.org/archives/2013/05/08/generators-in-v8)

[2] [http://wingolog.org/archives/2013/10/07/es6-generators-
and-i...](http://wingolog.org/archives/2013/10/07/es6-generators-and-
iteration-in-spidermonkey)

~~~
apaprocki
> What is Bloomberg's motivation for sponsoring browser feature development?

Our motivation is that we have a massive custom server-side JS deployment that
powers the platform for the Bloomberg Professional Service (a.k.a.
"Terminal"). We use both spidermonkey and v8 in custom environments, so
getting ES6 (and beyond) language features in the engines as fast as possible
helps the 2,000+ developers building the platform every day. So what benefits
us, benefits the web since we use engines that cut across multiple browsers.
We also have a bunch of web properties, so obviously those teams are thrilled
that we help move the needle a bit as well.

> How does Bloomberg prioritize what they would like to fund?

Prioritizing the features that Igalia works on falls out of discussions
between my team and Igalia to see where their development effort can be most
effective to get what helps our developers the most. We really, really wanted
generators across the board so that we could use generators and promises to
help how we address async control flow. We have internal JS frameworks that
use certain features that are not too common in the web and sometimes are not
as optimized/JITed as earlier APIs. It's a two-way conversation with Igalia to
find out how we can make the most impact.

We do some of our own contributions to these projects as well, but the model
we have with Igalia works amazingly well because they aren't distracted by the
other development that my team is currently involved in.

~~~
cpeterso
Thanks for sharing. That's very interesting!

> We use both spidermonkey and v8 in custom environments

Are you using SpiderMonkey on the server-side, too? I work for Mozilla and
some community members are interested in rebooting "SpiderNode", Mozilla's
2011 proof-of-concept to plug SpiderMonkey VM into the Node server.
SpiderMonkey supports more ES6 features than V8 (or node --harmony), so
SpiderNode developers could use more ES6 features on the server-side without
worrying about browser compatibility.

~~~
apaprocki
Yes, most of the production JS is running on spidermonkey. The original
binding is hand built using JSAPI, but the newer code we have abstracts the JS
engine away behind an interface, making a single way to easily bind C++
classes to JS, allowing us to swap in spidermonkey or v8 without the bound
code being aware. This is kind of what you want to do, only you want to
emulate the v8 API to avoid having to retool the Node guts. Two different
approaches but they achieve the same result. IBM guys working on the POWER
node port asked if we can open-source the abstraction and adapters -- it's on
my todo list to look into, but can't promise anything yet.

~~~
cpeterso
Mozilla has a prototype of what you suggested: "v8monkey", an API facade that
emulates the v8 API on top of SpiderMonkey's JSAPI. A contributor named Sarat
recently unbitrotted v8monkey and ported it to SpiderMonkey's current JSAPI
(which was rewritten to support Generational GC). He posted his patches just
three hours ago. :)

[https://bugzilla.mozilla.org/show_bug.cgi?id=1005411](https://bugzilla.mozilla.org/show_bug.cgi?id=1005411)

------
masswerk
Great!

A few things that are rather addressing the Harmony proposal:

\- `this` in arrow functions: Now this is breaking the standard behavior AND
strict mode. I understand that we're running out of reserved words for this,
but maybe it shouldn't have been `this` with different semantics. (I would
expect all (near-)future extensions to be compliant with strict mode.)

\- explicit `set()` and `get()` methods of Maps and WeakMaps: Why make them
explicit and not implicit getters and setters (by subscript) like with
associative arrays? Why another approach for the same thing?

These parts of the proposal are prone to cause some irritations, since they
are adding duplicate behavior or syntax to existing approaches ...

Edit: I do understand that using subscripts in assignments to Maps and
WeakMaps would produce some inconsistency on the other hand, since these
subscripts would not translate to names (or rather to some hash-signature), so
there's always a trade-off.

~~~
jlongster
Arrow functions don't break anything, they just add a little bit of
complexity. And trust me, once you start using them, you'll never go back.
That is one thing that TC39 absolutely got right; it solved a direct pain
point in JS code and it's far easier to write good code with it.

I work on the Firefox Debugger, and all the devtools use ES6 extensively,
especially arrow functions. They aren't confusing. Almost always, `this`
refers to the object instance that you are working on, and arrow functions
allow you to do quick functional programming inside the methods. It's
beautiful.

~~~
mnemonik
Yeah, pretty much the only time you want non-arrow functions is for prototype
methods (but once ES6 classes are implemented, you can use that syntax and it
will be less verbose anyways). In almost every other case you either don't
care about `this` or you want to use the containing function's `this` value.
Arrow functions are perfect for these cases.

~~~
masswerk
I would just point out the ambiguity while working with legacy code and ES6
applications. (A separate name would have been fine. But of course, there is
the reserved names problem.)

From a practical perspective, we will have to deal with IE 8 and co for
another 10 years at least. So we will have to "come back" all the time.

------
cantbecool
'is and isnt operator' that sounds nifty.

~~~
tyleregeto
I was excited for that. I've worked in languages that had an `is` operator,
and it can result in very readable code. Eg:

    
    
      if list is Array {
      
      }
    

Much nicer than:

    
    
      if Array.isArray(list) {
      
      }

------
general_failure
What's being discussed wrt promises?

(I don't like promises and would like to see it go away. Sadly too many specs
have adopted it already)

~~~
untog
_I don 't like promises and would like to see it go away_

You could always just... not use them.

~~~
JohnBooty
Most coders have to use and extend a lot of other peoples' code, so if
everybody else is using them then you have to deal with it...

------
CmonDev
Is there a list of design flaw fixes?

~~~
_random_
Yes, that would be nice to see.

