Removal of language features

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

Re: Removal of language features

Owen
It may be worth looking at Python 3 as a cautionary tail. For example, here is a mailing list post from 2009 debating whether it is worth adding features to 2.7 given that 3 is on the way: https://mail.python.org/pipermail/python-dev/2009-October/093204.html . Eight years later, Python 2.7 shows no signs of going  away, and the language has become, at least for portable code, basically static since then.

Of course, although the Python developers used an abundance of caution in rolling out a major version, it remains an open question whether adoption would have been smoother had the C API not changed. It may be that this difficulty would not affect JavaScript, and a new major version would be more feasible.

On Sun, Jul 23, 2017 at 7:57 PM doodad-js Admin <[hidden email]> wrote:
And more, engines could signal they support JS 2 just by the Accept header!

-----Original Message-----
From: David White [mailto:[hidden email]]
Sent: Sunday, July 23, 2017 7:52 PM
To: doodad-js Admin <[hidden email]>
Cc: [hidden email]
Subject: Re: Removal of language features

Ooooh, a mime type based versioning would be very nice!

`<script src=“/myapp.js” type=“application/javascript.2”></script>`

For the most part you control your applications language decision and honour that with your bundle then load additional scripts you have little control over such as logging, monitoring, stats, etc in different runtimes perhaps.

It’s certainly cleaner than injecting a version into the top of your bundle and would allow 3rd party vendors to provide version specific bundles.

David

> On 24 Jul 2017, at 00:43, doodad-js Admin <[hidden email]> wrote:
>
> May I propose a new file extension and mime-type... "js2": "application/javascript.2" ?
>
> -----Original Message-----
> From: David White [mailto:[hidden email]]
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin <[hidden email]>
> Subject: Re: Removal of language features
>
> That’s an interesting proposal but I’m struggling to think how that would solve this same issue 2 or 3 or 5 years down the line? JavaScript and browsers have a symmetry along with HTML, CSS... and given the disparity of devices today alone, let alone tomorrow a new major version would cause more harm than good. Ideally we would need a solution that works as ES5 as standard, then have that semantic in later versions of the language.
>
> Perhaps this is not a problem for this community but something browser providers should be providing / considering to allow developers to specify their runtime in order to allow the language to progress more natrurally?
>
> David
>
>
>> On 23 Jul 2017, at 23:38, doodad-js Admin <[hidden email]> wrote:
>>
>> Maybe that's time to start a new major version of JS?
>>
>> -----Original Message-----
>> From: David White [mailto:[hidden email]]
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: [hidden email]
>> Subject: Re: Re: Removal of language features
>>
>> Lots of good thoughts and discussions here, and while it’s gone slightly off topic I’d love to discuss the possibilities of how we could get JavaScript to a point where we could actively remove features with every new specification.
>>
>> I’m sure nobody would want to break the web, which would be very likely removing any parts of JavaScript, and certainly the biggest challenge, it does seem a shame that we can’t find an ulterior direction as it does seem allowing various features we consider bad practice today to still exist and the overhead that exists with them certainly hinders progress more than it helps.
>>
>> Linting is certainly the fastest and easiest method, but to a certain extent I not really a solution in that we only lint our own code, and not the additional code that we rely upon. Ideally removal of features should mean more performance out of JavaScript, if engines have less constructs to deal with then there should be some beneficial performance related with that?
>>
>> Given the lack of control over what browsers many users are using perhaps versioning could be a new semantic built into the language itself in the same way we have strict mode?
>>
>> We could allow developers the option to specify the version they wish to use, avoiding unnecessary transpiration back to ES5 for applications confident enough to give their users the choice to upgrade if needed but also allow browsers to only run based on versions?
>>
>> I'm sure it’s worth considering as removing features of a language / application is as important, if not more so, than adding features to a language or application.
>>
>> David
>>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>


_______________________________________________
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: Removal of language features

kdex
In reply to this post by doodad-js Admin
This was kind of the original idea around Dart IIRC. It didn't see much
traction though, and eventually got called off.

