Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: Re: JavaScript Versioning

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

Re: JavaScript Versioning

> > 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

Re: JavaScript Versioning

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.

Re: JavaScript Versioning

> 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

Re: Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

(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

Re: 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;

JavaScript Versioning

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