ECMAScript 6 support in Mozilla
developer.mozilla.org
developer.mozilla.org
http://kangax.github.io/es5-compat-table/es6/
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_...
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.
That's only part of the reason, the linked page notes which features had been added by Mozilla (generally feature-gated). The count is 5 items of syntactic additions (out of 12), and 0 of standard library additions (out of ~40)
No the reason is that adding Dart VM to Chrome is higher than JavaScript compliance.
I guess, given from the utterly dissapointing stats in the Mozilla page, and the even worse situation on Chrome, that we're in for another 7 year wait.
https://codereview.chromium.org/160073006/
(If any other companies are wondering how to help out, I can't recommend Igalia highly enough!)
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
[2] http://wingolog.org/archives/2013/10/07/es6-generators-and-i...
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.
> 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.
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.
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.
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.
Isn't this an issue with patterns, where an object is applied to a callback? It would introduce extensive testing, whether the callback was supplied as a regular function or (erroneously) as an arrow function (which would raise an error). Using try-catch for this would send the whole construct out of JIT-context at the other hand, so it isn't a favorable option.
A not-so-serious proposal: Since everyone is overwriting the variable "self", we could reuse the variable "parent" for the same reasons in this case.
Say you have a Map named 'm' and you do m.clear(). Keep in mind that '.' is just syntactic sugar in JS, so this is by definition the same as m["clear"](). But now you have to worry about what happens if someone uses "clear" as a key for the Map. Does that make it impossible to clear the map? Impossible to retrieve the key? Reinstate the e4x behavior where x.y() and x.y.call(x) would do different things? Something else?
These concerns, which come up all the time with the use of objects as associative arrays, are why Map and WeakMap have explicit getter/setter methods. That way you can tell when you're working with the map part and when you're just treating it like an object with methods (clear, forEach, entries, keys, size, values) on it.
-> no special consideration for 'this', works like function()
=> binds 'this' to parent's 'this'
Personally, I would suggest the introduction of another variable, providing a "sticky this", which would stay bound to the this-object of the scope, the function was declared in. But what would be the reserved word to be used for it? (This would have to be restricted to arrow-functions, since there would be inconsistencies when assigning a method to an other object.)
Instead of -> {...} replacing function() {...}
We get => {...} replacing (function() {...}).bind(this)
Why should the less common case get the more convenient syntax? Especially considering when we already have Function.prototype.bind to do this. How could they possibly agree on this but not the thin arrow?
Well you cant use it unbound. I dont want to declare functions bound to a scope I want a quick way to declare functions.
So this is a) a personal view on this (as pointed out clearly) and b) not raised deliberately.
I'm hoping you're right with your guess, regarding the motivations behind it.
if list is Array {
}
if Array.isArray(list) {
}if a isnt b or b is c then return e
(I don't like promises and would like to see it go away. Sadly too many specs have adopted it already)
You could always just... not use them.
If you're in favor or callbacks, you're doing it wrong.
I use promises and like them, but generators are a LOT nicer. I've been playing around with KoaJS and I'm amazed with it. I find that overall it makes code a lot easier to read, write, and understand.
On top of that, it give you sane stack-traces!
I'm not certain if this is correct, but from what I can gather, you can yield on a promise and if you resolve it successfully you get the value directly and if you resolve it as a failure, it will throw an error.
The example I like to show people is this: https://www.dropbox.com/s/06zy52m8x0lllzn/Screenshot%202014-... It's the controller for a user's registration, where the thrown error is an object of invalid fields submitted.