On Monday, July 24, 2017 1:56:53 AM CEST doodad-js Admin wrote:

> And more, engines could signal they support JS 2 just by the Accept header!
>
> -----Original Message-----
> From: David White [mailto:[hidden email]]
> Sent: Sunday, July 23, 2017 7:52 PM
> To: doodad-js Admin <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Removal of language features
>
> Ooooh, a mime type based versioning would be very nice!
>
> `<script src=“/myapp.js” type=“application/javascript.2”></script>`
>
> For the most part you control your applications language decision and honour
> that with your bundle then load additional scripts you have little control
> over such as logging, monitoring, stats, etc in different runtimes perhaps.
>
> It’s certainly cleaner than injecting a version into the top of your bundle
> and would allow 3rd party vendors to provide version specific bundles.
>
> David
>
> > On 24 Jul 2017, at 00:43, doodad-js Admin <[hidden email]> wrote:
> >
> > May I propose a new file extension and mime-type... "js2":
> > "application/javascript.2" ?
> >
> > -----Original Message-----
> > From: David White [mailto:[hidden email]]
> > Sent: Sunday, July 23, 2017 7:35 PM
> > To: doodad-js Admin <[hidden email]>
> > Subject: Re: Removal of language features
> >
> > That’s an interesting proposal but I’m struggling to think how that would
> > solve this same issue 2 or 3 or 5 years down the line? JavaScript and
> > browsers have a symmetry along with HTML, CSS... and given the disparity
> > of devices today alone, let alone tomorrow a new major version would
> > cause more harm than good. Ideally we would need a solution that works as
> > ES5 as standard, then have that semantic in later versions of the
> > language.
> >
> > Perhaps this is not a problem for this community but something browser
> > providers should be providing / considering to allow developers to
> > specify their runtime in order to allow the language to progress more
> > natrurally?
> >
> > David
> >
> >> On 23 Jul 2017, at 23:38, doodad-js Admin <[hidden email]> wrote:
> >>
> >> Maybe that's time to start a new major version of JS?
> >>
> >> -----Original Message-----
> >> From: David White [mailto:[hidden email]]
> >> Sent: Sunday, July 23, 2017 5:54 PM
> >> To: [hidden email]
> >> Subject: Re: Re: Removal of language features
> >>
> >> Lots of good thoughts and discussions here, and while it’s gone slightly
> >> off topic I’d love to discuss the possibilities of how we could get
> >> JavaScript to a point where we could actively remove features with every
> >> new specification.
> >>
> >> I’m sure nobody would want to break the web, which would be very likely
> >> removing any parts of JavaScript, and certainly the biggest challenge,
> >> it does seem a shame that we can’t find an ulterior direction as it does
> >> seem allowing various features we consider bad practice today to still
> >> exist and the overhead that exists with them certainly hinders progress
> >> more than it helps.
> >>
> >> Linting is certainly the fastest and easiest method, but to a certain
> >> extent I not really a solution in that we only lint our own code, and
> >> not the additional code that we rely upon. Ideally removal of features
> >> should mean more performance out of JavaScript, if engines have less
> >> constructs to deal with then there should be some beneficial performance
> >> related with that?
> >>
> >> Given the lack of control over what browsers many users are using perhaps
> >> versioning could be a new semantic built into the language itself in the
> >> same way we have strict mode?
> >>
> >> We could allow developers the option to specify the version they wish to
> >> use, avoiding unnecessary transpiration back to ES5 for applications
> >> confident enough to give their users the choice to upgrade if needed but
> >> also allow browsers to only run based on versions?
> >>
> >> I'm sure it’s worth considering as removing features of a language /
> >> application is as important, if not more so, than adding features to a
> >> language or application.
> >>
> >> David
> >
> > ---
> > This email has been checked for viruses by AVG.
> > http://www.avg.com
>
> _______________________________________________
> 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

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

Re: Removal of language features

Isiah Meadows-2
Thought I'd clarify why I brought TypeScript in from:

- TypeScript in of itself is *not* a problem.
- Angular's use and embrace of TypeScript in of itself is *not* a problem.
- TypeScript was more of a tangentially related side detail.

I was only referring to Angular embracing a stage 2 proposal,
specifically decorators (with TypeScript extensions thereof), that had
become rather unstable a few months before they went beta with v2.0.
It's a technical risk taken by a framework with already very high
usage, one that introduced significant technical debt, and one I
questioned from the start.

(I could understand if it were stage 3, gaining browser support. But
to be clear, a year ago when they made the decision, it was a poor
choice, being relatively new and immature for a stage 2 proposal.)

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Removal of language features

Naveen Chawla
In reply to this post by kdex
Don't break the web.

Those who don't like old features just don't need to use them.

Applications that do use them would break!

If reducing the available feature set would increase performance then a declaration to the browser to ignore deprecated features should be enough to get this optimization, but only for this reason.

But do we even know that there is any performance gain for doing so?

I'm not bothered about browser code complexity to support old features - I don't see that code anyway. I don't know to what extent other javascript developers are bothered about it either.

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

Re: Removal of language features

Sebastian Zartner-2
On 24 July 2017 at 10:47, Naveen Chawla <[hidden email]> wrote:
> If reducing the available feature set would increase performance then a declaration to the browser to ignore deprecated features should be enough to get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I don't see that code anyway. I don't know to what extent other javascript developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

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

Re: Removal of language features

Alexander Craggs
Some thoughts on using MIME types to distinguish between versions:

 1. In terms of including it in <script> tags, I don't think that is a good idea for including third party libraries in your code.  It would be hard to tell what version of JavaScript a library is using, I think it would be better to allow it to be defined by the library, instead of the user.
 2. In response to "server can set MIME type", a lot of libraries are hosted on systems that don't allow you to change headers, for example Github pages.  Plus, there are several JavaScript CDNs out there that also don't let you set MIME type.
 3. Not many newer individuals know how to set headers, I don't think I'd be able to set headers on Apache off the top of my head. 

May be biased, suggested a separate method of versioning with the "use es8" deceleration at the top of a file.  As a side note, since I made the other thread that seems to be discussing almost the exact same topic as this one (versioning to add breaking changes vs. versioning to remove language features), do people think it would be a good idea to discuss both thoughts solely in this thread (the more popular one?).  

On 25/07/2017 19:59:00, Sebastian Zartner <[hidden email]> wrote:

On 24 July 2017 at 10:47, Naveen Chawla wrote:
> If reducing the available feature set would increase performance then a declaration to the browser to ignore deprecated features should be enough to get this optimization, but only for this reason.
>
> But do we even know that there is any performance gain for doing so?
>
> I'm not bothered about browser code complexity to support old features - I don't see that code anyway. I don't know to what extent other javascript developers are bothered about it either.

Well, JavaScript developers may not bother about the complexity of
browser code, though browser developers, or more generally spoken,
JavaScript engine developers should care about the complexity of their
code. Supporting old features may not only be a question of engine
performance but also memory consumption and (download) sizes of their
programs.
So, it should be in their interest to deprecate misfeatures, even when
it takes 5, 10, or 15 years until their usage drops enough so they can
actually be removed.

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

FW: Removal of language features

doodad-js Admin
  •  1. In terms of including it in <script> tags, I don't think that is a good idea for including third party libraries in your code.  It would be hard to tell what version of JavaScript a library is using, I think it would be better to allow it to be defined by the library, instead of the user.

 

That’s why I’ve suggested a new file extension (js2).

 

  •  2. In response to "server can set MIME type", a lot of libraries are hosted on systems that don't allow you to change headers, for example Github pages.  Plus, there are several JavaScript CDNs out there that also don't let you set MIME type.

 

I’m talking about the “Accept” header, which is set by the client on each request. Browsers that support JS 2 will automatically append “application/javascript.2” to that header.

 

  • 3. Not many newer individuals know how to set headers, I don't think I'd be able to set headers on Apache off the top of my head. 

 

That’s the base of Web development, but not required on that situation.

 

 

