13 ms·

ECMAScript 6 support in Mozilla

87 points by matt42 12y ago

general_failure 12y ago
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 12y ago
  I don't like promises and would like to see it go away You could always just... not use them.
  - JohnBooty 12y ago
    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...
- Kiro 12y ago
  What do you think is a better alternative?
  - abjorn 12y ago
    There are some very interesting things you can do with generators in regards to asynchronous flow control. Personally I'm in favor of the Promises, however. Unfortunately some current implementations are broken in terms of error handling. Chrome just swallows exceptions that happen in Promises, in a lot of cases.
    - Touche 12y ago
      Generators are no fun to work with so you want a library. Promises won't require a library so i'll use that.
- coldtea 12y ago
  Why, what's the alternative? If you're thinking of using something like a generator, OK. If you're in favor or callbacks, you're doing it wrong.
  - TheAceOfHearts 12y ago
    Generators are the solution. 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-05-01%2014.59.22.png 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.
masswerk 12y ago
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.
- untog 12y ago
  With regard to arrow functions, I'm a big fan of how CoffeeScript does it: -> no special consideration for 'this', works like function() => binds 'this' to parent's 'this'
  - masswerk 12y ago
    In my view on `this`, changing the semantics would always harm the generality of functions as first class entities. In case I would assign a function to an object as a method, what would this mean for the semantics of `this`? Evaluating the this-object just as late as possible gives a general approach that isn't prone to fail. By changing semantics, we're always introducing some edge-cases, for which there would have to be special behavior and constraints to be defined. Even with binding there would have to be some constraints to be added. (We have been doing great things with the current implementation for nearly 20 years by now, so it can't be that wrong.) 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.)
cantbecool 12y ago
'is and isnt operator' that sounds nifty.
- tyleregeto 12y ago
  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) { }
- cnp 12y ago
  Totally. That's one of my favorite things about CoffeeScript and I hope that eventually the keywords make it in to the final spec: if a isnt b or b is c then return e
CmonDev 12y ago
Is there a list of design flaw fixes?
- deleted 12y ago
  [deleted]
- _random_ 12y ago
  Yes, that would be nice to see.
pjmlp 12y ago
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.
- abjorn 12y ago
  Well, historically Mozilla has been the main driving force behind JavaScript's development so that isn't too surprising. Who knows how Eich's departure will affect that, though.
  - coldtea 12y ago
    We're waiting for Harmony for like 7 years with Eich? 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.
    - _random_ 12y ago
      Welcome to the "open" web.
- ahoge 12y ago
  > 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_in_JavaScript/1.7 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.
  - gsnedders 12y ago
    To be fair, quite a lot of these things have had to have relatively significant changes to match the ES6 spec.
mrspeaker 12y ago
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 12y ago
  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 12y ago
    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-iteration-in-spidermonkey http://wingolog.org/archives/2013/10/07/es6-generators-and-i...
    - apaprocki 12y ago
      > 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.

87 points by matt42 12y ago

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 12y ago
I don't like promises and would like to see it go away You could always just... not use them.
- JohnBooty 12y ago
  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...
Kiro 12y ago
What do you think is a better alternative?
- abjorn 12y ago
  There are some very interesting things you can do with generators in regards to asynchronous flow control. Personally I'm in favor of the Promises, however. Unfortunately some current implementations are broken in terms of error handling. Chrome just swallows exceptions that happen in Promises, in a lot of cases.
  - Touche 12y ago
    Generators are no fun to work with so you want a library. Promises won't require a library so i'll use that.
coldtea 12y ago
Why, what's the alternative? If you're thinking of using something like a generator, OK. If you're in favor or callbacks, you're doing it wrong.
- TheAceOfHearts 12y ago
  Generators are the solution. 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-05-01%2014.59.22.png 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.

masswerk 12y ago

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.

untog 12y ago
With regard to arrow functions, I'm a big fan of how CoffeeScript does it: -> no special consideration for 'this', works like function() => binds 'this' to parent's 'this'
- masswerk 12y ago
  In my view on `this`, changing the semantics would always harm the generality of functions as first class entities. In case I would assign a function to an object as a method, what would this mean for the semantics of `this`? Evaluating the this-object just as late as possible gives a general approach that isn't prone to fail. By changing semantics, we're always introducing some edge-cases, for which there would have to be special behavior and constraints to be defined. Even with binding there would have to be some constraints to be added. (We have been doing great things with the current implementation for nearly 20 years by now, so it can't be that wrong.) 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.)

cantbecool 12y ago

'is and isnt operator' that sounds nifty.

tyleregeto 12y ago
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) { }
cnp 12y ago
Totally. That's one of my favorite things about CoffeeScript and I hope that eventually the keywords make it in to the final spec: if a isnt b or b is c then return e

CmonDev 12y ago

Is there a list of design flaw fixes?

deleted 12y ago
[deleted]
_random_ 12y ago
Yes, that would be nice to see.

pjmlp 12y ago

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.

abjorn 12y ago
Well, historically Mozilla has been the main driving force behind JavaScript's development so that isn't too surprising. Who knows how Eich's departure will affect that, though.
- coldtea 12y ago
  We're waiting for Harmony for like 7 years with Eich? 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.
  - _random_ 12y ago
    Welcome to the "open" web.
ahoge 12y ago
> 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_in_JavaScript/1.7 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.
- gsnedders 12y ago
  To be fair, quite a lot of these things have had to have relatively significant changes to match the ES6 spec.

mrspeaker 12y ago

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 12y ago
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 12y ago
  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-iteration-in-spidermonkey http://wingolog.org/archives/2013/10/07/es6-generators-and-i...
  - apaprocki 12y ago
    > 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.