Removal of language features

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

Re: Re: FW: Removal of language features

Brendan Eich-6
On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas <[hidden email]> wrote:
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

Who sees the warnings? Publishers hire contractors to build (re-build) site in year N, in year N+M when contractors are long gone, users visit  site and get unseen warnings in their unopened devtools. What upper bound can be put on M? 
  • Define when implementations SHOULD emit deprecations warnings - like using with statement, non-standard Reg-Exp properties, compile method, assign to arguments, getYear etc.

Who sees the warnings? Not the contractors, they are long gone by year N+1.  
  • Language features can be removed after 10 (15?) years

So M=10 might work (who knows?) but it's so long a time frame that no one will act on the remote threat of breakage. And yet at Y=N+M, there will be sites (not just web.archive.org) using the old feature, I would bet real money. We know this because from looking back at when the Web was smaller and easier to coordinate.

Your model seems to assume a small-world-network coordination system. That's not the Web.

I created JS in 1995. In 1996 I made a few incompatible changes to JS and got away with it, but not in 1997. ES3 was done in 1999 based on de-facto work in Netscape and IE that converged (mostly; a few edge cases) around the same time, but even by 1998 the only way to coordinate was via the ECMA-262 standards work, not just ES1 but the discussions about future work we were having in 1997.

This kind of TC39 coordination helps for sure, don't get me wrong. But it does not solve the publisher/contractor division of labor leaving M effectively unbounded.

For a language like Java or C# used server side, where the retrograde sites can stick to old tool/runtime versions as long as vendors support them, M can be a "Goldilocks" interval, not too big, not too small. The threat of vendors obsoleting old versions pushes most customers to upgrade in time, and the customers of size can push back and keep support going an extra year or three if need be.

But that's not the Web. On the web, you don't just have the publishers and contractors, you have browser users also not coordinated except possibly by loose rules about supported browsers (banks try this and still get it wrong). Most sites do not want to turn away users based on detailed user agent version checks.

Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share?

I hope this helps. It's very hard to remove things on the Web. That's the nature of the beast.

/be

_______________________________________________
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

Mike Samuel
In reply to this post by Andreas Rossberg-4
On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg <[hidden email]> wrote:
> 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

IIRC, the primary argument for strict mode wasn't implementation
simplicity, but the ability to do sound static analysis.

var x;
function f(a, b) {
  a(b);
  return x;
}

isn't analyzable because f(eval, 'var x = 1;') could cause the
returned x to refer to a local instead of the outer x but add "use
strict" to either scope and suddenly it is statically analyzable.

When you say that strict mode "does not carry its weight," are you
saying that that the ability to do sounds static analysis doesn't
warrant the additional complexity or are you referring to a different
bundle of benefits?
_______________________________________________
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 Brendan Eich-6
One thing that may not be obvious:

On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich <[hidden email]> wrote:
I created JS in 1995. In 1996 I made a few incompatible changes to JS and got away with it, but not in 1997. ES3 was done in 1999 based on de-facto work in Netscape and IE that converged (mostly; a few edge cases) around the same time, but even by 1998 the only way to coordinate was via the ECMA-262 standards work, not just ES1 but the discussions about future work we were having in 1997.

Netscape had effective monopoly control of JS in 1995 and into 1996, but was losing it by 1997 with IE4 coming out. No browser has it now, although Chrome has the most market power.

Even monopolies cannot repeal price law -- they can only force deadweight losses on customers up to a limit where the customer does without, or else substitutes by going outside the monopoly system. With JS, there was risk at the limit of users going without JS. There was risk too, small at first but growing to large, of users substituting IE and even using VBScript instead of JS.

Fortunately ;-), JS was first and good-enough, and standardized enough, to head off the VBScript substitution.

So I couldn't just change JS any way I wanted based on market power. Nor can Chrome now, or in a future where it got closer to IE's top (2004?) share of 95% (per wikipedia).

/be

_______________________________________________
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
In reply to this post by Mike Samuel
On 26 July 2017 at 18:10, Mike Samuel <[hidden email]> wrote:
On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg <[hidden email]> wrote:
> 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

IIRC, the primary argument for strict mode wasn't implementation
simplicity, but the ability to do sound static analysis.

Right, I was merely lumping a reply to two different suggestions into a single reply.

 
var x;
function f(a, b) {
  a(b);
  return x;
}

isn't analyzable because f(eval, 'var x = 1;') could cause the
returned x to refer to a local instead of the outer x but add "use
strict" to either scope and suddenly it is statically analyzable.

Actually, it cannot. An indirect call to eval cannot inject anything into the caller scope.

On the other hand, any use of indirect eval can inject something into the global scope, whether the caller is in strict mode or not. Overall, I thus don't think that strict mode makes JavaScript sufficiently better.

 
When you say that strict mode "does not carry its weight," are you
saying that that the ability to do sounds static analysis doesn't
warrant the additional complexity or are you referring to a different
bundle of benefits?

The "ability to do sound static analysis" is not a binary characteristics. You can do analysis on JS. With strict mode you have a couple more invariants, so can do slightly better, but from my perspective it's not even close to a game changer.

_______________________________________________
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
Strict mode also made runtime-incompatible changes, e.g. arguments[i] not aliasing i'th formal parameter, which required two-way testing while strict mode adoption was nascent or partial (which of course many devs skipped).

On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg <[hidden email]> wrote:
The "ability to do sound static analysis" is not a binary characteristics. You can do analysis on JS. With strict mode you have a couple more invariants, so can do slightly better, but from my perspective it's not even close to a game changer.

Agreed (static analysis approximates runtime, so the ability to do it is of course not binary -- many trade-offs).

From my memory of the meetings and online discussions, strict mode was not meant to make static analysis significantly easier. More important was enabling Caja (now SES) to "use strict" and do less work, static and at runtime. Implementation and legacy loopholes continue to confound such efforts :-).

/be

_______________________________________________
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

On Jul 26, 2017, at 10:56 AM, Brendan Eich <[hidden email]> wrote:

From my memory of the meetings and online discussions, strict mode was not meant to make static analysis significantly easier. More important was enabling Caja (now SES) to "use strict" and do less work, static and at runtime. Implementation and legacy loopholes continue to confound such efforts :-).

From my memory, static analysis of eval impact was definitely a motivator for the strict mode eval semantics. Similarly, it was part of the motivation for eliminating with. 

Allen

_______________________________________________
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

Mike Samuel
In reply to this post by Brendan Eich-6
On Wed, Jul 26, 2017 at 1:56 PM, Brendan Eich <[hidden email]> wrote:

> Strict mode also made runtime-incompatible changes, e.g. arguments[i] not
> aliasing i'th formal parameter, which required two-way testing while strict
> mode adoption was nascent or partial (which of course many devs skipped).
>
> On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg <[hidden email]>
> wrote:
>>
>> The "ability to do sound static analysis" is not a binary characteristics.
>> You can do analysis on JS. With strict mode you have a couple more
>> invariants, so can do slightly better, but from my perspective it's not even
>> close to a game changer.
>
>
> Agreed (static analysis approximates runtime, so the ability to do it is of
> course not binary -- many trade-offs).

Of course, no static analysis can be complete for all programs in a
Turing complete language.

At the time it was being debated, we couldn't assume closure integrity
if a parameter could alias eval which made static analysis of even
simple programs really really hard.
It looks like both violations of closure integrity via indirect
aliasing of eval got rolled into non-strict mode though.  I was just
confused.


> From my memory of the meetings and online discussions, strict mode was not
> meant to make static analysis significantly easier. More important was
> enabling Caja (now SES) to "use strict" and do less work, static and at
> runtime. Implementation and legacy loopholes continue to confound such
> efforts :-).

Fair enough.
_______________________________________________
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

Florian Bösch
In reply to this post by Brendan Eich-6
On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich <[hidden email]> wrote:
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.

There's a point at which you cannot add anything new meaningful because of the broken things. And you can't remove the broken things because you're committed to eternal backwards compatibility. And you can't add modes because nobody likes them. That's just planned obsolescence. This means JS is not a living language, or won't be much longer in any case. It's probably best if whatever you run on the web ships its own interpreter that runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available.

_______________________________________________
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
In reply to this post by Brendan Eich-6
I know that's hard to remove features from the web. That's why I propose clear and well defined route to clean up language.

Browsers already "broke" the web many times. Java Applets are dead. ActiveX is dead (though some government websites still require it). Flash will be dead in few years. And some sites stopped working because of this.

Backward compatibility is a great thing that made Web successful. But no other environment have a goal to be backward compatible forever. Windows 98 .exe will probably not run on Windows 10. Old Android apps does not run on new devices. Very old iOS apps does not run on new devices. Why would anyone expect to run 20 years old code successfully on new browser? And why we limit it only to JavaScript code, if other Web APIs and behaviours were changed in past?


On Wed, Jul 26, 2017 at 5:52 PM, Brendan Eich <[hidden email]> wrote:
On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas <[hidden email]> wrote:
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

Who sees the warnings? Publishers hire contractors to build (re-build) site in year N, in year N+M when contractors are long gone, users visit  site and get unseen warnings in their unopened devtools. What upper bound can be put on M? 
  • Define when implementations SHOULD emit deprecations warnings - like using with statement, non-standard Reg-Exp properties, compile method, assign to arguments, getYear etc.

Who sees the warnings? Not the contractors, they are long gone by year N+1.  
  • Language features can be removed after 10 (15?) years

So M=10 might work (who knows?) but it's so long a time frame that no one will act on the remote threat of breakage. And yet at Y=N+M, there will be sites (not just web.archive.org) using the old feature, I would bet real money. We know this because from looking back at when the Web was smaller and easier to coordinate.

Your model seems to assume a small-world-network coordination system. That's not the Web.

I created JS in 1995. In 1996 I made a few incompatible changes to JS and got away with it, but not in 1997. ES3 was done in 1999 based on de-facto work in Netscape and IE that converged (mostly; a few edge cases) around the same time, but even by 1998 the only way to coordinate was via the ECMA-262 standards work, not just ES1 but the discussions about future work we were having in 1997.

This kind of TC39 coordination helps for sure, don't get me wrong. But it does not solve the publisher/contractor division of labor leaving M effectively unbounded.

For a language like Java or C# used server side, where the retrograde sites can stick to old tool/runtime versions as long as vendors support them, M can be a "Goldilocks" interval, not too big, not too small. The threat of vendors obsoleting old versions pushes most customers to upgrade in time, and the customers of size can push back and keep support going an extra year or three if need be.

But that's not the Web. On the web, you don't just have the publishers and contractors, you have browser users also not coordinated except possibly by loose rules about supported browsers (banks try this and still get it wrong). Most sites do not want to turn away users based on detailed user agent version checks.

Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share?

I hope this helps. It's very hard to remove things on the Web. That's the nature of the beast.

/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

T.J. Crowder-2
In reply to this post by Florian Bösch
On Wed, Jul 26, 2017 at 7:37 PM, Florian Bösch <[hidden email]> wrote:
> This means JS is not a living language, or won't be much longer in any case.

"Much longer" is of course entirely subjective, but let's not be too dramatic; I think we can count on JavaScript being a living language for *at least* another 10 years, regardless of what happens with WebAssembly and similar.

If WebAssembly (or similar) does stabilize, spread, and mature, that will enable a thriving ecosystem of languages that compile to it, making JavaScript only one of many (just as it is now outside of browsers). I love the language, but I love the idea of it being one of many that can target browsers even more.

And that will probably allow JavaScript itself more freedom at that point in terms of evolution, keeping it alive and healthy beyond its browser-limited existence.

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

Brendan Eich-6
In reply to this post by Florian Bösch
1. 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.

2. WebAssembly is happening. Dynamic language support will  take a while.

Together these suggest JS evolution will continue. It shall continue.

/be

On Wed, Jul 26, 2017 at 11:37 AM Florian Bösch <[hidden email]> wrote:
On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich <[hidden email]> wrote:
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.

There's a point at which you cannot add anything new meaningful because of the broken things. And you can't remove the broken things because you're committed to eternal backwards compatibility. And you can't add modes because nobody likes them. That's just planned obsolescence. This means JS is not a living language, or won't be much longer in any case. It's probably best if whatever you run on the web ships its own interpreter that runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available.

_______________________________________________
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

Florian Bösch
In reply to this post by T.J. Crowder-2
On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <[hidden email]> wrote:
keeping it alive and healthy beyond its browser-limited existence.

Many languages (including Python and Perl)  concluded that at some point things have to be "cleaned up". The track record of languages that never cleaned up isn't... great. You could consider things like RPG, Cobol, Fortran, etc. "alive" because they're still used. But in any other sense of the word they aren't.

_______________________________________________
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
But no other environment have a goal to be backward compatible forever

JavaScript is often referred to as the "assembly language of the web". Did any instruction ever get removed from the x86 instruction set? Will this ever happen?

