I'd recommend reading through this awesome document from the Blink team that describes how they don't take breaking changes lightly, and gives tons of examples of breaking changes that have been made before.
Have you read through this document? Has anyone at Google read through this document?
I have.
First, and foremost, "gives tons of examples of breaking changes that have been made before." is not an excuse to have more and more breaking changes. Moreover, there are great examples that show exactly why breaking changes have to be handled with care.
So let's look into that document, shall we?
As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial... So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!
0.006% of page loads using alert()
0.003% of page loads using confirm()
So. "Small but not trivial" and significantly heavier than "even 0.0001%"
Immediately after that we have:
Relevant example cases:
...
Remove SVGPathSeg interfaces
Usage was around 0.001% but generated quite a lot of complaints (and hasn’t been removed in other browsers).
So, no. 0.001% doesn't mean you can just remove it.
Let's skip ahead to an example directly relevant to this issue:
Minimizing web developer impact
Ease of adaptation
Relevant example cases:
Remove showModalDialog Usage reported at <0.006% of PageViews but there was no great work-around (especially for sites depending on the blocking nature) and ultimately caused a LOT of user and developer pain, particularly within enterprises (exacerbated by the lack of visibility into enterprise use cases).
Look. The exact same issue as with alert.
Do you know what one of the suggestions for that was? "To announce these changes at least 6 months beforehand, and to provide developers with a clear upgrade path, alternatives, workarounds and polyfills".
Where's all that?
Oh, look. Some of it is right there in the document:
Outreach
We have more tolerance for riskier breaking changes when some outreach has been done for impacted sites / libraries. For example, if a blog post has been published which shows up as one of the first few search results when searching for the console error message generated as a result of the break. Ultimately we want to minimize the cost to web developers of understanding and dealing with breaking changes.
Have they done any of that? Of course not.
And here's the best quote of all:
It’s important for browser engineers to resist the temptation to treat breaking changes in a paternalistic fashion. It’s common to think we know better than web developers, only to find out that we were wrong and didn’t know as much about the real world as we thought we did. Providing at least a temporary developer opt-out is an act of humility and respect for developers which acknowledges that we’ll only succeed in really improving the web for users long-term via healthy collaborations between browser engineers and web developers.
Instead, we've seen high-visibility Chrome people be consistently dismissive, condescending, ignorant and so on.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions. As developers we can easily implement the required functionality ourselves, ensuring our own application flow.
Let's put this into things/perspective users and developers can/should understand. (Noting; It actually currently only entails cross-origin iframe usage and a possible future complete removal from the spec).
As a user I do not want 3rd party scripts possibly pretending they are the site I am visiting; i.e. alert/confirm with clicks to some nefarious site => cross-origin-removal (what it is all about)
As a user I do not want a site/app possibly pretending they are the browser/os; i.e. alert/confirm with clicks to some nefarious site => complete-removal (what it will become)
As a developer I do not want to rely on "a" browser for my application flow. => complete-removal (what it will become)
I wholeheartedly agree with @samwight comments. The argument against his comments are mostly making elephants from ants (or is that ... from ...).
As developers we should not accept that "old" is better, above "safer" is better. We live in a world wherein we know that the web is abused. As true developers we should all be behind this proposed change (spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts).
Are there really any real world examples of the usage? No; only tutorials. Tutorials are what they are; mostly always need to change to be applicable; given the weather. This is the weather.
p.s.
A lot of people are stating nuclear silos confirm etc. The only real world apps which use these functions are already probably running on isolated browsers that are fixed (i.e. app built for IE 5.5). These apps are not nuclear silo apps; those run with VBasic ;-) Apart from tutorials there are no real world examples that merit the usage of these methods.
p.p.s. I wrote this fast on a mobile so I apologize for typ0s etc
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions.
The article clearly stated the reasons. You decided to dismiss them out of hand
As developers we can easily implement the required functionality ourselves
That's the thing though: you can't easily implement this functionality. Saying that you can easily implement this functionality betrays the fact that you know very little of what goes into implementing into a proper accessible dialog.
On top of that the "replacement" that browsers have (<dialog>) is so bad that Chrome devs themselves argued for its removal. But you'd know that if you read the article.
As a user I do not want...
So instead of solving these issues browser implementors decided to remove a feature without providing a proper replacement.
spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts
And you know this how? From numbers that Chrome provided from public usage data that they themselves admitted was incomplete and incorrect?
Apart from tutorials there are no real world examples that merit the usage of these methods.
The article that you didn't read provides real world usage examples.
But its also telling how you dismiss tutorial sites out of hand because in your mind they are entirely unimportant. What else is unimportant to you?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Have you read through this document? Has anyone at Google read through this document?
I have.
First, and foremost, "gives tons of examples of breaking changes that have been made before." is not an excuse to have more and more breaking changes. Moreover, there are great examples that show exactly why breaking changes have to be handled with care.
So let's look into that document, shall we?
According to your own breakdown:
This would affect:
0.006% of page loads using alert()
0.003% of page loads using confirm()
So. "Small but not trivial" and significantly heavier than "even 0.0001%"
Immediately after that we have:
So, no. 0.001% doesn't mean you can just remove it.
Let's skip ahead to an example directly relevant to this issue:
Look. The exact same issue as with alert.
Do you know what one of the suggestions for that was? "To announce these changes at least 6 months beforehand, and to provide developers with a clear upgrade path, alternatives, workarounds and polyfills".
Where's all that?
Oh, look. Some of it is right there in the document:
Have they done any of that? Of course not.
And here's the best quote of all:
Instead, we've seen high-visibility Chrome people be consistently dismissive, condescending, ignorant and so on.
Oh. And don't forget: they are removing this functionality, and there's literally nothing in the pipeline to replace it.
As a developer there is never a reason to use these antiquated (nonsensical and legacy) application flow functions. As developers we can easily implement the required functionality ourselves, ensuring our own application flow.
Let's put this into things/perspective users and developers can/should understand. (Noting; It actually currently only entails cross-origin iframe usage and a possible future complete removal from the spec).
As a user I do not want 3rd party scripts possibly pretending they are the site I am visiting; i.e. alert/confirm with clicks to some nefarious site => cross-origin-removal (what it is all about)
As a user I do not want a site/app possibly pretending they are the browser/os; i.e. alert/confirm with clicks to some nefarious site => complete-removal (what it will become)
As a developer I do not want to rely on "a" browser for my application flow. => complete-removal (what it will become)
I wholeheartedly agree with @samwight comments. The argument against his comments are mostly making elephants from ants (or is that ... from ...).
As developers we should not accept that "old" is better, above "safer" is better. We live in a world wherein we know that the web is abused. As true developers we should all be behind this proposed change (spec from day1/not break the web arguments are superfluous as the current real world usage is mostly only nefarious cross origin scripts).
Are there really any real world examples of the usage? No; only tutorials. Tutorials are what they are; mostly always need to change to be applicable; given the weather. This is the weather.
p.s.
A lot of people are stating nuclear silos confirm etc. The only real world apps which use these functions are already probably running on isolated browsers that are fixed (i.e. app built for IE 5.5). These apps are not nuclear silo apps; those run with VBasic ;-) Apart from tutorials there are no real world examples that merit the usage of these methods.
p.p.s. I wrote this fast on a mobile so I apologize for typ0s etc
The article clearly stated the reasons. You decided to dismiss them out of hand
That's the thing though: you can't easily implement this functionality. Saying that you can easily implement this functionality betrays the fact that you know very little of what goes into implementing into a proper accessible dialog.
On top of that the "replacement" that browsers have (
<dialog>) is so bad that Chrome devs themselves argued for its removal. But you'd know that if you read the article.So instead of solving these issues browser implementors decided to remove a feature without providing a proper replacement.
And you know this how? From numbers that Chrome provided from public usage data that they themselves admitted was incomplete and incorrect?
The article that you didn't read provides real world usage examples.
But its also telling how you dismiss tutorial sites out of hand because in your mind they are entirely unimportant. What else is unimportant to you?