3 ms·

Can anyone explain the forwards compatibility plan for es6? I get we can transpile, but that's not a gradual strategy for converting code. Since you can't polyf

by habitue 12y ago

Can anyone explain the forwards compatibility plan for es6? I get we can transpile, but that's not a gradual strategy for converting code. Since you can't polyfill syntax, are we just supposed to all transpile until some far flung day when browsers without es6 support finally reach some tiny percentage? Is the assumption now that browsers largely auto-update that it won't be so long before that happens? Why are breaking syntax changes not a big deal, whereas "use strict" was done as a string so older browsers would ignore it? Edit: backwards compatibility -> forwards

VieElm 12y ago
The only backwards compatibility breaking change I know of is that function declarations are scoped block level in EcmaScript 6 (which I think has been renamed to EcmaScript 2015), not function scope which is what they have been since the beginning, but they're only block level if you use "use strict"; for the foreseeable future and if this change breaks things for you you were writing really terrible JavaScript to begin with.
- habitue 12y ago
  Sorry, I meant forwards compatibility
stupidcar 12y ago
Firstly, JS isn't just about browsers anymore. Developers using node.js and io.js can use new syntax as soon as their platform of choice supports it. For browsers, yes, compatibility means we have to transpile. But the day you need not isn't necessarily so far-flung. Like you say, browsers largely auto-update and, after a slow start, they are implementing ES6 features at a good pace. The ES6 compatibility table[1] shows the progress already made. Only WebKit is really lagging. IE.next/Spartan is actually leading the pack, and coupled with Microsoft's plan to give away Windows 10 free to Windows 7 and 8 users, it gives good hope for the future. Also, transpilation can be a gradual strategy for converting code. The Babel (née 6to5) authors have stated their intention to keep supporting new JS features as they are added to future versions of the EcmaScript standard. I think we'll soon see Babel able to be used like Autoprefixer, which selectively adds vendor prefixes to CSS based on browser support statistics and a developer-specified target configuration like "last 2 versions" or "> 5%". [1] http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
ahoge 12y ago
The behavior of strict mode would have broken existing code. That's why you have to opt-in. New syntax, on the other hand, can be added without breaking existing code. These new constructs would have been syntax errors beforehand.

by habitue 12y ago

VieElm 12y ago

The only backwards compatibility breaking change I know of is that function declarations are scoped block level in EcmaScript 6 (which I think has been renamed to EcmaScript 2015), not function scope which is what they have been since the beginning, but they're only block level if you use "use strict"; for the foreseeable future and if this change breaks things for you you were writing really terrible JavaScript to begin with.

habitue 12y ago
Sorry, I meant forwards compatibility

stupidcar 12y ago

Firstly, JS isn't just about browsers anymore. Developers using node.js and io.js can use new syntax as soon as their platform of choice supports it. For browsers, yes, compatibility means we have to transpile. But the day you need not isn't necessarily so far-flung. Like you say, browsers largely auto-update and, after a slow start, they are implementing ES6 features at a good pace. The ES6 compatibility table[1] shows the progress already made. Only WebKit is really lagging. IE.next/Spartan is actually leading the pack, and coupled with Microsoft's plan to give away Windows 10 free to Windows 7 and 8 users, it gives good hope for the future. Also, transpilation can be a gradual strategy for converting code. The Babel (née 6to5) authors have stated their intention to keep supporting new JS features as they are added to future versions of the EcmaScript standard. I think we'll soon see Babel able to be used like Autoprefixer, which selectively adds vendor prefixes to CSS based on browser support statistics and a developer-specified target configuration like "last 2 versions" or "> 5%". [1] http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/

ahoge 12y ago

The behavior of strict mode would have broken existing code. That's why you have to opt-in. New syntax, on the other hand, can be added without breaking existing code. These new constructs would have been syntax errors beforehand.