Slashdot Mirror


'How Chrome Broke the Web' (tonsky.me)

Reader Tablizer writes (edited and condensed): The Chrome team "broke the web" to make Chrome perform better, according to Nikita Prokopov, a software engineer. So the story goes like this: there's a widely-used piece of DOM API called "addEventListener." Almost every web site or web app that does anything dynamic with JS probably depends on this method in some way. In 2016, Google came along and decided that this API was not extensible enough. But that's not the end of the story. Chrome team proposed the API change to add passive option because it allowed them to speed up scrolling on mobile websites. The gist of it: if you mark onscroll/ontouch event listener as passive, Mobile Google can scroll your page faster (let's not go into details, but that's how things are). Old websites continue to work (slow, as before), and new websites have an option to be made faster at the cost of an additional feature check and one more option. It's a win-win, right? Turned out, Google wasn't concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile. That's why on February 1, 2017, they made all top-level event listeners passive by default. They call it "an intervention." Now, this is a terrible thing to do. It's very, very, very bad. Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization. This was not backward compatible change by any means. All websites and web apps that did any sort of draggable UI (sliders, maps, reorderable lists, even slide-in panels) were affected and essentially broken by this change.

37 of 283 comments (clear)

  1. onScroll not passive? by Luthair · · Score: 4, Insightful

    Maybe you should fuck off with your website that modifies scrolling.

    1. Re:onScroll not passive? by tepples · · Score: 5, Insightful

      The featured article claims that "All websites and web apps that did any sort of draggable UI (sliders, maps, reorderable lists, even slide-in panels)". In such web applications, if the user is performing a slide gesture, he doesn't necessarily want to make the whole document scroll just because the gesture has approached the edge of the document.

      So let me get this straight: Are you claiming that such web applications "should fuck off"? Must they instead be rewritten as native executable applications that work only on one brand of operating system?

    2. Re:onScroll not passive? by AmiMoJo · · Score: 2

      Maybe web sites should not be trying to behave like apps. Especially if doing so kills browser performance and battery life on mobile.

      Can you give an example of a web site where this behaviour is actually desirable?

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:onScroll not passive? by tepples · · Score: 2, Informative

      Maybe web sites should not be trying to behave like apps.

      Have you considered that a website might be trying to behave like an app in order to circumvent the costs and censorship aspects of being in Apple's App Store?

    4. Re:onScroll not passive? by AmiMoJo · · Score: 2

      Missing the point, I don't want apps wasting my battery on pointless crap either. A nice, usability focused UI will be fine, thanks.

      I guess maybe there are some unusual applications that would benefit from your use case, but I really can't think of any app that was censored/driven out by price and would benefit from having that kind of interactivity via a web version.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:onScroll not passive? by BronsCon · · Score: 2

      What's more usable:
      - A UI where, in order to move items in a list, you must click an up/down arrow and wait for the page to reload with the moved item in its new position
      or
      - A UI that lets you reorder a list by dragging the items where you want them?

      Unlike most people (I've done market research on this very topic), you must not think the second option is more usable, because that's what Google broke.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  2. Who wrote this? Donald Trump? by Bohnanza · · Score: 5, Funny

    "Now, this is a terrible thing to do. It's very, very, very bad, believe me, folks"

    --

    -----

    Sorry, I'm only a 1336 h4x0r.

    1. Re:Who wrote this? Donald Trump? by Tablizer · · Score: 2

      Do you mean the summary, or actual article? The summary I submitted in the story submission form was different from the Slashdot-published version. As the first line points out, it has been edited. Actually, my summary was shorter than the published version. For one, it didn't include the "very, very, very bad" line because I felt other wording already indicated Google's change made a bigly mess.

      - Tablizer

  3. Absolute power corrupts absolutely by Anonymous Coward · · Score: 5, Interesting

    The mantra of the Chrome team was once "Don't break the web".

    This hasn't been true for some time now. Why? Because power.

    Take (for example) Google's newfound habit of "updating" their webfonts. How many layouts have they broken in the process? Millions.

    Google needs to rediscover the value of accepted standards. But there seems to be a new management team calling the shots.

    And they're mostly d*cks.

    1. Re:Absolute power corrupts absolutely by shortscruffydave · · Score: 2

      The mantra of the Chrome team was once "Don't break the web".

      Their parent's mantra used to be "Don't be evil".

      Can you see a pattern beginning to emerge here?

    2. Re:Absolute power corrupts absolutely by thegarbz · · Score: 2

      Take (for example) Google's newfound habit of "updating" their webfonts. How many layouts have they broken in the process? Millions.

      If your website breaks because the font changes then it's not Google who deserves to be tared and feathered, but the web designer.

  4. The Chrome team "broke the web"... by Anonymous Coward · · Score: 2, Insightful

    if you use Chrome.

    As I'm firmly in the 'fuck Google and all of their products' camp, I hadn't noticed.

  5. Didn't they just break their own product? by myowntrueself · · Score: 5, Insightful

    It doesn't sound like they broke the web; surely other browsers carried on working just fine? They broke their own product.

    --
    In the free world the media isn't government run; the government is media run.
    1. Re:Didn't they just break their own product? by TuringTest · · Score: 5, Insightful

      Except that users will perceive it as "this old website doesn't work", not "Chrome doesn't work", since the problems only happens in some websites and not others.

      --
      Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
    2. Re:Didn't they just break their own product? by Anonymous Coward · · Score: 5, Insightful

      It's like a smudge on the screen, except users would probably figure out that not all web sites started having smudges in a fixed position.

      During your first week of working in this industry, you will quickly learn one thing: never, ever depend on users to figure out anything.

      You can only count on users to find the most ingenious ways to break things. You can't count on them to figure out new things. In fact most of them really hate learning. They will go to such extraordinary lengths to avoid learning, that actually learning would have been far less effort.

      If you've ever worked in an office setting, you will have seen tons of users who have used the same systems for years. Yet they know nothing more about how things work than when they started. They managed to avoid even accidentally picking up bits of new info along the way. Now that takes real work. If a later version changes the location of a menu item or icon, the company has to invest in "retraining".

      That's what "users" are like.

    3. Re:Didn't they just break their own product? by Quirkz · · Score: 2

      Man, I'd thought "the internet won't start" browser confusion problems had died with the last millennium. Guess some things never change.

  6. So, you're saying... by TuringTest · · Score: 3, Interesting

    ...developers should provide their own initial value for every parameter defined in the standard, and those non-standard parameters available in any popular implementation?

    --
    Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
    1. Re:So, you're saying... by thegreatbob · · Score: 3, Insightful

      When too much changes too quickly, as is pretty clearly the case here, cromulence diminishes rather rapidly. Making up new words is fine, provided they have a definition based in what is already understood (perhaps even understandable?). However, if I (or whatever entity) begin to unilaterally redefine words and other parts of speech, problems start to arise, and mutual intelligibility is lost.

      --
      There is no XUL, only WebExtensions...
  7. Re:Never rely on defaults... by Anonymous Coward · · Score: 5, Insightful

    This wasn't a default, it was a standard. Google was the one that decided to add a passive option in the first place, and when they defaulted it to true, they violated the standard. Sites that were broken by this change were doing everything right when they were written; their only mistake was not religiously re-checking their site against every new Chrome Canary build to make sure their standards-compliant site hadn't been broken.

  8. Chrome is the new IE by 93+Escort+Wagon · · Score: 5, Informative

    Dominant market position - check.

    Starting to define its own browser-specific functionality - check.

    Telling developers they should use their company's browser-specific functions to improve performance - check.

    Meet the new boss, same as the old boss. Anyone who didn't see this coming the moment Google forked Webkit simply wasn't paying attention.

    --
    #DeleteChrome
  9. Re:Microsoft Redux by bogaboga · · Score: 2

    Isn't it funny how the bigger companies seem to just "know better" than the rest of the Internet engineers?

    It would perhaps be better if you internalize the fact that the criticism of having "broke the web" is a one person opinion.

    Others would probably disagree.

  10. Re:Get with the picture! by redmasq · · Score: 2

    It is doubly Slashdot's fault, not only have they not fixed the issue, but tags are not whitelisted and get filtered out.

  11. Re:Never rely on defaults... by Anonymous Coward · · Score: 5, Insightful

    Years ago, websites were designed so that they rendered properly with Internet Explorer. Microsoft didn't have to follow any standards because they had the most widely used browser and Fuck You if you don't use IE.

    Now Chrome is the most widely used browser and Google has decided to become the new Microsoft.

  12. TL;DR: Tard Tears From Web "Devs" by NicknameUnavailable · · Score: 2, Interesting

    The web isn't a development platform, it's a more advanced version of Hypercard. It sucks, it changes to account for the constant sucking, and web "developers" want to make something amazing and be done with it, but you can't make something amazing in Hypercard 2.0, you can just make some presentation. The web isn't designed as an application layer, it's designed as a presentation layer. Stop making apps in the web, they are slower and generally garbage.

  13. Re:Never rely on defaults... by Jerry · · Score: 4, Insightful

    Exactly.
    Google is just adopting Microsoft's "Embrace, Extend, Extinguish" tactic against its opposition because it has the market share to do it.

    That, and Google's attack on free speech, are the reasons why I canceled my Google account.

    --

    Running with Linux for over 20 years!

  14. How bad is it really? by 140Mandak262Jamuna · · Score: 5, Insightful
    The summary says:

    It's very, very, very bad

    It explains:

    Basically, Chrome broke half of user websites, the ones that were relying on touch/scroll events being cancellable, at the benefit of winning some performance for websites that were not yet aware of this optional optimization

    OK, half the user websites? 50% of the web right? The linked article says:

    We looked at the percentage of cancelable touch events that were sent to a root target (window, document, or body) and determined that about 80% of these listeners are conceptually passive but were not registered as such. Given the scale of this problem we noticed a great opportunity to improve scrolling without any developer action by making these events automatically "passive".

    Looks like the chrome team did some basic profiling, figured out 80% of the listeners are actually passive. Still they should not have touched the default and educated the website developers to register conceptually passive listeners as passive, right?

    Google gives some motivation for this:

    We believe the web should be fast by default without developers needing to understand arcane details of browser behavior.

    There are some plots and more profiling data there.

    They could have done an RFC and got the standards updated in the next batch for this. But still, as evil behaviors go, this is not "dos is not done till lotus wont run" level. Does not even come to working around bugs in IIS in IE to make all other browsers crap out level of evil.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:How bad is it really? by LordKronos · · Score: 5, Insightful

      Yeah, I'm finding it a little difficult to get worked up about this. It's been this way for over half a year and I haven't noticed anything broken by it. And honestly I'm having a bit of difficulty imagining how a website could legitimately use this sort of eventListener and not be a prime example of sloppy coding. Yes it might've worked by the standard...I understand that. But really...listening for scroll events at the window, document, or body level? Can someone give me a good example of how this is used and couldn't be done better? Some of the "broken things" examples given in the linked article: Drag an drop list? Your list should be contained in some div or ul element and you should apply the listener at that wrapper level, not listen to ALL scroll events on the ENTIRE document. Sliders? Same. Maps? Same. Yes, it might have worked before by listening to all body events, but really that's just shit design.

      So I feel like a better description would be more like "google broke 50% of the shitty websites, but not the well designed ones". But please, I welcome an example to show me where there are good reasons to do this.

    2. Re:How bad is it really? by LordKronos · · Score: 4, Insightful

      Or perhaps this should be the free square on why you read the post before replying to it. Read my post again. As I mentioned, this particular chrome change ONLY applies for event listeners that are bound to the window, document, or body. It's a pretty general rule that any type of listener should be scoped to only listen to the minimum required amount of events. When you bind to window, document, or body, you are pretty much saying GIVE ME EVERYTHING. So now you get called for every event...even those you couldn't possibly be the slightest bit interested in. Best programming practice is generally to scope your event listeners so that they only get called in cases where you might possibly be interested in handling them.

      Lets look at a simple case....a webpage where the body contains 2 divs (divA and divB). In divA, you want to handle an event and perform some custom handling, possibly even cancel the the event with preventDefault. In divB, you never care about the event, so your event handler is always going to do nothing.

      If you bind your event handler to divA, then whenever that event occurs in divB your event handler will never even be call. That's perfect...you aren't interested so lets not even waste time asking if you want to do anything. But if you bind your event handler to the body/document/window, your event handler is going to be needlessly called so that it can do ABSOLUTELY NOTHING (except waste CPU time) every time the event occurs in divB.

      So that was my point...based on what I've read my gut instinct is to say that this would pretty much only affect web pages where the programmer was too sloppy/lazy to properly scope their event handler to the parts of the DOM where they're actually interested in doing something about that event.

      But of course, I admit that I may certainly be overlooking cases where this isn't the case, and there's absolutely no way to implement it without throwing an event handler on the window/document/body. And that is why I humbly asked for examples where I was wrong and this is the only way to do it. I will note that you provided precisely zero example of such. Maps and reorderable lists can certainly have their event handlers properly scoped instead of just throwing them on the window/document/body

  15. Re:How about you fuck off by Anonymous Coward · · Score: 3, Funny

    How about you fuck off the web, and go install a "native app", and get data-mined.
    It's more than you deserve.

    Yes, they should avoid installing native apps. Instead, they should use a Google-branded browser. That will DEFINITELY avoid data mining!

  16. Re:Get with the picture! by bhcompy · · Score: 4, Insightful

    Don't use Chrome. There, fixed.

  17. All browsers are broken by RogueWarrior65 · · Score: 2

    Can someone explain why I have to restart Firefox at least once a day in order to play back video of any kind?
    And why doesn't Wunderground render properly on Firefox? It seems that everything is a lot slower these days further convincing me that trying to do anything online that used to be done with a dedicated program is a bad idea.

    1. Re:All browsers are broken by fibonacci8 · · Score: 2

      The Russian and American malware you've contracted are incompatible. So are the others, but not such you'd notice.

      --
      Inheritance is the sincerest form of nepotism.
  18. Won't be shuned as Internet Explorer by Trax3001BBS · · Score: 2

    I came from Dos/Amiga to Windows, the very first time I used Internet Explorer I didn't want any part of it.
    Not used to WWW I went to Microsoft.com found a game that looked decent and downloaded it (I thought). ActiveX kicked in and was installing something I hadn't looked at first, so pulled the computer power cord.

    The second time I used IE was to download Netscape.

  19. Multiple browsers by ilsaloving · · Score: 5, Insightful

    It's idiocy like this why I am compelled to have at least 3 different browsers on every machine I use. Because it seems like every time there's some kind of update, stuff get horribly broken and I need to switch to a different browser for an extended period of time. It's to the point where I've purchased an xmarks premium subscription, so that all my bookmarks gets synced and I don't have to jump through hoops when the inevitable switch happens.

    It's so frustrating the way companies think that they are allowed to have defacto control of the entire internet.

    Fuck you Google, and fuck you Microsoft before you.

  20. Embrace, Extend... by hughbar · · Score: 2

    Well, they had good teachers, when they were younger.

    --
    On y va, qui mal y pense!
  21. NWS Mobile by pgn674 · · Score: 2

    Is that why the map on this website doesn't pan reliably on Google Chrome mobile? 7-Day Forecast for Latitude 43.66ÂN and Longitude 70.27ÂW (Elev. 7 ft) I just tried Mozilla Firefox mobile. Works much better in that app.

  22. Wunderground is a terrible mess by jeffb+(2.718) · · Score: 2

    At this point I can count on Wunderground to be broken more than 50% of the time. Differently on different days, at different times of day, and on different clients, but broken most of the time. (Trying to change a display preference? Scroll through times in the 10-day forecast view? Select conditions from a controlled (airport) station instead of a random PWS sitting in someone's backyard next to their dryer vent? "We'll be rolling out an update in a couple of months.")

    But not to worry. They're maintaining a steady pace of innovation, and soon they'll be broken 100% of the time on all clients.