Yes but not all breaking changes are equal. The church down your street was extremely unlikely to even be impacted by this change let alone have functionality broken by it.
This only affected websites which were using blocking scrolling event listeners. Scrolljacking, some mapping websites where you were able to tap and pan around, and some sticky headers, and only on mobile devices using chrome.
And of those features impacted, most weren't even "broken", they were simply delayed until after the user lets their finger off the screen. A "sticky" header will still work with this change, it will just "snap" into place after scrolling. Scrolljacking content will act in a similar manner.
I'm completely against breaking the web wherever possible, but in this case I really believe it to be worth it. Smooth scrolling makes sites usable, janky jumpy websites on mobile are so infuriating, and on lower spec devices can be completely unusable. This makes them usable again, it wasn't just "breaking the web" it was "fixing the web" for many people.
In my mind I see this like I see popup blockers or even adblockers built into the browser. Yes, they break functionality, but they do so for the user, and if the website needs to get around this change, they can easily do so without the user having to do anything (unlike popup and adblockers in most cases).
> The church down your street was extremely unlikely to even be impacted by this change
Why do you say that? Let's say, for example, that they use Discourse [1] to provide a web forum for churchgoers on their website. Oops! Mobile scrolling is completely broken for them [2] until they manage to update Discourse to the latest version. Is this the flu shot you were talking about?
No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken.
And while they would need to update, if they were using the hosted discourse plan it would have been fixed for them, and if they were using the self-hosted plan, they are running that on a linux server which needs updates and maintenance periodically anyway or a broken timeline will be the least of their problems. Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI.
So yes, this is exactly the flu shot I'm talking about. A product was broken in a fairly minor way with this update, and a fix was developed within 24 hours which consisted of 2 lines of CSS (both the same, but in 2 different spots). And now the product and the web as a whole (on chrome) are less laggy and janky on mobile devices.
> No, mobile scrolling wasn't "broken" for them, scrolling via their "timeline" feature was broken.
So, mobile scrolling is broken, but not all the time. Is that really the distinction you want to make right now? For the individual who said "[c]omplaints from my users are starting to come in", is that an adequate response?
> Luckily Discourse will email you when there is an update with a link to the admin page that lets you one-click upgrde the Discourse install on your server from the web UI.
Please do tell that to the parishioner whose son set up the website a year ago before he left to go to college. We all agree that software upgrades are important for security, but that doesn't justify imposing an additional artificial upgrade burden due to a backwards-incompatible breakage to the web.
The timeline feature is the sidebar that shows you where in time since the first post you are looking at. When you drag along it, it can move you to that date and time. It's a cool features but not integral to the application.
Scrolling still worked... 100% of the time on 100% of devices.
And as for the upgrade, if the parishioner can't click [0] in the web UI (a link to which was emailed to them), then I'm not sure how they are using discourse at all. And IMO they have no business hosting anything themselves as it will most likely turn into a DDoS bot within a year.
But again, there is no need to do this as the forum software worked completely fine for it's core functionality and only scrolling via the timeline was broken.
You're showing a pretty serious case of cognitive dissonance here. What previously was a theoretical problem was actualized with a real world example with actual affected users, and you've shifted to an entirely subjective argument that the breakage is "not integral to the application".
You also chose to rationalize the breakage by shifting the blame to the victim -- they have "no business hosting anything themselves". Well, great, but that isn't going to stop them. Maybe they want to ensure their web forum isn't censored by a hosting provider. It turns out that people still host their own websites in 2017, and until they all shift to centralized monolithic providers these bugs will persist for years, and you will persist in rationalizing the breakages as "flu shots".
Reread my first comment. I pointed out that the breakage would be limited in scope. Very very few applications were broken by this (broken being defined as having it's core functionality unusable).
And you seem to be completely ignoring the fact that the upgrade "path" is one click of a button. Whether you agree with my stance on the responsibility of hosting your own internet connected server or not, it's a one click button upgrade, to a fix which was made 24 hours after the problem appeared.
If your problem is a minor UI breakage of a side feature of a well maintained web application that doesn't get updated because the admin doesn't know how to click a button in response to a fix which significantly improved scrolling performance for all chrome users, how do you justify any changes at all? Call it rationalizing if you want, I'm saying it's worth the extremely small amount of pain for the bettering of all chrome users.
How can you change anything at all if that is your threshold for unacceptable? How can you even update a single line of code if you feel that such a small amount of breakage is not allowed?
Against my better judgement I did a reverse image search and found the post that you found that screenshot from [1]. The post is full of people having exactly the sort of problems you would expect from an automatic software updater, along with instructions from Jeff on how to manually update using SSH and git.
These things happen. The world is messy, and whether due to technical inadequacy or run-of-the-mill software updater bugs, web backends will not always be updated. As you've noted, this could eventually lead to security problems, and I agree -- but that doesn't justify intentionally breaking their code. To say that their breakage is justifiable because they'll be 0wned at some point anyway is an absurdly darwinian argument.
To address your last question, the way you update a system like the web is exactly the way we always have -- accretion. With very few exceptions, websites from the early 90s still work today. We didn't remove the `table` tag when we introduced flex boxes. We add new APIs while preserving existing functionality. If you want to see a fantastic talk on this exact subject, watch "Stewardship: The Sobering Parts" by Brian Goetz [2]. It is well worth your time.
And I agree that we shouldn't break things lightly, but in this case that wasn't possible.
The options were let website scrolling be laggy and janky on mobile, or break a very small amount of websites. (and your point is that things may never be updated, so no amount of "giving them the ability to opt-in to these improvements would ever help)
And I stand by my thought that they made the right decision here, despite the very few easily upgraded sites that were impacted.
This only affected websites which were using blocking scrolling event listeners. Scrolljacking, some mapping websites where you were able to tap and pan around, and some sticky headers, and only on mobile devices using chrome.
And of those features impacted, most weren't even "broken", they were simply delayed until after the user lets their finger off the screen. A "sticky" header will still work with this change, it will just "snap" into place after scrolling. Scrolljacking content will act in a similar manner.
I'm completely against breaking the web wherever possible, but in this case I really believe it to be worth it. Smooth scrolling makes sites usable, janky jumpy websites on mobile are so infuriating, and on lower spec devices can be completely unusable. This makes them usable again, it wasn't just "breaking the web" it was "fixing the web" for many people.
In my mind I see this like I see popup blockers or even adblockers built into the browser. Yes, they break functionality, but they do so for the user, and if the website needs to get around this change, they can easily do so without the user having to do anything (unlike popup and adblockers in most cases).