Tom Warren’s “Chrome is turning into the new Internet Explorer 6” for The Verge has a title that, to us front-end web developers, suggests that Chrome is turning into a browser far behind in technology and replete with tricky bugs. Aside from the occasional offhand generic, “Chrome is getting so bad lately,” comments you hear, we know that’s not true. Chrome often leads the pack for good web tech.
Instead, it’s about another equally concerning danger: developers building sites specifically for Chrome. In theory, that’s not really a thing, because if you build a website with web standards (of which there isn’t really much of an alternative) it’ll work in Chrome like any other modern web browser. But it is a thing if you build the site to somehow block other browsers and only allow Chrome. Warren:
Google has been at the center of a lot of “works best with Chrome” messages we’re starting to see appear on the web. Google Meet, Allo, YouTube TV, Google Earth, and YouTube Studio Beta all block Windows 10’s default browser, Microsoft Edge, from accessing them and they all point users to download Chrome instead. Google Meet, Google Earth, and YouTube TV are also not supported on Firefox with messages to download Chrome.
I wouldn’t call it an epidemic but it’s not a good trend. Best I can tell, it’s server-side UA sniffing that entirely blocks the sites:
If anything, I’d think you’d just let people use the site and display a warning if you’re really worried some particular feature might not work. Or even better, fix it. I have no behind-the-scenes knowledge of why they made the choice to block certain browsers, but it’s hard to imagine a technical limitation that would force it. And if it is, I’d suggest letting it be very publicly known to incentivize the other browsers to support what is needed, assuming it’s an established standard.
Even more concerning than browser-specific websites is seeing browsers ship non-standardized features just because they want them, not behind any vendor prefix or flag. There was a time when web developers would have got out the pitchforks if a browser was doing this, but I sense some complacency seeping in.
These days, the vibe is more centered around complaining about other browsers lack of support for things. For example, one browser ships something, we see one green dot in caniuse, and we lambast the other browsers to catch up. Instead, we might ask, was it a good idea to ship that feature yet?
No modern browser is shipping vendor prefixes anymore since we all ultimately decided that was a bad idea. A side effect of that is that shipping a new feature in CSS or JavaScript is all the riskier. I would think shipping an unprefixed feature to a stable version of the browser would mean the feature is standardized and not going to significantly change. Yet, it’s been happening.
In CSS, Chrome shipped motion-* properties, but then that all changed to offset-*, and the old motion-* properties just stopped working. That’s more than just annoying, that kind of thing helps developers justify saying, “I just build this site for Chrome, if you wanna use it, use Chrome.” Fine for a demo, perhaps, but bad for the web industry as a whole. Again, I have no special insight into why this happens, I’m just a developer looking in from the outside.
Here’s another CSS one I just saw the other day. People are excited about text-decoration-skip: ink; because it looks great and helps people. They are using it a lot. But apparently, that’s not the correct name for it? It’s been changed to text-decoration-skip-ink: auto; and so Chrome 64 is canning text-decoration-skip: ink;. This stuff is hard to keep up with even while actively trying.
Chris Krycho had a take on it recently as well:
Over the past few years, I’ve increasingly seen articles with headlines that run something like, “New Feature Coming To the Web” — followed by content which described how Chrome had implemented an experimental new feature. “You’ll be able to use this soon!” has been the promise.
The reality is a bit more complicated. Sometimes, ideas the Chrome team pioneers make their way out to the rest of the browsers and become tools we can all use. Sometimes… they get shelved because none of the other browsers decide to implement them.
Many times, when this latter tack happens, developers grouse about the other browser makers who are “holding the web back.” But there is a fundamental problem in this way of looking at things: Chrome isn’t the standard. The fact that Chrome proposes something, and even the fact that a bunch of developers like it, does not a standard make. Nor does it impose an obligation to other browsers to prioritize it, or even to ship it.
This isn’t all to throw Chrome under the bus. I’m a Chrome fan. I’m sure there are examples from all the major vendors in the same vein. I’d just like my two cents to be careful now. The web is the best platform to build for and generally heading in a direction that makes that even truer. The easiest way to screw that up is not being careful with standards.
Just thinking aloud hear, but I wonder if some of the mentioned problems could be solved by warning about experimental features in the browser console.
That way whenever is devs use an experimental feature, we’d get a heads up to be careful and maybe a link to chromestatus/ mdn/ caniuse documentation.
(This would very much be the opposite of the deprecation warnings that browsers already log to the console)
This feels similar to how Apple only supports Safari for live streaming their events. Or how the Windows OS will give you a popup every few times you launch a third-party browser saying “Hey! Have you tried Edge?” It’s a brand trying to force the general audience of the web to use their specific dedicated browser out of inconvenience. It seems to be motivated purely by greed more than any particular technical spec of the specific browsers peddled.
Watching apple’s live streams also work on microsoft’s edge.
I might be wrong but i think they’re doing that to counteract Google’s the same policy on all of their websites.
It’s never been about Apple blocking other browsers. Any browser that supports HTTP Live Streaming would work. It’s simply that, for years, Safari was the only browser to implement HTTP Live Streaming. Other browsers relied on Flash — for years — in order to play live-streamed video or any video which automatically adjusted its bitrate.
Their message is simply phrased in a way the average viewer could understand. If the message were “Your browser does not support HTTP Live Streaming”, it would have been useless to 90% of viewers. “Watch this on Safari instead” is actionable for them.
Why does this smell like the beginning of the browser wars in the late 90s. Internet Explorer 4 verse Netscape4. This is one of the cornerstones of why I do not like front end work myself, writing the same thing three different ways to appease six different people in nine different ways.
Well written, with some good points here. I’m pretty in bed with Google services at this point, so it’s Chrome all the way, but I would hate to see it get to the point that I can’t reasonably use Firefox for the same things.
Yeah I think this actually really sums it up for me too
I would suggest that Safari shares the shame in being more like IE6 than Chrome. It’s laggy farther behind in web standards than any other browser and integrated directly into the OS (iOS) so deeply that other browsers are not allowed to run on that OS and it only receives updates when the entire OS gets an update.
The issue with Chrome is not Chrome itself, it’s piss-poor devs being lazy or possibly even spiteful to open standards.
+1 from me.
Something else to remember, unless I’ve been lied to, is that Chrome uses Google’s own Http protocol when visiting Google webpages. Who knows what kinds of things they could be optimizing behind the scenes. I’m not saying that it’s the right thing to do, but definitely worth consideration and research :)
They used their own experimental protocol called SPDY for a while, but that got folded into the HTTP/2 standard.
The protocol you likely meant is called QUIC if it’s still in use you should find it in chrome://net-internals (IIRC)
Parettos law. If things always seem to work in one browser and most people use it, why cater to anything else? Or even discuss it?
Well, it isn’t like you should expect to have to support way out there browsers like say Brave or something. But the discussion of supporting modern IE, Chrome, Firefox, and probably Opera too should always be on the table. Why not support them? Chances are if there is a feature not supported there is a shiv of some sort so you can be cross browser and grow your audience.
I’m a bit guilty of doing such messages. It was mainly for input type date and other things like this that I didn’t want to code for browsers, like Firefox, that didn’t support it (Firefox finally caught up 5 years later).
So instead of wasting my time with those declining browsers, I decided to block them if they didn’t support a specific set of features.
The issue is that FF fans thinks that FF is part of the leading browsers, which is far from the case as they are behind Edge!
How do you figure that Fx is behind Edge? Fx has generally been ahead of all the other browsers (except Opera) in terms of standards support. And even now, Fx is way ahead with things like Web Assembly.
I remember the mess trying to developing for multiple browsers. If anyone doesn’t see a problem with it, its because they are new developers and weren’t around for it. Have fun rewriting your css down the road.
I’ve been developing for years, and I don’t see a problem with it. But I do see a problem with not bothering to make things cross browser compatible. It shows you either don’t care, are lazy, or don’t know how. Only the last of those 3 are excusable.
As soon as the other browsers are on par with the Chrome’s support for latest EcmaScript features, I may consider not to limit the browser support. Otherwise, sorry. IE is not a browser. Fix it.
I may have missed this in Chris’ and Tom’s Articles, but why is it that Google feels some of their products wont work properly on other browsers. Is it because they have ignored web standards or is it because they have followed them to the letter and pushed the bounderies where other browsers havnt? (This is a genuine question rather than me jumping to a conclussion)
I do feel like you should build sites to work for everyone, but if you are pushing the Tech Boundries and shipping the latest cutting edge stuff, then surely you can only be expected to Follow web standards. If your competitors don’t, then that should be a reason for their customers to move away from them?
Power begets power. Google is so big they are going around the HTML Standards world view and trying to “introduce” elements of which should not be added without full compliance considerations; only because they can. Do you think Walmart or Amazon would crash the gates of the shopping world by making components which only work on certain browsers? The Developers that are using “tools” for Chrome-only are using those assets because they believe they are promoting good ethics by supporting Chrome’s ideas (IMO).
Just like Wallymart, Google is being very impetuous by offering elements in their “society” (corporate decisions… what’s next, no insurance for G employees) which are not fully vetted from within the standards of the industry.
Sure, go ahead and experiment; but do not release a piece of the pie that holds together a DOM without full cross-browser support. If you want a “speciality” browser like One-off then so be it. But Chrome aint special. Would you build the space station using screws that were not tested? Personally—IMHO—Quantum just got me onto the Firefox boat and I never use Chrome unless I am forced to.
So, the problem is that Chrome is evolving and implementing new stuff, while others don’t, so you need to always use third party, making your app heavier.
Chrome is not the problem, the other browsers are the problem, and if we don’t use those new features, they will never implement it..
Thank God Google didn’t followed the slow and old web standards that just didn’t evolved enough.
As a developer you should code for users, not for browsers :-)
So you are saying that Apple should open all of their closed apps to Android, windows and others because not all users use their products?
So we should not use new technologies because of the users? Beautiful degradation is there for this reason, building a app that works on IE9 make the app at least 30% more expensive for the client, here em Brazil we just don’t have enough time to think in old browsers, the client sometimes wants the application to be Live in 2 weeks, from Scratch to end, and yes, chrome is the best tool for that.
As a developer you should deliver What the client want, with the technologies you have until the deadline , even if it doesn’t work in all browsers at first, just make it clear to the client that it will not work on all browsers in two Weeks.
Most try to stick to works on most browsers, ever now and then I forget to check something really like how it turned out … and spend hours trying to make it work, usually never as nice!
Although it’s not nice of Google that it does not let their apps work on non chrome browsers, I also doubt that it tries to alter the performance of Firefox on windows. When Chrome is opened and you open Firefox it takes a while but if you open Firefox first it opens quite fast. Maybe anyone with more experience can inspect that better on that.
The only way to have standards is to have it legislated, worldwide, that only one browser can exist. Otherwise there will be competition, as there should be. Innovation will always bring a greater net benefit.
Browsers are the distribution mechanism for software, and if you’re going to allow more than one company to release software you will need to accept that each will want at least some freedom to customize their distribution pipeline to maximize the impact of the products pushed through that pipeline. Just as it would be silly to suggest all software must be distributed via Steam. Would be well intentioned, but naive.
The problem is when Google asks you to use their own code to gain search visibility and speed. AMP is prime example of that.
I miss AOL Browser.
While reading this article (before reading the comments), I kept thinking “Yeah, but the websites cited are all Google sites. This isn’t an issue. Non-Google websites don’t do this.”
I was really surprised after reading the comments to realize that apparently it does happen elsewhere.
As for the Google websites doing it… those websites are free to access. If the only payment required is that I have to use their browser, that doesn’t really feel wrong to me. Does it count as a monopoly if you never charge money for anything?
The best solution is not using non-standard features at all. Most of the chrome-specified (or any-other-browser-specified) problem are the result of the lack of standards. But now with tc39 and w3c being updating well-requested and awesome new features, most of the time it is on browser manufacturers the responsibility to keep things updated.
But with the babel heat everyone seems not really cares about standards and uses whatever looks convenient (The legacy decorator draft).
In conclusion, I think browsers can update their APIs as long as it follows the standards strictly. And developer should not use non-standards features just because of convenience, double check them on website like caniuse.com is a necessary modern habit.