Removal of language features

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

RE: FW: Removal of language features

doodad-js Admin

I feel like a reticence on starting a new version of JS. After all, JS is only at version 1 and has survived at least 20 years. Every software, including languages, are having major versions with breaking changes. And I don’t see why JS should be an exception. That just would be great to make a big cleanup, stabilize things, make real classes, a real type system (dynamic or static) ... But maybe that’s reserved for another new Web language after all.

 

From: Brendan Eich [mailto:[hidden email]]
Sent: Wednesday, July 26, 2017 6:19 PM
To: Florian Bösch <[hidden email]>
Cc: T.J. Crowder <[hidden email]>; doodad-js Admin <[hidden email]>; es-discuss <[hidden email]>
Subject: Re: FW: Removal of language features

 

Languages have warts, not just JS. No cleanup is perfect, and more warts come over time. If your point is merely about a "language you hate" but must perforce use  on the Web, I think you should be happy right now. The solution is not to hate JS. It's not going to change incompatibly. Rather, you can use linters, "transpilers", compilers, voluntary unchecked subsets -- all possible today.

 

If you then object to having to use a tool or a subsetting discipline, I'm not sure what to say. The `with` statement is not forcing you to use it. Avoid it!

 

If you are concerned with the "painting into the corner" problem for engine implementors, the big ones are all in the room here and they can cope.

 

If you are concerned about JS pedagogy or marketing, the solution already practiced is to subset. Just as when teaching English or another evolved, irregularity-ridden living language.

 

/be


_______________________________________________
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

Tab Atkins Jr.
In reply to this post by Florian Bösch
On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[hidden email]> wrote:
> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[hidden email]>
> wrote:
>>
>> The solution is not to hate JS. It's not going to change incompatibly.
>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>> subsets -- all possible today.
>
>
> So basically "the best way to use JS is to not use JS". Awesome.

That's the downside of shipping your programs to customers as source,
and letting them use any of 100+ compilers of varying ages and quality
to compile your code.  (There's plenty of upsides, of course.)

As Brendan said, examples of other languages don't really apply,
because they compile on the developer end, and just ship binaries to
customers. (Or something that has the same effect, like shipping
source+interpreter to customers in a package.)  If you want to benefit
from those network dynamics, you have to compile on your end, or in
the language of today, "transpile".

That doesn't mean "not use JS" - Babel and related projects let you
use modern JS, and you can apply whatever restrictions you want.  Or
you can go ahead and abandon JS, and use one of the myriad of
alternative transpilation languages. Whatever floats your boat.

But you can't get around the mathematics.  Delivering plain source,
without a well-controlled compiler monopoly, means breaking changes
are very, very hard to make.  Best to make peace with it and engineer
around it, rather than futilely fight it.

~TJ
_______________________________________________
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

Michael Kriegel
I read this discussion for a long time and I do not see anything which
helps anyone...

I see TC39 members/supporters who say, there is no issue for them still
having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from a few that we are near the point of JS
painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that
deprecation would help simplifying JavaScript implementations: no, not
to a relevant degree (...) And clearly, modes or versions only make
things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because
of backwards compatibility and as long as browser vendors do not
indicate having trouble maintaining the old features and as long as
those old features are not security risks by design, there is no need to
discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features
around, which I do not use. If there are features a group of people (and
even if it were the whole JS developer community) agrees to be evil,
they can agree not to use them. And as a developer using JavaScript I am
thankful for the great work the TC39 and browser vendor guys do to keep
this all rolling. And if they say one time, that they (for a good
reason) have to abandon a feature, which I used and maybe even liked, I
would spend all time necessary on making my software work without it.
That being said I see no value in us developers discussing about
removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:

> On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[hidden email]> wrote:
>> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[hidden email]>
>> wrote:
>>> The solution is not to hate JS. It's not going to change incompatibly.
>>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>>> subsets -- all possible today.
>>
>> So basically "the best way to use JS is to not use JS". Awesome.
> That's the downside of shipping your programs to customers as source,
> and letting them use any of 100+ compilers of varying ages and quality
> to compile your code.  (There's plenty of upsides, of course.)
>
> As Brendan said, examples of other languages don't really apply,
> because they compile on the developer end, and just ship binaries to
> customers. (Or something that has the same effect, like shipping
> source+interpreter to customers in a package.)  If you want to benefit
> from those network dynamics, you have to compile on your end, or in
> the language of today, "transpile".
>
> That doesn't mean "not use JS" - Babel and related projects let you
> use modern JS, and you can apply whatever restrictions you want.  Or
> you can go ahead and abandon JS, and use one of the myriad of
> alternative transpilation languages. Whatever floats your boat.
>
> But you can't get around the mathematics.  Delivering plain source,
> without a well-controlled compiler monopoly, means breaking changes
> are very, very hard to make.  Best to make peace with it and engineer
> around it, rather than futilely fight it.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


_______________________________________________
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

Isiah Meadows-2

I agree. The only people who really have a stake in this discussion apart from committee members are implementors, and trust me: they really don't like having to support features deprecated for over a decade.

My only question at this point is: would it be possible to emit deprecation warnings for some features, so it would be easier to remove some of the legacy bloat? (example: `RegExp.$1`)


On Thu, Jul 27, 2017, 01:21 Michael Kriegel <[hidden email]> wrote:
I read this discussion for a long time and I do not see anything which
helps anyone...

I see TC39 members/supporters who say, there is no issue for them still
having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from a few that we are near the point of JS
painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that
deprecation would help simplifying JavaScript implementations: no, not
to a relevant degree (...) And clearly, modes or versions only make
things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because
of backwards compatibility and as long as browser vendors do not
indicate having trouble maintaining the old features and as long as
those old features are not security risks by design, there is no need to
discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features
around, which I do not use. If there are features a group of people (and
even if it were the whole JS developer community) agrees to be evil,
they can agree not to use them. And as a developer using JavaScript I am
thankful for the great work the TC39 and browser vendor guys do to keep
this all rolling. And if they say one time, that they (for a good
reason) have to abandon a feature, which I used and maybe even liked, I
would spend all time necessary on making my software work without it.
That being said I see no value in us developers discussing about
removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:
> On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[hidden email]> wrote:
>> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[hidden email]>
>> wrote:
>>> The solution is not to hate JS. It's not going to change incompatibly.
>>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>>> subsets -- all possible today.
>>
>> So basically "the best way to use JS is to not use JS". Awesome.
> That's the downside of shipping your programs to customers as source,
> and letting them use any of 100+ compilers of varying ages and quality
> to compile your code.  (There's plenty of upsides, of course.)
>
> As Brendan said, examples of other languages don't really apply,
> because they compile on the developer end, and just ship binaries to
> customers. (Or something that has the same effect, like shipping
> source+interpreter to customers in a package.)  If you want to benefit
> from those network dynamics, you have to compile on your end, or in
> the language of today, "transpile".
>
> That doesn't mean "not use JS" - Babel and related projects let you
> use modern JS, and you can apply whatever restrictions you want.  Or
> you can go ahead and abandon JS, and use one of the myriad of
> alternative transpilation languages. Whatever floats your boat.
>
> But you can't get around the mathematics.  Delivering plain source,
> without a well-controlled compiler monopoly, means breaking changes
> are very, very hard to make.  Best to make peace with it and engineer
> around it, rather than futilely fight it.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


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

Michael Kriegel
Maybe TC39 should think about a deprecation plan, which includes rules for fairness between browser vendors. For example, if the feature `RegExp.$1` shall be removed. Then:

1. At date X, the feature gets marked as deprecated.

2. Within 6 Months from X, all browser vendors must have taken this feature up in their deprecation list and show a deprecation warning in the console.

3. At a fixed date (e.g. 12 Months after X) all browsers must show a warning to the user (e.g. red address bar, etc.), when the website he visits uses a feature from the deprecation list: "The website you are visiting uses features, which will be removed in the future. Please ask the website owner to update his website." - All browser vendors are obliged to start this warning beginning with that date - so the browser has to check for the date.

4. At a fixed date (e.g. 24 Months after X) all browsers must stop supporting the feature, which means that they just refuse to show that broken website and instead show a message to the user, that the website cannot be shown anymore, because its features are not supported anymore.

5. All browser versions released after that must have the feature permanently disabled or removed.

Authors of Websites, for which there is still interest, will update their code. Other websites will just break and nobody will care. Companies using browser based internal tools may decide to stick with older browser versions for that purpose, which is totally fine, it's their risk (security holes, etc.?)

(Optional idea at step 2: If the website author enabled it, the browser tries to send a deprecation warning to [hidden email] where whatever.ch is the domain of the website the user visited. Or maybe this should be communicated to the web server which may then send a message itself)

So I do not see a risk of "breaking the web" when there is such a clear plan set up. There would be just the question how browser vendors could be punished, if they do not comply and try to get an advantage over other browsers by continuing support of those old features...? Maybe search engine developers could agree on degrading websites which use deprecated features after point 3 in time, which would reduce the interest of people in that web site and increase the will of the website owner to improve.

This was just thinking out loud... I will stick to every decision TC39 makes about language feature removal.


On 27.07.2017 07:33, Isiah Meadows wrote:

I agree. The only people who really have a stake in this discussion apart from committee members are implementors, and trust me: they really don't like having to support features deprecated for over a decade.

My only question at this point is: would it be possible to emit deprecation warnings for some features, so it would be easier to remove some of the legacy bloat? (example: `RegExp.$1`)


On Thu, Jul 27, 2017, 01:21 Michael Kriegel <[hidden email]> wrote:
I read this discussion for a long time and I do not see anything which
helps anyone...

I see TC39 members/supporters who say, there is no issue for them still
having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from a few that we are near the point of JS
painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that
deprecation would help simplifying JavaScript implementations: no, not
to a relevant degree (...) And clearly, modes or versions only make
things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because
of backwards compatibility and as long as browser vendors do not
indicate having trouble maintaining the old features and as long as
those old features are not security risks by design, there is no need to
discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features
around, which I do not use. If there are features a group of people (and
even if it were the whole JS developer community) agrees to be evil,
they can agree not to use them. And as a developer using JavaScript I am
thankful for the great work the TC39 and browser vendor guys do to keep
this all rolling. And if they say one time, that they (for a good
reason) have to abandon a feature, which I used and maybe even liked, I
would spend all time necessary on making my software work without it.
That being said I see no value in us developers discussing about
removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:
> On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[hidden email]> wrote:
>> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[hidden email]>
>> wrote:
>>> The solution is not to hate JS. It's not going to change incompatibly.
>>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>>> subsets -- all possible today.
>>
>> So basically "the best way to use JS is to not use JS". Awesome.
> That's the downside of shipping your programs to customers as source,
> and letting them use any of 100+ compilers of varying ages and quality
> to compile your code.  (There's plenty of upsides, of course.)
>
> As Brendan said, examples of other languages don't really apply,
> because they compile on the developer end, and just ship binaries to
> customers. (Or something that has the same effect, like shipping
> source+interpreter to customers in a package.)  If you want to benefit
> from those network dynamics, you have to compile on your end, or in
> the language of today, "transpile".
>
> That doesn't mean "not use JS" - Babel and related projects let you
> use modern JS, and you can apply whatever restrictions you want.  Or
> you can go ahead and abandon JS, and use one of the myriad of
> alternative transpilation languages. Whatever floats your boat.
>
> But you can't get around the mathematics.  Delivering plain source,
> without a well-controlled compiler monopoly, means breaking changes
> are very, very hard to make.  Best to make peace with it and engineer
> around it, rather than futilely fight it.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


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

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
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

Bill Frantz
In reply to this post by Brendan Eich-6
On 7/26/17 at 3:18 PM, [hidden email] (Brendan Eich) wrote:

>If you are concerned about JS pedagogy or marketing, the solution already
>practiced is to subset. Just as when teaching English or another evolved,
>irregularity-ridden living language.

The real problem with bloat is reading code, not writing it.
However, if a reader can easily look up a nearly abandoned, but
still supported, construct to find out what it does and what
footguns it includes, that situation is probably better than
having some unmaintained web site fail when a new version of a
browser comes out that no longer supports that construct.

YMMV - Bill

-------------------------------------------------------------------------
Bill Frantz        | Re: Hardware Management Modes: | Periwinkle
(408)356-8506      | If there's a mode, there's a   | 16345
Englewood Ave
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos,
CA 95032

_______________________________________________
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

Isiah Meadows-2
In reply to this post by Michael Kriegel

Sounds good, except for a few nits:

1. Engines will know ahead of time when the deprecation will start, as it'll likely be in the draft 6 months or more before then.
2. It's one thing to print a deprecation message. It's another to alert the end user for something that shouldn't matter. It's not a security issue like using compromised certificate algorithms (getting people of MD5 was a nightmare), so it shouldn't be worth alerting the user over it.
3. Requiring browsers to stop implementing something is as easy as making it a forbidden extension (like what was already done with `arguments.caller`). I'm not sure we would need anything other than a formal document stating that practice is a thing.

Also, keep in mind, some things are much more difficult to remove (e.g. `with` statement) than others (e.g. `Function.prototype.callee`). So it may be necessary to 1. make logging optional with "should", and 2. call the relevant hook with something to denote what's being deprecated, so implementors/embedders can avoid logging things that would end up super spammy in their particular use case. For example:

- Things like `String.prototype.bold` are pretty safe to just remove in server runtimes due to being mostly useless, but not so much in browsers, where it is occasionally used.
- It's harder to remove `with` in servers than in browsers due to templating based on code gen using it being more popular there (like Lodash templates), and the lack of need to precompile for startup performance.


On Thu, Jul 27, 2017, 02:02 Michael Kriegel <[hidden email]> wrote:
Maybe TC39 should think about a deprecation plan, which includes rules for fairness between browser vendors. For example, if the feature `RegExp.$1` shall be removed. Then:

1. At date X, the feature gets marked as deprecated.

2. Within 6 Months from X, all browser vendors must have taken this feature up in their deprecation list and show a deprecation warning in the console.

3. At a fixed date (e.g. 12 Months after X) all browsers must show a warning to the user (e.g. red address bar, etc.), when the website he visits uses a feature from the deprecation list: "The website you are visiting uses features, which will be removed in the future. Please ask the website owner to update his website." - All browser vendors are obliged to start this warning beginning with that date - so the browser has to check for the date.

4. At a fixed date (e.g. 24 Months after X) all browsers must stop supporting the feature, which means that they just refuse to show that broken website and instead show a message to the user, that the website cannot be shown anymore, because its features are not supported anymore.

5. All browser versions released after that must have the feature permanently disabled or removed.

Authors of Websites, for which there is still interest, will update their code. Other websites will just break and nobody will care. Companies using browser based internal tools may decide to stick with older browser versions for that purpose, which is totally fine, it's their risk (security holes, etc.?)

(Optional idea at step 2: If the website author enabled it, the browser tries to send a deprecation warning to [hidden email] where whatever.ch is the domain of the website the user visited. Or maybe this should be communicated to the web server which may then send a message itself)

So I do not see a risk of "breaking the web" when there is such a clear plan set up. There would be just the question how browser vendors could be punished, if they do not comply and try to get an advantage over other browsers by continuing support of those old features...? Maybe search engine developers could agree on degrading websites which use deprecated features after point 3 in time, which would reduce the interest of people in that web site and increase the will of the website owner to improve.

This was just thinking out loud... I will stick to every decision TC39 makes about language feature removal.


On 27.07.2017 07:33, Isiah Meadows wrote:

I agree. The only people who really have a stake in this discussion apart from committee members are implementors, and trust me: they really don't like having to support features deprecated for over a decade.

My only question at this point is: would it be possible to emit deprecation warnings for some features, so it would be easier to remove some of the legacy bloat? (example: `RegExp.$1`)


On Thu, Jul 27, 2017, 01:21 Michael Kriegel <[hidden email]> wrote:
I read this discussion for a long time and I do not see anything which
helps anyone...

I see TC39 members/supporters who say, there is no issue for them still
having the old features in place:

Brendan Eich (TC39): "There's no evidence (I'm sitting in a TC39
meeting) other than grumping from a few that we are near the point of JS
painted into a corner by backward compatibility."

Andreas Rossberg (google): "As for the reoccurring assumption that
deprecation would help simplifying JavaScript implementations: no, not
to a relevant degree (...) And clearly, modes or versions only make
things worse in that regard."


Can't we agree on the following:

"As long as TC39 members do not feel being painted into a corner because
of backwards compatibility and as long as browser vendors do not
indicate having trouble maintaining the old features and as long as
those old features are not security risks by design, there is no need to
discuss further about the removal of language features."?

As a developer, "a user" of JavaScript I have no problem with features
around, which I do not use. If there are features a group of people (and
even if it were the whole JS developer community) agrees to be evil,
they can agree not to use them. And as a developer using JavaScript I am
thankful for the great work the TC39 and browser vendor guys do to keep
this all rolling. And if they say one time, that they (for a good
reason) have to abandon a feature, which I used and maybe even liked, I
would spend all time necessary on making my software work without it.
That being said I see no value in us developers discussing about
removing old features which we just do not like.


On 27.07.2017 01:14, Tab Atkins Jr. wrote:
> On Wed, Jul 26, 2017 at 3:37 PM, Florian Bösch <[hidden email]> wrote:
>> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <[hidden email]>
>> wrote:
>>> The solution is not to hate JS. It's not going to change incompatibly.
>>> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
>>> subsets -- all possible today.
>>
>> So basically "the best way to use JS is to not use JS". Awesome.
> That's the downside of shipping your programs to customers as source,
> and letting them use any of 100+ compilers of varying ages and quality
> to compile your code.  (There's plenty of upsides, of course.)
>
> As Brendan said, examples of other languages don't really apply,
> because they compile on the developer end, and just ship binaries to
> customers. (Or something that has the same effect, like shipping
> source+interpreter to customers in a package.)  If you want to benefit
> from those network dynamics, you have to compile on your end, or in
> the language of today, "transpile".
>
> That doesn't mean "not use JS" - Babel and related projects let you
> use modern JS, and you can apply whatever restrictions you want.  Or
> you can go ahead and abandon JS, and use one of the myriad of
> alternative transpilation languages. Whatever floats your boat.
>
> But you can't get around the mathematics.  Delivering plain source,
> without a well-controlled compiler monopoly, means breaking changes
> are very, very hard to make.  Best to make peace with it and engineer
> around it, rather than futilely fight it.
>
> ~TJ
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02


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

-- 
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02

_______________________________________________
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
> 3. At a fixed date (e.g. 12 Months after X) all browsers must show a 
> warning to the user (e.g. red address bar, etc.), when the website he 
> visits uses a feature from the deprecation list: "The website you are 
> visiting uses features, which will be removed in the future. Please ask 
> the website owner to update his website." - All browser vendors are 
> obliged to start this warning beginning with that date - so the browser 
> has to check for the date.

My step mother calls me: Bruno, there is a strange message on my screen. 
Can you help! I reassure here.

> 4. At a fixed date (e.g. 24 Months after X) all browsers must stop 
> supporting the feature, which means that they just refuse to show that 
> broken website and instead show a message to the user, that the website 
> cannot be shown anymore, because its features are not supported anymore.

My step mother calls again: my tablet is broken, can you fix it?

The web site that my step mother was visiting was built by the
non-profit accountant's nephew eight years ago. He is climbing a mountain.

We see things with our technologist eyes. Many (most?) web users don't 
understand whether something is wrong with the browser or with the server,
or with the network (and they don't care). For them it is just "broken".

We've broken the web. My step mother is happy with her apps.

_______________________________________________
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

I've been following this thread since it started. Maybe it's in here somewhere and I missed it throughout these many comments. But...

It has already been mentioned that there is likely no performance degradation when adding new features. If performance is an issue because a developer is using legacy/outdated methods in their code, the developer should just update their methods to use the newer better ones in the newer API that was introduced. 

Alternatively, JS has done a good job of adding new features that are optional and that do not affect outdated ones, so there is nothing lost here. If you don't want to use a new feature, don't use it... ever (if necessary).

So can someone give me at least a couple of hard use cases where introducing a new JS feature requires the removal of another? And not removing the feature, would cause significant harm to the future of the language? I don't mean just some anecdotal or insignificant case like having to choose a different reserved word because it was already used before (i.e. will we run out of words? :) ) 

AFAICT, the committee is working extremely hard to introduce some pretty new and exciting things to JS every day. And I don't think this progress would be improved that much by removal old JS features. So I'm seriously having trouble understanding the assumption that we need to remove JS features just to move the language forward.


On Thu, Jul 27, 2017, 4:30 AM Bruno Jouhier <[hidden email]> wrote:
> 3. At a fixed date (e.g. 12 Months after X) all browsers must show a 
> warning to the user (e.g. red address bar, etc.), when the website he 
> visits uses a feature from the deprecation list: "The website you are 
> visiting uses features, which will be removed in the future. Please ask 
> the website owner to update his website." - All browser vendors are 
> obliged to start this warning beginning with that date - so the browser 
> has to check for the date.

My step mother calls me: Bruno, there is a strange message on my screen. 
Can you help! I reassure here.

> 4. At a fixed date (e.g. 24 Months after X) all browsers must stop 
> supporting the feature, which means that they just refuse to show that 
> broken website and instead show a message to the user, that the website 
> cannot be shown anymore, because its features are not supported anymore.

My step mother calls again: my tablet is broken, can you fix it?

The web site that my step mother was visiting was built by the
non-profit accountant's nephew eight years ago. He is climbing a mountain.

We see things with our technologist eyes. Many (most?) web users don't 
understand whether something is wrong with the browser or with the server,
or with the network (and they don't care). For them it is just "broken".

We've broken the web. My step mother is happy with her apps.
_______________________________________________
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 27 July 2017 at 11:00, Mark <[hidden email]> wrote:

It has already been mentioned that there is likely no performance degradation when adding new features.


That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.

_______________________________________________
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
Yeah, but performance issues are different from not being backwards-compatible.

I think it is a mistake to assume that a developer has a right to always have optimal performance without requiring anything to get it.  It almost sounds like you're saying that there should be no cost to the consumer for choosing not to evolve with the language.

Things we buy into in life (not just a coding language) will depreciate in value and will require either an upgrade or a replacement or significant maintenance and, if not done, the consumer will suffer the consequences of choosing to remain stagnant. And the longer the stagnation, the greater the change needed to put the consumer in the same (or better) position they were in before the depreciation got so bad.

That said, I'm still struggling to see a real need to remove older JS features.

On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg <[hidden email]> wrote:
On 27 July 2017 at 11:00, Mark <[hidden email]> wrote:

It has already been mentioned that there is likely no performance degradation when adding new features.


That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.

_______________________________________________
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 27 July 2017 at 12:07, Mark <[hidden email]> wrote:
I think it is a mistake to assume that a developer has a right to always have optimal performance without requiring anything to get it.  It almost sounds like you're saying that there should be no cost to the consumer for choosing not to evolve with the language.

In an ideal world, I would agree. But that's not how the game theory works out on the web. What Brendan already pointed out wrt breaking sites also applies to performance regressions: if Joe User observes that a website suddenly got notably slower with a new version of their browser then they will blame the browser. That effect is further elevated by tech reviews often performing measurements with hopelessly outdated benchmarks. So no browser vendor can afford significant regressions, unless they have an urge to look bad in public perception.

 

Things we buy into in life (not just a coding language) will depreciate in value and will require either an upgrade or a replacement or significant maintenance and, if not done, the consumer will suffer the consequences of choosing to remain stagnant. And the longer the stagnation, the greater the change needed to put the consumer in the same (or better) position they were in before the depreciation got so bad.

That said, I'm still struggling to see a real need to remove older JS features.

On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg <[hidden email]> wrote:
On 27 July 2017 at 11:00, Mark <[hidden email]> wrote:

It has already been mentioned that there is likely no performance degradation when adding new features.


That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.


_______________________________________________
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

kai zhu
In reply to this post by Andreas Rossberg-4
On Jul 27, 2017, at 5:43 PM, Andreas Rossberg <[hidden email]> wrote:

That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.

I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe its due to performance-penalty of extra parser complexity, maybe not.  Also, the chrome-based electron-browser has gotten slower with each release over the past year, when I use it to test mostly es5-based browser-code.  Can’t say about the other browser-vendors as I don’t use them as much.
_______________________________________________
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

T.J. Crowder-2
On Thu, Jul 27, 2017 at 12:55 PM, kai zhu
> I’ve noticed chrome 59 freezing more when initially loading
> pages. Maybe its due to performance-penalty of extra parser
> complexity, maybe not.

Much more likely due to the major changes in V8 v5.9: https://v8project.blogspot.co.uk/2017/05/launching-ignition-and-turbofan.html

-- T.J. Crowder

_______________________________________________
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

Marky Mark
In reply to this post by kai zhu

Reposting (with edits) because I accidentally sent this to only Andreas

if Joe User observes that a website suddenly got notably slower with a new version of their browser then they will blame the browser.

This is a rather large assumption to make and, at the same time, I don’t think it is true. When users go to a slow-loading website, I think it’s much more likely they’ll blame the website developer. If an application runs slow on your OS, you wouldn’t blame it on the OS vendor. Similarly, if an application I just upgraded runs slow on my mobile device, I wouldn’t automatically assume it's the phone manufacturer.


On Thu, Jul 27, 2017 at 7:55 AM kai zhu <[hidden email]> wrote:
On Jul 27, 2017, at 5:43 PM, Andreas Rossberg <[hidden email]> wrote:

That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.

I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe its due to performance-penalty of extra parser complexity, maybe not.  Also, the chrome-based electron-browser has gotten slower with each release over the past year, when I use it to test mostly es5-based browser-code.  Can’t say about the other browser-vendors as I don’t use them as much.

_______________________________________________
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

Andreas Rossberg-4
On 27 July 2017 at 14:23, Mark <[hidden email]> wrote:


if Joe User observes that a website suddenly got notably slower with a new version of their browser then they will blame the browser.

This is a rather large assumption to make and, at the same time, I don’t think it is true. When users go to a slow-loading website, I think it’s much more likely they’ll blame the website developer. If an application runs slow on your OS, you wouldn’t blame it on the OS vendor. Similarly, if an application I just upgraded runs slow on my mobile device, I wouldn’t automatically assume it's the phone manufacturer.

I'm talking about the situation were they upgrade the browser and observe that a known site runs slower afterwards than it did before. Nothing else changed. Of course they gonna blame it on the browser update, and correctly so.

 

On Thu, Jul 27, 2017 at 7:55 AM kai zhu <[hidden email]> wrote:
On Jul 27, 2017, at 5:43 PM, Andreas Rossberg <[hidden email]> wrote:

That is not always true. For example, ES6 has caused some notable performance regressions for ES5 code initially, due to extensions to the object model that made it even more dynamic. The new @@-hooks were particularly nasty and some cases required substantial amounts of work from implementers just to get back close to the previous baseline performance. Parsing also slowed down measurably. Moreover, many features tend to add combinatorial complexity that can make the surface of "common cases" to optimise for in preexisting features much larger.

I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe its due to performance-penalty of extra parser complexity, maybe not.  Also, the chrome-based electron-browser has gotten slower with each release over the past year, when I use it to test mostly es5-based browser-code.  Can’t say about the other browser-vendors as I don’t use them as much.


_______________________________________________
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

Boris Zbarsky
In reply to this post by Michael Kriegel
On 7/27/17 2:02 AM, Michael Kriegel wrote:
> 4. At a fixed date (e.g. 24 Months after X) all browsers must stop
> supporting the feature

How do you plan to enforce this?

Please note that the people representing browsers in this committee may
not (and afaict generally do not) make ship/no-ship product decisions
for their browsers, so the can't even credibly commit to what you suggest.

> Authors of Websites, for which there is still interest, will update
> their code. Other websites will just break and nobody will care.

Unfortunately, you're wrong.  That's because interest is asymmetric:
_users_ may have interest in a site even if the _author_ does not.  So
it's quite possible (and in fact has happened before) that sites will
not be updated, they will break, and users will in fact care.

This happens all the time, even with well-advertised multi-year
deprecations, well publicized cutoff times and large companies that have
the resources to update their sites if they want to.  See the story of
Google Hangouts, for example.

> So I do not see a risk of "breaking the web" when there is such a clear
> plan set up. There would be just the question how browser vendors could
> be punished, if they do not comply and try to get an advantage over
> other browsers by continuing support of those old features...?

Good luck with that.

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

Mike Samuel
In reply to this post by Isiah Meadows-2
On Thu, Jul 27, 2017 at 1:33 AM, Isiah Meadows <[hidden email]> wrote:
> I agree. The only people who really have a stake in this discussion apart
> from committee members are implementors, and trust me: they really don't
> like having to support features deprecated for over a decade.

I am not an implementor, but I would like to restake my claim as a
security practitioner that I made in

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


> My only question at this point is: would it be possible to emit deprecation
> warnings for some features, so it would be easier to remove some of the
> legacy bloat? (example: `RegExp.$1`)

Linters were mentioned earlier as a mechanism for this.  The problem,
as Brendan pointed out, is that you have to get the usage rate very
low or have browsers coordinate closely on breaking the holdouts.
_______________________________________________
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

Allen Wirfs-Brock
In reply to this post by Michael Kriegel

On Jul 26, 2017, at 11:02 PM, Michael Kriegel <[hidden email]> wrote:

Maybe TC39 should think about a deprecation plan, which includes rules for fairness between browser vendors. For example, if the feature `RegExp.$1` shall be removed. Then:

1. At date X, the feature gets marked as deprecated.

2. Within 6 Months from X, all browser vendors must…

TC39 has absolutely no authority to tell browser vendors (or anybody else) that they must do something.

All TC39 can do is publish specifications that say what a conforming implementation must do. It is completely up to implementations to choose to conform or not. 



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