From: Alexander Craggs [[hidden email]]
Sent: Tuesday, July 25, 2017 3:16 PM
To: Sebastian Zartner <[hidden email]>; Naveen Chawla <[hidden email]>
Cc: [hidden email]
Subject: Re: Removal of language features

 

Some thoughts on using MIME types to distinguish between versions:

 

 

May be biased, suggested a separate method of versioning with the "use es8" deceleration at the top of a file.  As a side note, since I made the other thread that seems to be discussing almost the exact same topic as this one (versioning to add breaking changes vs. versioning to remove language features), do people think it would be a good idea to discuss both thoughts solely in this thread (the more popular one?).  


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

Re: FW: Removal of language features

Alexander Craggs
I'm sorry, I missed that suggestion.

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?

On 25/07/2017 20:41:33, doodad-js Admin <[hidden email]> wrote:

  •  1. In terms of including it in <script> tags, I don't think that is a good idea for including third party libraries in your code.  It would be hard to tell what version of JavaScript a library is using, I think it would be better to allow it to be defined by the library, instead of the user.

 

That’s why I’ve suggested a new file extension (js2).

 

  •  2. In response to "server can set MIME type", a lot of libraries are hosted on systems that don't allow you to change headers, for example Github pages.  Plus, there are several JavaScript CDNs out there that also don't let you set MIME type.

 

I’m talking about the “Accept” header, which is set by the client on each request. Browsers that support JS 2 will automatically append “application/javascript.2” to that header.

 

  • 3. Not many newer individuals know how to set headers, I don't think I'd be able to set headers on Apache off the top of my head. 

 

That’s the base of Web development, but not required on that situation.

 

 

From: Alexander Craggs [[hidden email]]
Sent: Tuesday, July 25, 2017 3:16 PM
To: Sebastian Zartner <[hidden email]>; Naveen Chawla <[hidden email]>
Cc: [hidden email]
Subject: Re: Removal of language features

 

Some thoughts on using MIME types to distinguish between versions:

 

 

May be biased, suggested a separate method of versioning with the "use es8" deceleration at the top of a file.  As a side note, since I made the other thread that seems to be discussing almost the exact same topic as this one (versioning to add breaking changes vs. versioning to remove language features), do people think it would be a good idea to discuss both thoughts solely in this thread (the more popular one?).  


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

RE: Removal of language features

doodad-js Admin
In reply to this post by Alexander Craggs

My apologizes, you still should set the “Content-Type” header from the server *as usual* if that’s not automatically done.


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

RE: FW: Removal of language features

doodad-js Admin
In reply to this post by Alexander Craggs
  • How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

For inline, that’ll be:

 

<script type=”application/javascript.2>...</script>

 

For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify.

 

  • Are extensions going to be released often, or is this going to be a one time thing?

 

Just at another new major revision of JS, which should not happen before a long time.

 

  • would it make more sense to start on js7 instead of js2

 

No, because ES6, ES7, ... are still JS 1.

 

 

From: Alexander Craggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

I'm sorry, I missed that suggestion.

 

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?


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

RE: FW: Removal of language features

Alexander Craggs
I think version interoperability is a must in a world of Webpack & Browserify.

On 25/07/2017 21:12:58, doodad-js Admin <[hidden email]> wrote:

  • How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

For inline, that’ll be:

 

<script type=”application/javascript.2>...</script>

 

For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify.

 

  • Are extensions going to be released often, or is this going to be a one time thing?

 

Just at another new major revision of JS, which should not happen before a long time.

 

  • would it make more sense to start on js7 instead of js2

 

No, because ES6, ES7, ... are still JS 1.

 

 

From: Alexander Craggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

I'm sorry, I missed that suggestion.

 

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?


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

Re: FW: Removal of language features

Brendan Eich-6
This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-(

Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2.

"Don't break the web" is not some vague high-minded notion of TC39's. It's a consequence of hard-to-change browser-market game theory. No browser wants to risk (however small the risk) breaking what might be more of the web than one thinks at first. It's very hard to find out what "the web" is and prove absence of breakage (paywalls, firewalls, archives, intranets, etc.). There's very little gain and potentially much pain, which could mean support calls and market share loss.

This is not just a browser market failure. Developers don't want their code broken, until they stop using something and then ask for it to be removed. That is not globally coordinated so it won't fly, as browser market share depends in part on developer testing and use of browsers. Ecosystem effects mitigate against breaking the web in deep ways, _in general_.

Yet ECMA-262 has broken compatibility in a few edge cases. And browser competition led to some dead limbs and underspecified pain-points (e.g., global object prototype chain).

And Google people seem to be leading the Web Intervention Community Group, which wants to break the web a bit (rather than block 3rd party ad/tracking scripts :-P). So perhaps we can break some DOM APIs such as sync touch events, without also breaking gmail :-). The jury is still out in my view, but Chrome has enough market power to push and assume more risk than other browsers.

Core language changes are different in kind from sync touch events. It's very hard to plan to remove anything on a practical schedule or order-of-work basis. Engine maintainers likely still hate more modes, and users should too. New syntax as its own opt-in still wins, although this obligates TC39 to work on future-proofing, e.g., : after declarator name in declaration for type annotation syntax.

So based on 22+ years doing JS, I believe anything like opt-in versioning for ES4, a la Python3 or Perl6, is a non-starter. Period, end of story.

Ok, I'm not unsubscribing -- but I hope more people read and search https://esdiscuss.org/ and engage with history instead of coming as if to a blank slate. Santayana's dictum applies.

/be

On Tue, Jul 25, 2017 at 2:10 PM Alexander Craggs <[hidden email]> wrote:
I think version interoperability is a must in a world of Webpack & Browserify.

On 25/07/2017 21:12:58, doodad-js Admin <[hidden email]> wrote:

  • How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

For inline, that’ll be:

 

<script type=”application/javascript.2>...</script>

 

For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify.

 

  • Are extensions going to be released often, or is this going to be a one time thing?

 

Just at another new major revision of JS, which should not happen before a long time.

 

  • would it make more sense to start on js7 instead of js2

 

No, because ES6, ES7, ... are still JS 1.

 

 

From: Alexander Craggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

I'm sorry, I missed that suggestion.

 

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?

_______________________________________________
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: FW: Removal of language features

Bruno Jouhier
In reply to this post by doodad-js Admin
Reading this thread, it feels that cleaning the language raises more problems than it solves. It is not even clear how versions should be flagged.

TC39 has worked very hard to keep the language backward compatible and avoid "breaking the web". So only a very strong motive would justify removal of features. Security is one and that explains why arguments.callee is going away, but I don't see others. Even performance isn't a strong enough motive: libraries that don't perform because of inefficient language features  (with, eval) will just die or be replaced. No need to be proactive here, just let the Darwinian process take its course.

Language cleanup is the business of linters. They let you enforce modern features within your teams/projects, without impacting others nor existing libraries. 

Derived languages and transpilers (TypeScript) are the perfect place to experiment with new features. This is much better than taking chances with JavaScript itself.

If it ain't broke, don't fix it.

Bruno

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

RE: FW: Removal of language features

doodad-js Admin
In reply to this post by Brendan Eich-6

We are just talking on how we can enhance JS without “breaking the web”. And the solution we are talking about is to make a major revision of JS (JS version 2), instead of breaking the current one (JS version 1).

 

From: Brendan Eich [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 5:51 PM
To: Alexander Craggs <[hidden email]>; doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-(

 

Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2.

 

"Don't break the web" is not some vague high-minded notion of TC39's. It's a consequence of hard-to-change browser-market game theory. No browser wants to risk (however small the risk) breaking what might be more of the web than one thinks at first. It's very hard to find out what "the web" is and prove absence of breakage (paywalls, firewalls, archives, intranets, etc.). There's very little gain and potentially much pain, which could mean support calls and market share loss.

 

This is not just a browser market failure. Developers don't want their code broken, until they stop using something and then ask for it to be removed. That is not globally coordinated so it won't fly, as browser market share depends in part on developer testing and use of browsers. Ecosystem effects mitigate against breaking the web in deep ways, _in general_.

 

Yet ECMA-262 has broken compatibility in a few edge cases. And browser competition led to some dead limbs and underspecified pain-points (e.g., global object prototype chain).

 

And Google people seem to be leading the Web Intervention Community Group, which wants to break the web a bit (rather than block 3rd party ad/tracking scripts :-P). So perhaps we can break some DOM APIs such as sync touch events, without also breaking gmail :-). The jury is still out in my view, but Chrome has enough market power to push and assume more risk than other browsers.

 

Core language changes are different in kind from sync touch events. It's very hard to plan to remove anything on a practical schedule or order-of-work basis. Engine maintainers likely still hate more modes, and users should too. New syntax as its own opt-in still wins, although this obligates TC39 to work on future-proofing, e.g., : after declarator name in declaration for type annotation syntax.

 

So based on 22+ years doing JS, I believe anything like opt-in versioning for ES4, a la Python3 or Perl6, is a non-starter. Period, end of story.

 

Ok, I'm not unsubscribing -- but I hope more people read and search https://esdiscuss.org/ and engage with history instead of coming as if to a blank slate. Santayana's dictum applies.

 

/be

 

On Tue, Jul 25, 2017 at 2:10 PM Alexander Craggs <[hidden email]> wrote:

I think version interoperability is a must in a world of Webpack & Browserify.

On 25/07/2017 21:12:58, doodad-js Admin <[hidden email]> wrote:

·         How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

For inline, that’ll be:

 

<script type=”application/javascript.2>...</script>

 

For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify.

 

·         Are extensions going to be released often, or is this going to be a one time thing?

 

Just at another new major revision of JS, which should not happen before a long time.

 

·         would it make more sense to start on js7 instead of js2

 

No, because ES6, ES7, ... are still JS 1.

 

 

From: Alexander Craggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

I'm sorry, I missed that suggestion.

 

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?

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

 

Virus-free. www.avg.com

 


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

RE: FW: Removal of language features

doodad-js Admin
In reply to this post by Alexander Craggs

With something like Babel, we should be able to transpile from JS 2 to JS 1 for backward compatibility. We are already doing it from ES6/ES7 to ES5.

 

From: Alexander Craggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2017 5:08 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: RE: FW: Removal of language features

 

I think version interoperability is a must in a world of Webpack & Browserify.

On 25/07/2017 21:12:58, doodad-js Admin <[hidden email]> wrote:

·         How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

For inline, that’ll be:

 

<script type=”application/javascript.2>...</script>

 

For REPL, I don’t know... I didn’t think about this one :-) It should be based of the content of the page. And I don’t know if we should allow to mix different versions together. That’s things we’ll have to clarify.

 

·         Are extensions going to be released often, or is this going to be a one time thing?

 

Just at another new major revision of JS, which should not happen before a long time.

 

·         would it make more sense to start on js7 instead of js2

 

No, because ES6, ES7, ... are still JS 1.

 

 

From: Alexander Craggs [[hidden email]]
Sent: Tuesday, July 25, 2017 3:54 PM
To: doodad-js Admin <[hidden email]>; [hidden email]
Subject: Re: FW: Removal of language features

 

I'm sorry, I missed that suggestion.

 

That definitely sounds significantly better than a new MIME type.  Although two thoughts I have are:

 

 - How are you going to deal with scenarios that don't have extensions, e.g. REPL or inline JS.

 

 - Are extensions going to be released often, or is this going to be a one time thing?  For example, would we increment the version number with the current JS version (js6, js7 etc) and if so, would it make more sense to start on js7 instead of js2?

 

Virus-free. www.avg.com

 


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

Re: Re: FW: Removal of language features

Marky Mark
In reply to this post by Bruno Jouhier

I hope more people read and search https://esdiscuss.org/ and engage with history instead of coming as if to a blank slate.

