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
<mailto: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
<mailto:pya...@gmail.com>> wrote:
>> On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich
<brendan.e...@gmail.com <mailto: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 <mailto: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 <http://www.actifsource.com> •
+41 56 250 40 02
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto: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
