Live data from Hacker News

Chrome breaks the Web

tonsky.me

31–40 of 473 posts

Re: Chrome breaks the Web

#31

> Google wasn’t concerned about your websites at all. It was more concerned about its own product performance Why I'm not surprised?

No, Google were concerned about your websites. Your mobile websites which are so heavily overloaded with JS that basic interactions like scrolling don’t work. Complaining that Google “broke the web”, when mobile developers have been making it slowly unusable—and unused—for years is pretty hypocritical. All the feature detection and backwards compatible changes in the world won’t help developers when their entire user…

So this is a good thing because the gatekeeper is Google instead of Facebook?

How's about adhering to standards? We gave Microsoft a hell of a time for not adhering to standards, but Google gets a free pass now? Because "performance"? (read: some negligible gains on some synthetic benchmarks)

Then let's stop pretending: let's scrap the W3C and go back to the good old days of "Best viewed on Netscape Navigator at 800x600".

Re: Chrome breaks the Web

#32
Dear developer,

I hate you[1] when you interfere with scrolling. Yes, some people do it right and so on. You are not one of them. Please. Stop.

Yours,

A user that will close your website when scrolling is messed with.

---

[1] not OP, but the average developer, which, under time pressure and without many resources, cannot test all desktop/phone and browser combinations. Assuming they even care.

Re: Chrome breaks the Web

#33
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

Isn't this a reaction to moronic use of autocomplete=off in a user-hostile way by various websites? In a similar vein to how abuses of disabling the back button, popups etc have led to defensive measures by browser vendors.

Re: Chrome breaks the Web

#34
post #3

There’s a good point here but the clickbait trappings are holding it back, especially since passive listeners aren’t some obscure edge case which only Google needs.

I think the point of it was that they made every event listener passive by default, rather than making it an option.

My point was simply that while there's a good technical discussion to be had here, the doom and gloom styling hurts it. There is a reasonable point about backwards compatibility, the conflicts between Google owning Chrome and also making web properties which compete with other companies, etc. but there's a lot of hyperbole like this:

“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.”

None of those claims are supported. If Mobile Chrome broke half of the sites on the web, we'd have heard a lot more outrage over the last six months, and the very strong language fails to consider all of the broken code which was making the web experience worse for almost everyone.

Again, I'm not saying that that the technical discussion isn't useful but that “breaks the web” seems unnecessarily hyperbolic. The fact that the React team is struggling with a simple JS/CSS change seems to say a lot more about the support cost of building huge JS frameworks which duplicate core browser functionality than whether the Chrome team should make decisions to help mobile performance.

Re: Chrome breaks the Web

#35
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

The problem is that some sites decided to use autocomplete=off to impose their feeling about password managers on users and make them more difficult to use. It's the same reason I have to turn off clipboard events because some sites think it's okay to block copy/paste.

Re: Chrome breaks the Web

#36
post #32

Dear developer, I hate you[1] when you interfere with scrolling. Yes, some people do it right and so on. You are not one of them. Please. Stop. Yours, A user that will close your website when scrolling is messed with. --- [1] not OP, but the average developer, which, under time pressure and without many resources, cannot test all desktop/phone and browser combinations. Assuming they even care.

> Yes, some people do it right

Who? Any examples?

Re: Chrome breaks the Web

#37
A lot of fair points in here.

I think what it comes down to is backward compatibility for the web. There are SO MANY websites relying on old behavior that introducing new behavior is going to break some sites that don't KNOW about your shiny new shit.

IE used to have this kind of thing too, anyone here remember "Quirks Mode" and so on?

What web browsers sorely need is a backward compatibility standard that they can STICK TO. Such as feature detection as a first-class API to be tried first. Perhaps this way any new features can be detected across browsers. Like, they would actually have to coordinate to name EACH new change the same in EACH new browser.

But this is what you get when you have multiple browser makers. Some just won't coordinate with the others and you need another layer - a library - to abstract away the differences.

