JavaScript Versioning

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

JavaScript Versioning

Alexander Craggs
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Jordan Harband
Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be introduced.

There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <[hidden email]> wrote:
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Alexander Craggs
(Apologies for the double email Jordan, I accidentally replied to just you, not es-discuss as well.  I'm new to this whole mailing list thing.)

Apologies, that was a bad example.  I was more considering "use strict" to be breaking in the sense that some things that worked without it would no longer work with it.  That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be introduced, most that I could find appeared to fail in the sense of the content they provided, installing rules that were better found in a linter, as opposed to a parsing mode.  Do you have any points on why the idea itself is unlikely to be implemented as opposed to the content?  

I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string.  We would have to add some new detection feature for this newer flavour to allow better messages.

But error messages were the lowest suggestion for this new functionality, and probably another bad example.  Just consider the hundreds of previously rejected proposals that were very promising but couldn't be used because of breaking backwards compatability.

On 23/07/2017 05:50:31, Jordan Harband <[hidden email]> wrote:

Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be introduced.

There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <[hidden email]> wrote:
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Jordan Harband
Error messages 1) are unspecified, 2) change all the time, 3) vary by language, 4) vary across browser/engine implementations. There is zero reason that any error message couldn't be changed, and in fact, many browsers do improve them over time.

I'd say before believing it can't be done, try filing tickets on Chromium, Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a more favorable response than you think.

On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <[hidden email]> wrote:
(Apologies for the double email Jordan, I accidentally replied to just you, not es-discuss as well.  I'm new to this whole mailing list thing.)

Apologies, that was a bad example.  I was more considering "use strict" to be breaking in the sense that some things that worked without it would no longer work with it.  That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be introduced, most that I could find appeared to fail in the sense of the content they provided, installing rules that were better found in a linter, as opposed to a parsing mode.  Do you have any points on why the idea itself is unlikely to be implemented as opposed to the content?  

I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string.  We would have to add some new detection feature for this newer flavour to allow better messages.

But error messages were the lowest suggestion for this new functionality, and probably another bad example.  Just consider the hundreds of previously rejected proposals that were very promising but couldn't be used because of breaking backwards compatability.

On 23/07/2017 05:50:31, Jordan Harband <[hidden email]> wrote:

Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be introduced.

There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <[hidden email]> wrote:
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Alexander Craggs
Huh, in which case I will!

What are your thoughts on the non-error message part of this proposal?

On 23/07/2017 06:34:48, Jordan Harband <[hidden email]> wrote:

Error messages 1) are unspecified, 2) change all the time, 3) vary by language, 4) vary across browser/engine implementations. There is zero reason that any error message couldn't be changed, and in fact, many browsers do improve them over time.

I'd say before believing it can't be done, try filing tickets on Chromium, Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a more favorable response than you think.

On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <[hidden email]> wrote:
(Apologies for the double email Jordan, I accidentally replied to just you, not es-discuss as well.  I'm new to this whole mailing list thing.)

Apologies, that was a bad example.  I was more considering "use strict" to be breaking in the sense that some things that worked without it would no longer work with it.  That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be introduced, most that I could find appeared to fail in the sense of the content they provided, installing rules that were better found in a linter, as opposed to a parsing mode.  Do you have any points on why the idea itself is unlikely to be implemented as opposed to the content?  

I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string.  We would have to add some new detection feature for this newer flavour to allow better messages.

But error messages were the lowest suggestion for this new functionality, and probably another bad example.  Just consider the hundreds of previously rejected proposals that were very promising but couldn't be used because of breaking backwards compatability.

On 23/07/2017 05:50:31, Jordan Harband <[hidden email]> wrote:

Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be introduced.

There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <[hidden email]> wrote:
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Jordan Harband
I don't think a new mode is a good idea.

On Sat, Jul 22, 2017 at 10:36 PM, Alexander Craggs <[hidden email]> wrote:
Huh, in which case I will!

What are your thoughts on the non-error message part of this proposal?

On 23/07/2017 06:34:48, Jordan Harband <[hidden email]> wrote:

Error messages 1) are unspecified, 2) change all the time, 3) vary by language, 4) vary across browser/engine implementations. There is zero reason that any error message couldn't be changed, and in fact, many browsers do improve them over time.

I'd say before believing it can't be done, try filing tickets on Chromium, Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a more favorable response than you think.

On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <[hidden email]> wrote:
(Apologies for the double email Jordan, I accidentally replied to just you, not es-discuss as well.  I'm new to this whole mailing list thing.)

Apologies, that was a bad example.  I was more considering "use strict" to be breaking in the sense that some things that worked without it would no longer work with it.  That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be introduced, most that I could find appeared to fail in the sense of the content they provided, installing rules that were better found in a linter, as opposed to a parsing mode.  Do you have any points on why the idea itself is unlikely to be implemented as opposed to the content?  

I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string.  We would have to add some new detection feature for this newer flavour to allow better messages.

But error messages were the lowest suggestion for this new functionality, and probably another bad example.  Just consider the hundreds of previously rejected proposals that were very promising but couldn't be used because of breaking backwards compatability.

On 23/07/2017 05:50:31, Jordan Harband <[hidden email]> wrote:

Strict mode wasn't a breaking change; browsers that don't understand strict mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be introduced.

There's also no need to add pragmas or make breaking changes to make error messages more useful; for that, I suggest filing specific suggestions on each engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <[hidden email]> wrote:
One of the main issues I've found with why a significant number of proposals are rejected is because it would introduce breaking changes into JavaScript, a language created over 22 years ago.  It doesn't surprise me that people have suggestions to improve JavaScript that are breaking, popular syntax seems to have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header at the top of files.  Would it not make sense to introduce new breaking changes under a similar header for each change we suggest?  For example, "use es7" could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: JavaScript Versioning

Dante Federici
In reply to this post by Alexander Craggs
A few times now you've proposed a "use _x_" syntax to achieve breaking changes to the language.

"use strict" is more an attempt to condense the language and take a first pass best practice. Not a means of "versioning" JS.

The bottom line here is that browsers aren't a place for a type safe and correct language (well, thy could have been but hey, such is history). They're a medium to consume information over the internet. Versioning would be awesome and great, but there's always the "I don't want to leave X in the dust" use case that needs to be considered.

"use strict" doesn't leave them high and dry, but does push the web to a better place.  

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

kai zhu

On Jul 23, 2017, at 4:47 PM, Dante Federici <[hidden email]> wrote:

The bottom line here is that browsers aren't a place for a type safe and correct language (well, thy could have been but hey, such is history). They're a medium to consume information over the internet.

+1


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

kdex
For the sake of keeping our discussions clear, could we all please refrain
from flooding the entire mailing list's inbox with these unsubstantial "+1" or
"-1" emails if they contain no meaningful contribution to the conversation?

If you want to make a point, make your point. If not, don't.

Much obliged!

On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote:
> > On Jul 23, 2017, at 4:47 PM, Dante Federici <[hidden email]>
> > wrote:
> >
> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.
> +1
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

kai zhu

> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.

due to history, the hard-reality is that its impractical to write completely correct frontend-code because there are simply too many UX edge-cases to account for.  this inconvenient truth bites non-frontend engineers everytime they try to write a "correct" browser program, and get overwhelmed by the scope of such a requirement.  angular2 is a texbook example of sacrificing convenience (of angular1) for the sake of more correctness.

On Jul 24, 2017 6:11 AM, "kdex" <[hidden email]> wrote:
For the sake of keeping our discussions clear, could we all please refrain
from flooding the entire mailing list's inbox with these unsubstantial "+1" or
"-1" emails if they contain no meaningful contribution to the conversation?

If you want to make a point, make your point. If not, don't.

Much obliged!

On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote:
> > On Jul 23, 2017, at 4:47 PM, Dante Federici <[hidden email]>
> > wrote:
> >
> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.
> +1
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: JavaScript Versioning

David White
In reply to this post by Alexander Craggs
Sorry, just seen this thread and thought it worth mentioning a similar thread ongoing here that has derived from wanting to remove less popular features from the specification:

https://esdiscuss.org/topic/removal-of-language-features

We should definitely continue this conversation in this thread.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Boris Zbarsky
In reply to this post by Alexander Craggs
On 7/23/17 12:30 AM, Alexander Craggs wrote:
> Say we create such versioning, it would allow us to improve the language
> so much more than we're currently able to, we'd no longer have to stick
> with useless error messages for forgetting `async`:
>
> ```js
> < function u() { let x = await "hi" }
>> Uncaught SyntaxError: Unexpected string

In Chrome, that's what you get.  In Firefox, you get:

   SyntaxError: await is only valid in async functions

which is about what you're asking for.  In Safari, you get:

   SyntaxError: Unexpected string literal "hi". Expected ';' after
variable declaration.

which is a moderately more informative version of the Chrome error message.

In any case, it's quite clear that a JS engine _can_ report the "right"
error here; Firefox does so.  Engines that don't do that should just
start doing it, and this should not involve any spec changes.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Boris Zbarsky
In reply to this post by Alexander Craggs
On 7/23/17 1:19 AM, Alexander Craggs wrote:
> I also feel that it is *impossible* for vendors to add such changes to
> make error messages more useful because in the JavaScript syntax
> specified ten years ago "await" didn't exist and it would just be an
> unexpected string.

Just to be clear, the "unexpected string" in your testcase is the "hi",
not the await keyword.  Safari's error message, which I cited earlier in
this thread, makes this much more clear than Chrome's.

> We would have to add some new detection feature for
> this newer flavour to allow better messages.

Again, no; see Firefox behavior here.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Florian Bösch
In reply to this post by Jordan Harband
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband <[hidden email]> wrote:
There's lots of other threads on why no new modes are likely to ever be introduced.

And here we see the language evolution committee in its natural habitat setting itself the impossible goal to support everything every introduced, still introduce new things, and do it all without versioning, forever. In a thousand or a million or a billion years, JS will still be JS as it was set into stone in the late 20th century. 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JavaScript Versioning

Isiah Meadows-2

Not everything. But it's much easier to add than remove a feature, and here's a couple of the driving issues that make it harder for browsers to remove these features (browsers remove them before TC39 can):

- `with` is frequently used in templating libraries that use code gen and allow JS interpolation. There is no real alternative besides parsing each JS expression/statement part, and that's pretty costly up front in code size.
- `RegExp.$1` and friends are incredibly convenient, and are used to avoid having to reference the regexp or `exec` result directly.
- `this` in sloppy mode calls is frequently used to get the global object. Until a `global`, `System.global`, or some other proposal gets through, there is no other reliable, platform-agnostic option to get the global object.

It would be helpful if the committee decided to recommend browsers to emit console warnings for deprecated features (where practical) instead of just telling people to not use deprecated features. That would at least encourage people to act instead of doing nothing.


On Mon, Jul 24, 2017, 12:32 Florian Bösch <[hidden email]> wrote:
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband <[hidden email]> wrote:
There's lots of other threads on why no new modes are likely to ever be introduced.

And here we see the language evolution committee in its natural habitat setting itself the impossible goal to support everything every introduced, still introduce new things, and do it all without versioning, forever. In a thousand or a million or a billion years, JS will still be JS as it was set into stone in the late 20th century. 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss