Re: JavaScript Versioning

2017-07-26 Thread Isiah Meadows 
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  wrote:

> On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband  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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-24 Thread Florian Bösch 
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband  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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-24 Thread Boris Zbarsky 

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-24 Thread Boris Zbarsky 

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: JavaScript Versioning

2017-07-23 Thread David White 
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-23 Thread 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"  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 <
> c.dante.feder...@gmail.com>
> > > 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-23 Thread 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 
> > 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

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-23 Thread kai zhu 

> On Jul 23, 2017, at 4:47 PM, Dante Federici  
> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: JavaScript Versioning

2017-07-23 Thread Dante Federici 
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-23 Thread Jordan Harband 
I don't think a new mode is a good idea.

On Sat, Jul 22, 2017 at 10:36 PM, Alexander Craggs <
alexan...@debenclipper.com> 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  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 <
> alexan...@debenclipper.com> 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  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 <
>> alexan...@debenclipper.com> 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
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-22 Thread 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  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  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  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  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
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-22 Thread 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 <
alexan...@debenclipper.com> 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  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 <
> alexan...@debenclipper.com> 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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-22 Thread 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  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  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
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

2017-07-22 Thread 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 <
alexan...@debenclipper.com> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

JavaScript Versioning

2017-07-22 Thread 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss