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 <[email protected]> wrote: > On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
