JavaScript Versioning
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.
(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 <ljharb at gmail.com> 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 <alexander at debenclipper.com [mailto:alexander at 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:
< 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
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.
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 <ljharb at gmail.com> 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 <alexander at debenclipper.com [mailto:alexander at 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 <ljharb at gmail.com [mailto:ljharb at gmail.com]> 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 <alexander at debenclipper.com [mailto:alexander at 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:
< 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
I don't think a new mode is a good idea.
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.
On Jul 23, 2017, at 4:47 PM, Dante Federici <c.dante.federici at 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
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!
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.
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:
esdiscuss.org/topic/removal-of-language-features
We should definitely continue this conversation in this thread.
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:< 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.
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.
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband <ljharb at gmail.com> 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.
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):
withis 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.$1and friends are incredibly convenient, and are used to avoid having to reference the regexp orexecresult directly.thisin sloppy mode calls is frequently used to get the global object. Until aglobal,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.
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:< 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 functionOne 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 ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170723/3ad1d9b8/attachment.html>