Which is why it would be super-useful for browsers to add content-addressable protocols (read: not just http) to fetch files from any website in a DHT. So these libraries can be loaded ONCE and become cheap to use!

Does anyone know any mainstream browserd planning to implement, I dunno, IPFS? The only one I've heard of doing this is Blockstack and dude, how much adoption does that have exactly?

Last question -- can there be a browser extension that can intercept http requests by their Subresource Integrity checks, and load them on demand as if they were content addressed? Maybe use service workers in Chrome? Is that possible? I would be willing to partner with someone here to write such a thing.

Re: Chrome breaks the Web

#38
post #9

> they made all top-level event listeners passive by default. They call it “an intervention”. This is my very problem with Chrome/Chromium right now. The Chrome team does assumption on how things "should" be (in a highly subjective way) and breaks the web. Another example: they decided to ignore the value of `autocomplete` attributes on ` ` tags [1], because: > The tricky part here is that somewhere along the journey…

Personally I have found I was more annoyed with forms not allowing me to autofill before the change than times I have seem chrome fill the wrong fields out after.

Re: Chrome breaks the Web

#39

I side with Google on this one. IMO we should be breaking JavaScript more often, especially in the name of performance, to make people use less JS and simpler JS on their websites.

There are no more websites. There are applications, delivered on applications platforms, using css, html, and js as programming languages. Chrome is the application platform, and Google is the company shipping it. Like all application platforms, the interests of company who designs it always come first.

Let us return to a moment to the WWW's ripe vintage of 1995, when Netscape Communications Corporation released a browser which had 3/4 of the browser market share within a year of release. Their product was advertised as a consistent universal interface to the web. They created custom features for their product, such as SSL, and JavaScript. But many of the features were released to outdo its main competitor, Microsoft, who could dedicate far more resources to development (they had so much cash they didn't even need to charge for the browser!).

Netscape Communicator attempted to be a groupware solution combining multiple products to provide a complete solution for office and enterprise needs. But the design was too monolithic and complicated, and development was eventually halted. Ever since then, many organizations have attempted to build complete groupware solutions, but have been weighed down by the difficulty of developing such a complex suite of applications.

And so came the future. As the web's technologies progressed, so did the capability of content delivered through a "standard" web browser. Even though browsers have traded back and forth over who supports what, most of the time the browser with the majority market share holds all the cards. As long as that browser works the same on multiple platforms, they don't need to worry about cross-browser compatibility, because that isn't their goal. Netscape's original goal was to kill Mosaic, and they did that in spades.

Today, Google provides a mostly-complete groupware solution, delivered on its favorite application platform: its own web browser. The costs of developing and shipping the software to end users are much lower than traditional native apps, and they increasingly control more and more of the pipeline, even to the actual computer (Chromebooks are designed to cement Google's ownership of computing resources, freeing them from the constraints of other vendors' platforms).

They not only don't want you to have "less JS and simpler JS on a website", they don't want you to run a website. They want you to provide an application which runs on their application platform. In service of that goal, they have developed dozens of web technologies designed to further their own application platform, just like the Netscape of old. If they have to break compatibility with other browsers to do it, that's fine with them.

The bizarre thing is breaking existing websites on their own browser. If you can't browse the web reliably you'll stop using their browser, and then their app platform and apps are in danger of becoming obsolete.

Re: Chrome breaks the Web

#40
post #15

Can't they just add another argument for the options map without breaking backwards compatibility? That's ugly as hell too, but in a way that preserves backwards compatibility. My feeling is that so many compromises have been made to maintain compatibility in JS/DOM-land that it seems capricious to make this kind of decision now.

> Can't they just add another argument for the options map without breaking backwards compatibility?

The options map is a recent addition in the first place, and they want passive listeners by default. They originally made passive opt-in, then decided that they wanted it set.

Post reply on HN