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 <michael.krie...@actifsource.com> 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 deprecation-warn...@whatever.ch > 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 < > michael.krie...@actifsource.com> 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 <pya...@gmail.com> >> wrote: >> >> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich <brendan.e...@gmail.com >> > >> >> 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 >> > es-discuss@mozilla.org >> > 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 >> es-discuss@mozilla.org >> 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