Also, modern C compilers still compile C code written in the 70s, even if they use obsolete syntax (pre-ansi K&R parameter declarations). Did features get removed from C? (I don't know the answer - anyone ever used trigraphs?). Is this a problem for C programmers?

There is an issue of scale here. You can impose an upgrade behind a corporate firewall; much harder in the open.

Bruno

_______________________________________________
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

Florian Bösch
On Wed, Jul 26, 2017 at 9:47 PM, Bruno Jouhier <[hidden email]> wrote:
JavaScript is often referred to as the "assembly language of the web". Did any instruction ever get removed from the x86 instruction set? Will this ever happen?

There are some features of x86 which where ditched. The more well known example would be MMX (though the idea lives on in SSE/SIMD). But then there's also ARM and its slow crawl to replace x86, mainly in areas x86 didn't have much luck in capturing (mobile), but which now is increasingly making its way into nettops, and undoubdedly will eventually start to tackle high-end personal computing. In other areas (such as GPUs), vendors frequently toss support for features deemed obsolete (though many of them remain support in drivers software paths, just don't use those features cause the speed sucks).

_______________________________________________
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
There are some features of x86 which where ditched. The more well known example would be MMX (though the idea lives on in SSE/SIMD). But then there's also ARM and its slow crawl to replace x86 ...

MMX was not in the original set and looks more like an abandoned experiment (a bit like ES-4). But you are right, some obscure instructions got dropped (like ES dropping arguments.caller). ARM would be more like Dart (with a brighter future). Even if the analogy is not perfect, scale is the key factor in these phenomena.


_______________________________________________
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
In reply to this post by Florian Bösch
On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch <[hidden email]> wrote:
On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <[hidden email]> wrote:
keeping it alive and healthy beyond its browser-limited existence.

Many languages (including Python and Perl)  concluded that at some point things have to be "cleaned up".

You have not addressed my points about the difficulty of removing things on the Web. Citing Perl and Python implies you want opt-in versioning, which I had proposed for ES4 back in the day. before I wised up ;-). A couple of points:

1. Perl 5 vs. 6 and Python 2 vs. 3 are not great precedents. I think they are counterexamples even given the ability with Unix command line tools to be installed and used on single systems or in cloud settings without the huge coordination problem posed by the Web. Perl and Python have forked, and split their communities between versions. The Python rift may heal, but these forks have real and high costs. I know, we use Python at Brave in our build system.

2. Opt-in versioning on the Web is an anti-pattern, as discussed at length on es-discuss. The better way, dubbed 1JS, is to let old forms fall into disuse while carefully extending the language with new syntax and semantics that compose well with the existing surface language, using a kernel semantics approach. This is still TC39's settled conviction as best foot forward.

The track record of languages that never cleaned up isn't... great. You could consider things like RPG, Cobol, Fortran, etc. "alive" because they're still used. But in any other sense of the word they aren't.

Those languages forked and some modernized (I remember Fortran 77). Those are all quite a bit older than JS. I would also suggest they are for the most part stunning successes. We've learned a lot from them.

But the point of order here is whether JS can even be forked as Perl and Python have been. Another point to discuss is what you mean by "isn't... great." Aesthetics aside, keeping compatibility maximizes utility. There is risk of "painting into a corner", making conflicts in the kernel semantics or surface language over time, or just making a kitchen sink language. These are not _malum in se_ but costs to be traded off for benefits.

If the aesthetic or Platonic ideal approach prevails, almost any successful language is not "alive" because it is messy. But that's false: C is still alive, C++ is quite alive, etc. I suggest being precise about costs vs. benefits and avoiding vague or counterfactual metaphorical judgments ("isn't... great", not "alive").

/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

Florian Bösch
On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich <[hidden email]> wrote:
Those languages forked and some modernized (I remember Fortran 77). Those are all quite a bit older than JS. I would also suggest they are for the most part stunning successes. We've learned a lot from them.

Yes, but we'll also want people to *want* to use a language. Not just use it because eons ago something has been written in them and now there is no way out. JS has to keep pace or it will end up like those languages, some relic from the past that nobody uses if they can possibly avoid it. I don't think the mission brief of JS can be "The best language you hate using but can't avoid using anyway."

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

On Wed, Jul 26, 2017 at 3:06 PM Florian Bösch <[hidden email]> wrote:
On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich <[hidden email]> wrote:
Those languages forked and some modernized (I remember Fortran 77). Those are all quite a bit older than JS. I would also suggest they are for the most part stunning successes. We've learned a lot from them.

Yes, but we'll also want people to *want* to use a language. Not just use it because eons ago something has been written in them and now there is no way out. JS has to keep pace or it will end up like those languages, some relic from the past that nobody uses if they can possibly avoid it. I don't think the mission brief of JS can be "The best language you hate using but can't avoid using anyway."

_______________________________________________
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 Michał Wadas
On Wed, Jul 26, 2017 at 11:59 AM Michał Wadas <[hidden email]> wrote:
I know that's hard to remove features from the web. That's why I propose clear and well defined route to clean up language.

Instead of asserting in bold, why not answer the questions I posed in reply to your clear but incomplete proposal?

Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share?
 
Browsers already "broke" the web many times. Java Applets are dead. ActiveX is dead (though some government websites still require it). Flash will be dead in few years. And some sites stopped working because of this. 

You are citing proprietary plugins. The Web of which JS is a part is defined by open standards from Ecma, WHATWG, W3C, IETF. We survived plugins dying (and good riddance, in general; credit to Flash for filling gaps and still doing things the standard Web cannot do well -- this is to the shame of the Web, no argument).

Ok, so proprietary or not, plugins died and that has costs. But they are borne by sites who dropped those plugins, one by one. They are not imposed (at least not till Brave, or now with the plan to kill Flash by 2020 among Adobe and the big four browsers) from the client side. Again, the browser-market game theory does not work. Please respond to this clear and well-defined point :-P.

/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

Florian Bösch
In reply to this post by Brendan Eich-6
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.

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