Discuss
  • Versioning?

Versioning?

# Peter van der Zee (14 years ago)

lists.webkit.org/pipermail/webkit-dev/2011-December/018924.html

use version 6;

In which thread on esdiscuss should I have read about that?

# David Bruant (14 years ago)

I did start a related thread a while ago [1].

Brendan's response [2] explained a few things: "Please read RFC 4329:

tools.ietf.org/html/rfc4329

There will be at least a ;version=6 parameter you can use, probably with either application/javascript and application/ecmascript -- I have argued that we should align version numbers."

"Beyond the RFC 4329 version= parameter, we also want a pragma for in-script-content version assertion:

use version 6;"

See the full response [2] for full context.

Besides an es-discuss thread, I think that what is really needed is an harmony proposal. How to opt-in for ES6 is outside of the scope of pure ECMAScript (especially if it's with playing with the HTML script tag @type attribute), but let's face it, web devs need this information and a wiki page on the topic would be handy.

At the time of reading Brendan's response, I didn't have anything to add on that and I still don't. Unlike HTML and CSS, JavaScript needs new syntax features. Syntax features that are NOT backward compatible with ES3. If you use one of these features, your script break in older browsers (unlike new HTML elements and CSS rules). I don't see an alternative to versionning. Smarter people are welcome to jump in, I guess.

David

[1] esdiscuss/2011-August/016262 [2] esdiscuss/2011-August/016267

Le 19/12/2011 11:49, Peter van der Zee a écrit :

# Xavier MONTILLET (14 years ago)

Why

use version 6;

and not

"use version 6";

? Just to be sure ES 6 code breaks in old browsers ? And what do you mean by "opt-in for ES6" ? New syntax ? Everything in ES 6 ?

I'm thinking about weakmaps:

  • on the one hand, you want to use native weakmaps when available so you would want to "opt-in for ES6"
  • but on the other hand, you could also implement a weakmap "polyfill" that wouldnt be as efficient, that would suck the memory but still work, and have it work in older browsers

Therefore, setting the thing to do to "opt-in for ES6" to something not backward compatible doesn't seem like a good idea to me.

# Mark S. Miller (14 years ago)

On Mon, Dec 19, 2011 at 10:21 AM, Xavier MONTILLET <xavierm02.net at gmail.com>wrote:

Why

use version 6;

and not

"use version 6";

? Just to be sure ES 6 code breaks in old browsers ? And what do you mean by "opt-in for ES6" ? New syntax ? Everything in ES 6 ?

I'm thinking about weakmaps:

  • on the one hand, you want to use native weakmaps when available so you would want to "opt-in for ES6"
  • but on the other hand, you could also implement a weakmap "polyfill" that wouldnt be as efficient, that would suck the memory but still work, and have it work in older browsers

code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/WeakMap.js is a WeakMap polyfill that should work transparently in all ES5 conformant browsers. It is indeed not as efficient, but it's better than you might expect ;).

Btw, where does the term "polyfill" come from?

# Rick Waldron (14 years ago)

Mark, It was coined by Remy Sharp remysharp.com/2010/10/08/what-is-a-polyfill

...I still don't understand how it differs from "shim"

# Gavin Barraclough (14 years ago)

As an aside (I'm not arguing for or against inline versioning here) isn't:

use version 6;

more backwards compatible? For example, consider the following:

"use version 6"; with ({hi:"Hi!"}) alert(hi);

I believe this is a valid program in ES5, that treating "use version 6" as a directive would break? Whereas I don't see how:

use version 6;

could currently be being parsed as valid ES5. Obviously if we allowed use directives to be split across multiple lines then ASI could be an issue, but so long as the syntax required:

"use" no-newline-here Identifer ...

then this form seems safer.

G.

# Axel Rauschmayer (14 years ago)

My understanding:

  • Shim: retrofit a new API in an older context.
  • Polyfill: “A shim that mimics a future API providing fallback functionality to older browsers.”
# Xavier MONTILLET (14 years ago)

@Gavin Barraclough :

I don't get the point of having the code break in old browsers... When you use this code:

"use version 6"; with ({hi:"Hi!"}) alert(hi);

It will throw an error and this is what you want it to do. Just like when you used "use strict"; Of course, it would work in old browsers and not in new because they would know with isnt allowed anymore. But again, that's what i expect: When i dev in new browsers, it tells me what is bad and when I put it on old browser, they just don't care and have it work.

But if you use:

use version 6;

to opt-in, then you CAN NOT write backward compatible code while using some ES6 features (even those that can be polyfilled)...

# Xavier MONTILLET (14 years ago)

I was speaking of ES 5 + "use strict"; since it needs you to opt-in. ES 5 itself doesn't.

Given the nature of the changes in ES6 I'm not sure that there will be much scope to write code that benefits form utilizing ES6 and yet would still run on a browser supporting only ES5. If you want to write code that will run on an browser that only supports ES5, I think you will find you need to stick to writing ES5 code.

Weakmaps, private names, optimized arrays are all much better in ES 6 but could be (kind of) implemented in ES 5.

# Jason Orendorff (14 years ago)

On Mon, Dec 19, 2011 at 12:21 PM, Xavier MONTILLET <xavierm02.net at gmail.com> wrote:

And what do you mean by "opt-in for ES6" ? New syntax ? Everything in ES 6 ?

Not everything. Let me try to explain the opt-in.

ES6 must not break existing code. This is non-negotiable. Nobody will use a Web browser that breaks the Web.

However, a few of the ES6 proposals are impossible to accept, for this very reason... unless there is an opt-in. Since no existing code contains an ES6 opt-in, any new features that are enabled by the opt-in can't break existing code.

As I understand the current proposals, opt-in will be required for scripts that

  • use the new 'module' keyword, which isn't reserved in ES5;
  • expect (typeof null) to be "null", rather than 'object' as in ES5;
  • need the top-level scope to be declarative, rather than tied to the global object as in ES5; or
  • declare functions in Blocks, with nice standard semantics, different from current browsers which all do it a little different.

...precisely because these are the features that could otherwise change the behavior of existing code. All other new features will be available whether you use the opt-in or not.

Now: in order for TC39 to ditch the opt-in, they would have to either ditch these four features ... or somehow make the new syntax totally distinct from all existing code, so that existing code doesn't break. Here is what I might do:

  • keep modules, but change the syntax to eliminate the 'module' keyword, use an ES5 ReservedWord, or make 'module' a contextual keyword (lots of options here, none pretty);
  • give up on typeof null;
  • keep top-level declarative scope, but only in module code;
  • specify less-nice, more-Web-compatible semantics for functions in Blocks
# David Bruant (14 years ago)

Le 20/12/2011 22:45, Jason Orendorff a écrit :

As I understand the current proposals, opt-in will be required for scripts that (...)

  • need the top-level scope to be declarative, rather than tied to the global object as in ES5;

Where is the proposal for this? I can't find it at harmony:proposals