In all fairness, es-discuss is rather ancient in the way it works. I personally would recommend es-discuss coming up with a better way to keep track of its threads. The current setup is rather confusing, imo. FWIW, I personally would recommend Discourse. I agree with you on the same topics coming up constantly though.
.

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

Re: Re: FW: Removal of language features

Andreas Rossberg-4
As for the reoccurring assumption that deprecation would help simplifying JavaScript implementations: no, not to a relevant degree. 80+% of the complexity in a JS VM comes from the plethora of (sometimes ridiculous) edge cases in the core semantics of JavaScript, its object model, implicit conversions, etc., and the desire to make all that fast in the common case without breaking correctness of the million special cases. None of that can be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard. Strict mode already is a pig when it comes to implementation complexity (in retrospect, it does not carry its weight IMHO). ES6 made it worse. Our experiments with strong mode a while ago increased complexity even further, so much that the urge to rip it out again overtook very quickly. I for one am eternally healed of modes.

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

Re: Re: FW: Removal of language features

Michał Wadas
Simple idea:
  • Add new Annex to language.
  • Define operation EmitDeprecationWarning(code) - implementations MAY show deprecation warning in implementation dependent way (it can depend on runtime flag, dev tools, not minified code, etc.); otherwise operation EmitDeprecationWarning is noop
  • Define when implementations SHOULD emit deprecations warnings - like using with statement, non-standard Reg-Exp properties, compile method, assign to arguments, getYear etc.
  • Language features can be removed after 10 (15?) years

On Wed, Jul 26, 2017 at 11:55 AM, Andreas Rossberg <[hidden email]> wrote:
As for the reoccurring assumption that deprecation would help simplifying JavaScript implementations: no, not to a relevant degree. 80+% of the complexity in a JS VM comes from the plethora of (sometimes ridiculous) edge cases in the core semantics of JavaScript, its object model, implicit conversions, etc., and the desire to make all that fast in the common case without breaking correctness of the million special cases. None of that can be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard. Strict mode already is a pig when it comes to implementation complexity (in retrospect, it does not carry its weight IMHO). ES6 made it worse. Our experiments with strong mode a while ago increased complexity even further, so much that the urge to rip it out again overtook very quickly. I for one am eternally healed of modes.

_______________________________________________
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: FW: Removal of language features

Brendan Eich-6
In reply to this post by Andreas Rossberg-4
Hi Andreas, is this the best link to the Strong Mode post-mortem?


/be

On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg <[hidden email]> wrote:
As for the reoccurring assumption that deprecation would help simplifying JavaScript implementations: no, not to a relevant degree. 80+% of the complexity in a JS VM comes from the plethora of (sometimes ridiculous) edge cases in the core semantics of JavaScript, its object model, implicit conversions, etc., and the desire to make all that fast in the common case without breaking correctness of the million special cases. None of that can be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard. Strict mode already is a pig when it comes to implementation complexity (in retrospect, it does not carry its weight IMHO). ES6 made it worse. Our experiments with strong mode a while ago increased complexity even further, so much that the urge to rip it out again overtook very quickly. I for one am eternally healed of modes.
_______________________________________________
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: FW: Removal of language features

Andreas Rossberg-4
On 26 July 2017 at 17:38, Brendan Eich <[hidden email]> wrote:
Hi Andreas, is this the best link to the Strong Mode post-mortem?


Yup.


On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg <[hidden email]> wrote:
As for the reoccurring assumption that deprecation would help simplifying JavaScript implementations: no, not to a relevant degree. 80+% of the complexity in a JS VM comes from the plethora of (sometimes ridiculous) edge cases in the core semantics of JavaScript, its object model, implicit conversions, etc., and the desire to make all that fast in the common case without breaking correctness of the million special cases. None of that can be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard. Strict mode already is a pig when it comes to implementation complexity (in retrospect, it does not carry its weight IMHO). ES6 made it worse. Our experiments with strong mode a while ago increased complexity even further, so much that the urge to rip it out again overtook very quickly. I for one am eternally healed of modes.
_______________________________________________
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
12345