No not even close by every single possible measure.
I was there, I suffered through it, Google would have to make TONS of hostile moves for that fact to change.
I have no interest in the arguments of a closed source subscription service that wants me to switch to the bundled browser of the wealthiest company on earth's most popular consumer OS, lecturing me about using the 4th wealthiest company on earth's browser that I freely installed.
The most important one from an anti-trust perspective, every device I've ever had Chrome on I've had to seek out and install/make default Chrome, that includes my mobile devices which used the manufactures browser by default.
If I want to use chromium I can, Safari has been VERY late in implementing certain industry spec standards (SSE's, web sockets, IndexedDB API, animations, relative color syntax, container queries, a bunch of <video> stuff, flexbox, the list goes on and on.)
Safari hasn't actually been particular far behind implementing industry standards. As far as I can tell, it's more that people seem to believe that Google dictates industry standards and base everything on when Chrome supports it as opposed to when it actually gets standardized.
SSE's
W3C draft standard in 2012. Supported in Safari in 2010.
web sockets
This one is true. IETF standard 2011. Supported fully in Safari 2013.
IndexedDB API
W3C recommended standard in 2015. Supported in Safari in 2014.
animations
If we're talking the Web Animations API, it hasn't been standardized yet (W3C working draft) and level 2 isn't even that far.
relative color syntax
Not standardized yet. It's currently a W3C working draft.
container queries
Not standardized yet. It's currently a W3C working draft.
a bunch of <video> stuff
Need specifics.
flexbox
W3C candidate recommendation 2018. Supported in Safari 2013.
This is very misleading, compare implementation timelines between browsers and you'll see that Safari has implemented many of these things year(s) after chromium, firefox and even opera. This of course was because they have tried as much as possible to push people to closed source/walled garden apps.
I still don’t understand what you’re trying to say about Safari. After reading the response (outlining draft vs support dates) to your initial comment it seems like the reality is that your primary complaints dont make much sense. Maybe there are some other features that they were late to start supporting. Seems more like other browsers jumped on new features before they were standardized, and maybe that is at the heart of your original complaint? Safari taking “too long” to support things that dont have a standard?
So what? It was recommended in 2015 and was working in 2016, what's the big deal?
The big deal is that if you tried to see if you could use it at all, you would get false information:
```js
function indexedDBOk() {
return "indexedDB" in window;
}
```
This returned true on Safari, all of the functions did, and a bunch of them looked like they worked too, until they completely bugged out.
So we couldn't use them until it was fixed, *and* because you can't reliably use features until the last two major versions of a browser support those feature and because Safari releases updates locked to OS updates, that means that it wasn't what most would consider "supported" until nearly 2018.
That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.
So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
And instead of improving your project, you have to either try to retrofit the base storage layer of your app, or build a new product based on a different tech. That's assuming you were lucky enough to have the runway to continue and not just have your project fail.
They weren't just late, they lied and those lies harmed developers.
> So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
You spent 6 months developing against an unstandardised technology on a platform with well documented compatibility complexities, and you didn’t test it on one of your larger target devices?
And so you'd purchase a new iOS device for ~$1000 and test against it.
Then you realise that you're getting bugs from some customers that you literally cannot replicate on your device.
Then you realise that the bugs are type of device independent, so you need to purchase one of every kind of device apple offers for ~$10,000 and test against those.
Then you realise that the bugs aren't just type of device independent, they're actually dependent on a combination of OS version AND type of device.
So you spend another ~$10,000 for a second copy of each device, and set them up to never auto update.
But now you need to wait 12 months for the next iOS update so you can test the current and the previous version, but waiting 12 months won't do.
So you want to rollback iOS versions, but Apple doesn't let you do that.
But they do let you simulate combinations of iOS devices and versions through xcode. So you buy a macOS device and you're out another $5,000 and spend time simulating, but then you realise that the simulations don't actually replicate the device bugs, they're just running sandboxed versions of desktop Safari on the host machine that are scaled down and streamed into the simulated device. And so we've learnt a $5000 lesson on the difference between simulation and emulation.
So here you are, out ~$25,000 and dealing with customer complaints and troubleshooting, the you find something unexpected... You find a customer with a combination of type of device and OS version that you have, and you can't replicate the issue.
So it's not just type of device plus OS version dependent bugs. The bugs are independent to the devices themselves. Yes, really!
So what do you do at that point?
You have no way to reliably test if a feature works, the only thing you can do is take Apple at their word and recommend to customers that they can still access your product through other platforms (Android, macOS, Windows) and just put up with the angry complaints and reviews from iPhone customers that you can't help.
--------
The above comes from personal hands-on experience.
We have purchased multiple of the same device on the same day from the same shop with the same OS on factory settings and have witnessed different behaviours.
Reporting issues to Apple is useless, their responses are absent at best, and hostile at worst.
> That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.
Chrome, Firefox and IE had buggy implementations in 2012. Firefox didn't support IndexedDB from worker threads and would corrupt data. Chrome couldn't write blobs and would corrupt data.
Safari certainly required more workarounds due to more bugs than anyone, but the truth is that the IndexedDB standard sucks. For goodness sake, there's still no standard for locking to prevent corruption between two tabs (while everyone supports the Web Locking API now, it's not actually a standard).
We would have all been better off if we tossed it and replaced it with WebSQL.
> because you can't reliably use features until the last two major versions of a browser support those feature
Maybe a bit of a nitpick but this particular comparison is exactly the same with any other browser.
Sure, Safari is locked to iOS version, but iOS adoption rates are insanely fast, about as fast as browser updates. We are talking 90% current major version adoption within 5 months. Here's a source with some historical info: https://worldmetrics.org/ios-version-statistics/
So really, at worse you're looking at being one year behind to cover 95%+ marketshare in iOS.
The latest version of Safari runs on the two previous versions of macOS, so it's even less of a problem on macOS.
> So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
That could happen to you if you don't test your software on popular platforms.
Let's not forget, Safari and Chrome have the exact same open source core with proprietary commercial applciation development model. Safari has about 1/4 of the user base as Chrome. But here we are expecting the open source community around Webkit to fix bugs just as fast as Chrome?
You could have fixed the indexDB bug yourself if you wanted to. I would say that what you are framing as "Apple lying" about capabilities can be more generously interpreted as "Apple has 1/4 of the community developer resources to find and squash bugs in Webkit compared to Chromium." Really, it's far less less considering that essentially every other browser besides Mozilla uses the Chromium engine. Microsoft is of course another huge company also contributing to Chromium, and once you put Google and Microsoft together Apple doesn't look like such a behemoth anymore. The only thing that makes Apple "bigger" is the fact that they sell a lot of high margin hardware. In reality, the software businesses at Google and Microsoft are far larger and more complex than Apple (e.g., Apple has no enterprise cloud computing business, and essentially no enterprise software business at all).
Apple purposefully does not support immersive WebXR in Mobile Safari. If it did 8th Wall wouldn't exist.
Mobile Safari would regularly break WASM. Like iOS 10.1 and 10.2 just broke it for no good reason. It had a broken WebGL 2 implementation for a long time. This hobbled Unity games.
The compressed textures support for WebGL was also broken for a long time.
The lowest latency WebRTC codecs that Stadia and Xbox Cloud Gaming used were also purposefully not enabled by default. Google had to smuggle in an obscure WebRTC feature for low latency via libwebrtc that Apple just didn't know about.
I have no idea why you guys are going out and defending this stuff. Android Chrome has much better support for web standards that Mobile Safari does, even in situations where the codebase was shared like libwebrtc, because of strategic Apple decisions.
I wouldn't say I'm defending Apple so much as I'm defending the idea that it might not just be making these technical decisions/iterations entirely based on the most cynical possible interpretation of the situation.
For all we know WebXR immersive just isn't ready yet, just like WebXR wasn't ready for VisionOS 1 and shipped in VisionOS 2, which also makes sense considering that Apple's VR/AR business is years behind its competitors.
Broken stuff can just be bugs and regressions.
And I think it's also contextual to point out that Google really badly needs you to prefer Chrome and have the browser with the most features a lot more than Apple needs Safari to be anything more than a functional basic web browser. Examples like Stadia or even Unity in the web browser are essentially features that nobody asked for and that have worked better as native applications for decades. In other words, Google depends on the web browser being "the only application" as much as Apple depends on their users turning to the App Store first.
I totally get where Apple has a vested interest in boxing out competitors in the way you describe, but at the same time some of the complaints end up sounding a lot like bugs or just being generally behind in development velocity.
This is plain bad faith. If you know anything about web standards, you already know the W3C process requires candidate implementations and interoperability before a standard reaches its later stages. Other browsers implemented the standards earlier because they participated in that process; calling those implementations "non-standard chrome/etc features" is absurd.
Later stages? These features often get implemented at the working draft stage - a stage where major changes can still happen, it has no consensus or even wide review.
Google implementing a draft they themselves authored with minimal review doesn't make it standard just because w3c publishes the draft.
When chrome/firefox/opera all implement a working draft and demonstrate interoperability, they are participating in the standards process. Trying to make it sound like they're doing something non-standard when they do that is simply dishonest.
As usual, there's supported and "supported" with Safari, nobody could build an IndexedDB app in 2014 supporting Safari, I've been there. It's only been really stable through the past 3 to 5 years max.
It definitely is, I was also there, just like everyone was doing IE only sites, not only plenty of people do the same with ChromeOS vision of the Web, they ship Chrome alongside Electron crap.
Safari is the last man standing before a ChromeOS world.
Safari is the last man standing before a ChromeOS world.
Except it isn't. Maybe I'm being slightly obtuse here, but the world is not "Chrome Vs Safari". It's "Chrome Vs Safari Vs native apps". If Safari dies we'll be in a world of "Chrome Vs native apps", and that is what Apple wants. Browsers represent a way to deliver software to users that's outside of Apple's revenue mechanisms.
Apple have every incentive to keep Safari being good-not-great at running web apps, so users prefer the native version (even though most of the time that'll be Electron.)
The Firefox that gets the vast majority of its revenue from Google, that Firefox?
I think the only full-featured browser with a prosocial funding model is Konqueror, where what little money there is mostly comes from EU grants. Not coincidental that its code quality was so much better that everyone else based on its rendering engine.
Konqueror no longer uses its unique KHTML engine and has switched to working on top of WebKit/Safari, making it just a wrapper, similar to Brave. It’s a pity that the last truly independent player in the browser engine market is gone, but such are the realities.
I use Firefox Mobile but have long abandoned the desktop offering. The only thing I feel like I get from the desktop version lately is a spiritual victory whereas the mobile browser actually has tangible features I prefer like add-ons and the search bar at the bottom.
Being the only Android browser (that I know of) that support extensions, namely UBlock Origin, means that Firefox is the only logical choice for me.
Chrome's Manifest v3 forcing UBO into becoming UBO Lite only strengthen my original decision.
Hopefully this move by google would push more people toward Firefox. Although considering the amount of people who happily surf the web with zero adblockers (including every single of my IT colleagues), I'm not holding my breathe.
Notably this desire -- to own a platform by making "native" code for your proprietary OS the "preferred" way to interact with the world -- was exactly the logic behind MS's "embrace and extend" nonsense in the 90's. It still feels weird to me that people don't react the same way when Apple does it.
They don't. Apple gets away with stuff today that would have made Bill Gates blush in 1998.
Imagine if Microsoft was able to just ban any competing browser from running on Windows. We wouldn't be here debating if Chrome is the new IE. IE would be the same old IE (and the web would be a lot worse off today).
Native apps have always been better than browser/cloud based solutions. The only people who prefer the cloud are lazy developers, tech companies who want to sell software as a subscription, and corporate IT who finds it easier than dealing with native software on the computers.
The end user is always served better by native apps.
Chrome won't die when it already owns 80% of the browser market.
And if it is bluntness that you want, native apps should wipe both of them, lets get back to the days of Internet protocols and leave browsers for documents, nothing else.
How many Regular Joe people are using progressive web apps in the first place? I think Android users also prefer apps over websites and PWAs anyway. I would guess that if I took a poll of all my real life not-technology friends that zero of them use a PWA, know what it is, or even have one installed by accident.
I think that this idea that Apple is making Safari deliberately shitty to stop PWAs from taking over may have been true at some point, but I think by now that battle has been lost and Apple doesn't have to defend that moat anymore. There's just a plain reality of installing native apps being a better user experience regardless of platform, even though it is more locked down and has its own significant list of disadvantages.
More recently, I have difficulty seeing what's so bad about Safari in this regard. It lets you add web apps to your home screen and works with notifications since iOS 16. Safari has features like picture-in-picture that the native YouTube app doesn't have. It also has extensions. Maybe there are some PWA features that I don't know about here that I'm missing?
Maybe this is my dumbest opinion: say what you want about Electron, every Electron app I've used has been a better experience installed as a native app than used inside a browser. Not much better, but better enough that I didn't want to keep using them in the browser (regardless of choice of browser). Slack comes to mind. I greatly dislike using Slack in a browser, and it's hard to point my finger on exactly why that is.
> How many Regular Joe people are using progressive web apps in the first place?
I know several of them, because Google doesn’t let e-commerce apps in my country sell cigarettes and other products containing tobacco. The android version of these apps guide users into installing their PWA version if they wish to order such products.
Except you can't. Every browser on iOS uses Safari's rendering engine. Chrome/Firefox on iOS are effectively reskinned Safari. This is an apple requirement. The rendering engine being the important part here when talking about standards and such.
A rendering engine is not a browser. Are all the Chrome engine variants really just Chrome in a skin? I don’t think so they all have unique properties that set them apart. As do Orion, Firefox, brave, etc on iOS
Every time this discussion happens a non-trivial number of people reveal they’ve fallen into this trap of believing other browsers are allowed on iOS. Feels like a consumer protection issue, at some level.
I tried Orion (m1 MBP) recently. From about 3wks ago til a few days ago. I liked the UI. But there were a lot of pages that didn’t work correctly. I persevered for a while. But gave up a few days ago and went back to Brave.
Safari is mandatory to have on iOS - it's preinstalled and can't be removed. It's also propped up in the sense of being built on apis and OS features that other browsers aren't allowed to use.
I mean, imagine if DOJ forced Apple to divest Safari and treat it the same as other browsers. What would happen? Parsimonious answer: the same thing that happened everywhere else.
Another piece of evidence is Google tries at nearly every turn to help people write portable code, use best practices like feature detection instead of browser version sniffing, etc... They run https://web.dev/ and the founded baseline https://web.dev/baseline and the web platform dashboard https://web.dev/blog/web-platform-dashboard
MS in their IE days did the exact opposite, trying to make as many proprietary IE only features as possible.
Just because Chrome implements a feature and then rams it through a W3C committee does not make it a “standard” that Apple must support on day 1. The arrogance of the Chrome crowd is astonishing.
I think some of the complaints in the article were about websites using User Agent string to detect compatibility, rather than individual feature sniffing.
In that small complaint, I would agree. But I think the fault is mostly with the website owners, not with the browser.
Feature sniffing generally doesn't work for anything interactive. Many bugs in controls, animation, events are not sniffable. Yet developers still need to deliver workarounds.
Feature sniffing works best for static HTML documents - and even then the code to actually do the sniffing can be demonic code (a side-effect or correlation or an obscure discovery).
Using just feature sniffing is a great goal but it simply isn't a perfect solution. I do believe us developers should avoid parsing user agents unless there is no other good solution (never a crutch for lazy bad developers).
And detecting the browser for obsolete browsers is usually a perfectly fine solution. The bugs won't get fixed and the browser won't change. There are exceptions of course!!!
> And detecting the browser for obsolete browsers is usually a perfectly fine solution.
But there are a long tail of user agents and the average web developer does a terrible job at identifying those in the long tail. My password manager on iOS uses the newest Safari engine, but all websites think it is an outdated/obsolete browser because it uses a user agent string they don't recognize.
Also, my bank doesn’t use highly interactive features you mention. It’s almost exclusively links, forms and a little validation JavaScript. Feature sniffing would have been a much better experience.
> Google would have to make TONS of hostile moves for that fact to change
I think the biggest issue with IE6 was not the hostile moves Microosft did, it is that it didn't do anything. The browser was just frozen. That's why it was relatively easy for Firefox to take a marketshare.
Frankly, with some of the APIs Google are adding to Chrome, I'd rather they'd do a little less.
So, no, the problem with IE was 100% Microsoft's hostile competition tactics. Yes, part of that was trying to deprecate the "world wide web" as a platform, so yes, IE6 got very crufty toward the end of its days.
But by that point it was clear it was already dying and IE7 et. al. were introduced late as an attempt to catch up. During the period when the real bullets were flying, IE6 was actually a really great browser, just one that forced you into using a menu of Microsoft technologies because it didn't support the "standard" stuff. Remember that XMLHttpRequest, the basic tool underneath all modern dynamic web UIs, was originally a non-standard Microsoft invention.
And yes: eventually this proved unsustainable and innovation in the standards-based browser world eventually proved too fast for MS to keep up, and it lost.
But the tool that broke the back of that monopoly absolutely wasn't Firefox. It was Chrome.
I would say that the 30% market-share Firefox had in 2009 was breaking the monopoly much more than the 3% Chrome had a time.
Sure IE6 had many non-standard APIs, but even the fact that all hobbyist browsers back then were implementing tabs and IE6 never had that, speaks to its stagnant development. To be honest I'd prefer some things Google is now pushing through th W3C as standards to be left as Chrome specific APIs and leave the rest of us alone.
That and browser sniffing to serve intentionally broken CSS on Microsoft's websites to competitors like Opera, I remember this because it directly effected me at the time.
I mean at least we still have websites like this from over 20 years ago that still document the bullshit, people who weren't there CANNOT fathom the how despicable they were.
Safari was late until a couple of years ago when they started implementing new features more aggressively. Now it's always Firefox. Just check how long it took them to add support for the :has() selector and RegEx Lookbehind. We're years into "manifest v3" and background workers are nowhere to be found.
Firefox has mindbogglingly bad performance with :has() even if their superficial tests tell you otherwise. I experienced minute-long lockups just because I used :has() on a large element like body. Chrome and Safari had no issues with those selectors.
> using the 4th wealthiest company on earth's browser that I freely installed.
99% of the time I use Chrome it's because some site does not support Firefox (and that often includes Google sites/apps). (The 1% are for APIs that Firefox, consciously or out of resource constraints, does not support.)
In what sense am I "freely installing" Chrome in this situation?
Just today I had a family member reach out to me, unable to use government e-signing on their phone after I'd switched their default browser to Firefox (they were getting tons of ads in mobile Chrome, which does not support plugins and accordingly also no ad blockers). Turns out they support only IE/Edge, Safari, and of course Chrome...
> every device I've ever had Chrome on I've had to seek out and install/make default Chrome
My Pixel came with Chrome preinstalled, as far as I remember. (I don't recall if there was a browser selection screen.)
Sure, that's a Google phone, but then again Windows is a Microsoft operating system.
> the arguments of a closed source subscription service that wants me to switch to the bundled browser of the wealthiest company on earth's most popular consumer OS
Oh, I'd also not advise anyone to switch to Safari. Apple absolutely would pull exactly the same or worse as Google if they could, I have no illusions about that.
I can't wait for the day they're finally forced to actually allow alternative browser engines on iOS and switch to Firefox everywhere.
I see this argument a lot. I use Firefox on my Mac, iPhone and my Windows work PC. I can’t remember the last time there was a website that was broken because of Firefox.
Do you happen to have any examples? I’m curious to see how broken/what the issues are.
Not who you are replying to, but before I switched to Vivaldi (a Chromium fork), I saw lots.
Among them: Logging into some of my financial accounts doesn't work on Firefox. Enterprise software and gear like VMware and management UIs of various devices on the network. (They foolishly hard-coded their devices to reject any UserAgent strings that weren't Chrome, IE, or Edge.) Sites that use some kind of poorly-implemented tracking/fingerprinting to make sure you're a human. (I would routinely get stuck in infinite CAPCHA loops even on normal sites.) For a while, Slack video/audio calls did not work on Firefox because Slack chose to use codecs that FF didn't support. Video calls on FF are still hit-and-miss on various platforms, ran into it on Facebook just the other day.
These are all just off the top of my head, of course. There are plenty more that I've forgotten.
I don't use Firefox currently but I did for a couple years recently. For a while Teams was blocked and/or broken in Firefox due to calling features Firefox didn't have at the time.
A few sites would silently break, e.g. restaurant online order pages, but work in Chrome. Never really looked into why, it was just annoying and intermittent (might work one month but not the next).
YouTube occasionally had some issues. For a while it was on an old version of Polymer that used Shadow DOM V0 (experimental) instead of V1.
A good list is here https://webcompat.com/issues?page=1&per_page=100&state=open&... keep in mind some of these are "is extremely slow in Firefox". Sometimes that's just that Firefox didn't have the same set of optimizations (not necessarily even fewer optimizations, just not ones built against) and other times that's deeper seated like the Shaw DOM V0 example where the fallback for the page was to use some older.
I don't understand this because I have used Firefox exclusively since it first came out and never run into broken sites. What exactly are these exotic sites you are visiting that break in Firefox? You mentioned an elusive government website but I have used many (IRS, SSA, Edu, etc...)
>What exactly are these exotic sites you are visiting that break in Firefox?
In my case, an example of a non-exotic site is Youtube streaming 4k 60fps videos. I tried with latest Firefox a few months ago and it was still stuttering and glitchy. But Chrome plays smoothly with no issues. I previously mentioned that 4k playback has been a long-standing issue: https://news.ycombinator.com/item?id=28783904
On one hand, my computer is fairly old ... but then again, Chrome works fine on that same old hardware.
Never seen this; however, youtube prefers pushing VP9 over H.264. Maybe your computer cannot use hardware decode for VP9 and can for H.264? (Since you mentioned, it is an older one). Maybe the h264ify extension would help.
What firefox cannot do and chrome can is HDR playback.
> however, youtube prefers pushing VP9 over H.264. Maybe your computer cannot use hardware decode for VP9 and can for H.264?
No, even if I download the 4k 60fps file using yt-dlp with forced h264 codec settings locally to my harddrive, Firefox still can't play the mp4 file smoothly.
So it's not really a streaming issue or h264 vs VP9 codec issue. The Firefox core engine doesn't seem optimized to playback 4k and 8k high-frame-rate videos with low cpu utilization. Even VLC for 4k and 8k isn't as smooth as Chrome. I don't know what the Chrome team did but they really optimized that code path to play back hi-res videos.
Interesting, I recently had the opposite experience. Wanted to enable hw decode on an older Intel system and only got it to work on Firefox. Tried several different instructions from the web on how to force chrome to ignore any blacklists for drivers or anything, but still no luck.
Oh and a while ago I noticed (on a more modern system) that enabling hw decode makes chrome ignore the aspect ratio of the video and displays it like the pixels are square. Again Firefox handled it fine.
YouTube is routinely broken for Firefox, especially when navigating around in places like shorts. I actually find this to be a feature because it prevents me from continuing to mindlessly consume. But it is broken.
I'll give you one example: I sometimes can't open OpenAI API documentation due to some stupid Cloudflare captcha checks. No, on Firefox, however many times I click that checkbox, I can't go through the verification, just to read some static content. Not even if I disable adblock and tracking protection.
I don't even see a checkbox at all on Chrome or Edge.
Sure, technically nobody is excluded: Just solve the captcha! Fraud heuristics are only reasonable, right?
But it's all fun only as long as your situation occurs within the 90th or 95th percentile of all data labeled "good customer". Good luck if you're out side of that...
I mostly use Chrome on Linux (fully Google distributed, closed source Chrome...so not Chromium) and I see those cloudflare captchas at a much higher rate than I do when using Windows or macOS.
This is also my experience. But to be fair I have a heavily modified privacy-centric Firefox, and I disabled some features in the config, and I disable js and large images and of course tracking/ads by default, and I delete most cookies on browser close, and I run Wayland on Linux so... any breakage is probably on me.
I almost always find that when sites do not work with Firefox (also Wayland on Linux) it works with Firefox (on the same machine) without the same plugins and settings.
Enabling JS is not enough, so I think its liked to privacy plugins, or running inside a container.
the cynic would say if you can't be tracked, you can't be monetized. unfortunately, being successfully un-de-anonymizable means you can't be distinguished from a bot.
The likely reason why they don't support Firefox is because it has less than 5% marketshare. It isn't a Chrome only site. You said that they support Chrome, IE, Edge (if they support IE then I'd assume that they might also support pre-Chromium Edge), and Safari.
That is just the nature of using a niche platform. I primarily use Linux on the desktop. I have to keep a Windows install around for the times that I need to do something that can't be done on Linux. Resources are limited and so high marketshare platforms are prioritized. That's just how it is.
The onus is on the app developer to make sure their app runs on a variety of platforms. It's not Chrome's fault for third party developers being lazy and not supporting Firefox.
I don't know of anything that is completely broken, but some functionality requiers chrome:
On Google Docs, paste as markdown, copy and paste from menus, paste without formatting, etc. only works on chrome. This functionality could be done with standard APIs, but instead google uses a hidden, pre-installed extension to implement it.
Offline mode doesn't work on firefox for either gmail or google docs.
Google doodles don't show up on Firefox Mobile, unless you spoof a chrome user agent.
Youtube has repeatedly had serious performance problems on Firefox.
"AI overview" (which I happen to find really useful) was only available on Chrome and Safari for at least a few months.
Sure, it's a lab experiment or whatever, but these are just words, and the effect is that I have to use a different browser to be able to use them, for absolutely no technical reason. (The LLM is running on Google's servers and provides plaintext. I think Firefox could handle that.)
"Given the market-share dominance of Blink-based browsers,[4] if Google chooses to not support a standard, like JPEG XL,[30][31] it will not become relevant on the Web.[30][31] Such standards are not listed in these tables."
So if Chrome implements something that Safari doesn't, then its a deficiency in Safari. If Safari supports something Chrome doesn't, its not relevant so will not appear in any comparison tables.
Chrome is 100% the new IE, as it is the being treated as the sole arbiter of what is a web standard or not.
You can see it here, too. And in all discussions around PWAs. And on sites like whatcanwebdotoday. Anything Chrome ships is considered crucial, critical, and standard. And other browsers are shit because they don't immediately implement everything Chrome implements
I manage websites for a couple of non-profits. A very high percentage of traffic is from Safari (mostly on iOS) -- 40% on one site. Only testing in Chrome seems like a bad idea.
Yeah one non-profit is a place that people physically so I imagine a lot of people look at it on their cell phone. We have over half of our visitors on mobile.
No, I dont think this is the case. While a lot of devs use Chrome while developing, we're all well aware that 50% or more of US users are using an iPhone. And that's Safari no matter what. So many do a ton of testing there as well. Firefox often gets the shaft.
I know as a matter of fact that many teams'/companys' approach is "We'll develop and run our CI tests on Chrome only. If it breaks on Firefox or Safari, we'll fix it, but that's as much as what we care about." And I'll be honest, for many organizations, it's a good business and financial move.
> If it works on Chrome, no one cares or even tests for other things.
We've been through an extensive standardization pass for this to not happen. Anything not matching the specification whether in Chrome or any other browser should be considered a bug.
This is not at all the same as IE, where it just went its own way.
The unstated major premise of this assertion is that the standard is a spec that every browser must comply with exactly. It's not; there's not a single browser that has ever implemented 100% of whatever was the latest standard at the time, and major browsers typically also include many of their own additions that go beyond the standard.
This latter bit isn't in conflict with the standard; it's an essential part of the standardization process. The typical route for something making it into the standard is for a browser to release their own browser-specific extension and use that as a basis for advocating that it be added to the standard. XMLHttpRequest, for example, started as an IE-only feature and didn't make it into all the other major browsers for several years. It got a published W3C spec a little bit after that, which meant that browsers needed another couple years to also get synced up on their behavior.
In this respect, Chrome has definitely now taken IE's old position: new Web standards have a tendency to start as Chrome-specific extensions, and then the other browsers have to implement their own versions and get them ratified into the W3C specs in an effort to try and keep up. Which in turn suggests that a compatibility-minded Web developer might want to choose a similar strategy from what was done in the past: test on the most popular browser last.
> The unstated major premise of this assertion is that the standard is a spec that every browser must comply with exactly. It's not; there's not a single browser that has ever implemented 100% of whatever was the latest standard at the time, and major browsers typically also include many of their own additions that go beyond the standard.
Sure, but there is a big difference between implenting 99% of the standard and only implementing like 10%
As I wrote in a similar thread a year ago: Whenever I point out that some bug which happens in Firefox my colleagues usually responds with some variant of "we tested in Chrome, and that is the standard", or "can you ask the customer to use Chrome instead". Even if Firefox or some other browser may be using a proper standards implementation and the Chrome one being the one with some quirk.
What about half-assed specifications that Chrome throws over the wall, ships them, and advertises them as standard everywhere, including web.dev? Even though their status is "not on any standards track"?
One issue I keep see cropping up with various corporate websites is they will only allow Chrome and will block any other browser. I would say in 9/10 cases, this isn't because the site uses features not supported in other browsers but rather, developers restrict it to Chrome because that's all their QA's test on.
Which is ironic because scores of enterprise companies developed internal systems/reporting/intranets using .NET in the early 2000s, restricting their users to Internet Explorer!
Not even close. IE 6 didn’t get any updates or new web features for years. It was closed source. It was dead and everyone used it. float:right; zoom:1; was a common necessity… to compare them is an insult to the immense progress and effort spent over the last 24 years… (yes chrome started in 2007, but the teams from Firefox get credit too, many of them went on to build chrome ). The open source movement won, IE is dead - MS shipped edge. We can argue about how Google is evil all day but it’s night and day compared to what the web was like in 2000
We don't have float:right;zoom1: but our "necessities" nowadays are even crazier. Babel, vdom, frameworks provided by browser-vendors. Those are several orders of magnitude more complex than previous "workaround" approaches to the web, all unstandardized.
How about Electron? Do we see any Firefox-based desktop apps around or is that market completely dominated by the Chrome runtime? Are app developers happy having only Chromium as the viable solution? (my guess: they're not, but they have no choice).
Where we're going is even nastier than clearfixes and table layouts.
Isn't this a Firefox/Mozilla fault as well ? Afaik there is really no API or support for embedding Gecko & anyone who tries to do that, is on their own, having to periodically rebase large patch sets for embedding.
Possibly. I guess XUL was that API, but XUL is no more.
It helps if your company uses the embedded stuff in other products. Like Microsoft used the Trident engine from IE6 all over Windows components. In that way, allocating resources for developing an embeddable engine is justifiable. Can Mozilla do that? I don'know. Google can (and does it! why wouldn't they?).
But sadly on Android the alternative is simply using a Chrome/Blink-powered webview, which is capable enough for most people and importantly comes at a zero APK size hit. So you need to have pretty special needs before including a complete custom browser engine inside your app becomes an attractive proposition.
(Whereas on Windows for example for a very long time the only OS-provided browser engine was IE, so if you needed more advanced web features, you couldn't avoid shipping your own browser engine in your application anyway.)
Hmm, you’re right, I think GeckoView is “marketed” specifically for making browsers:
> However, Android’s WebView is not really intended for building browsers, and hence, many advanced Web APIs are disabled. Furthermore, it is also a moving target: different phones might have different versions of WebView, all of which your app has to support.
It might still be an okay choice for an application shell sometimes (e.g. if you use a web API that is not supported by WebView and no polyfill is readily available for Cordova/Capacitor).
If something uses DOM and JavaScript, to me it's web enough to be called web, even if it is rendering outside of regular browser expectations (some React Native stuff or similar). The whole premise of this tech is to approximate app development to web development.
Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.
VDOM would still exist if the DOM was faster. It's a different abstraction that reconciles the differences between the simple data->elements flow and the inherently stateful DOM. If you don't understand why VDOM exists, here's a nice experiment: in your next web app stop using VDOM and always set innerHTML. You'll find that (1) it's actually fast enough so you can conclude that VDOM doesn't exist just to patch over DOM slowness; (2) you are missing some features you get in VDOM.
The answer is that the DOM inherently has state. It could be a textbox's text input and its cursor state, or the focus state, or whatever. But developers don't want to think about this DOM-managed state to simplify their mental model.
Let's ask the next why. Why make the interaction with the DOM stateless?
Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used.
So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state).
Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls).
It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?
The open source movement has been co-opted. Its core values were laid out in a world where people owned their own computers and were custodians of their own data. There was no cloud, there was no saas, and that meant that owning source code meant you had some level of control over your digital life.
You're right. It is night and day. In 2024, access to source code is no longer, in and of itself, an effective proxy for autonomy. And using how the world worked a quarter century ago as a yardstick for measuring the relative merits of Google's influence on the digital domain nowadays is specious.
When I parked a rental car in downtown SLC last week I had to find a way to pay to park. There was a kiosk with a functional screen, but the touchscreen part of it was broken, so I couldn't interact with it. I plopped my stuff down and sat on a concrete bench in the cold and dark to try to figure things out on my phone.
The QR code sent me to a website to install an app. Google Play store said the app was designed for an older version of Android and couldn't be installed on my device. I eventually found a "pay online" link hidden down the page a bit, then spent several minutes filling in my credit card number and what not. Then when I got to the part where I was to select the expiration month and year, the drop-down menus simply didn't work. I had no way to continue in my default browser, Firefox.
It had been 7 or 8 minutes, the cold was starting to numb my fingers, and I was no closer to actually paying for my parking space. I debated just canceling my appointment and driving away rather than risk a parking ticket, but I decided to give it just one more try in the Vanadium browser. Lo and behold, the drop-down menus worked, and after over 10 minutes of messing with a broken kiosk, a broken app, and a broken website, I was able to proceed to the point where I punched in my parking space number. Which, of course, wasn't marked.
At that point I looked up and down the side of the street and noticed a post with numbers for two spots behind me. I noted which number was bigger to infer whether my space would be one higher than the higher or one lower than the lower and punched that in. After my appointment I came out to find the car parked behind me had a parking ticket, while my car didn't. So I guess I managed to punch the right sequence of buttons on my phone to avoid a parking fine.
However the fact remains that I couldn't legally park my car in Salt Lake City unless I was in possession of a functioning smartphone and was running a Chrome-based browser on it.
Not sure if this is more a story of Chrome being the only browser that's tested and/or compatible with critical services I need to use to function in a major U.S. city or if it's a story about municipalities like Salt Lake City making things as difficult as possible for people so as to collect more revenue from fines.
Front end developers bear the responsibility for this nonsense, and many of the guilty post in this very forum!
There is nothing in what you described that couldn't be accomplished with late 90s-era technology.
Why is an app needed? A simple web page with basic HTML, enter number plate or space number, enter payment info, submit, done. No browser features introduced in the last 20 years are needed. The only improvement is enhancements to security - so we're up to TLS 1.3.
Do we really need spinning pinwheels and bleeding edge web standards to process a simple payment?
In the nearest urban center the meters don't take cash. The machines also do not take direct payment. The kiosk on each block also does not take payments of any kind. They force you to use a 3rd party app not actually owned by the city.
There is zero way to pay for parking unless you have a smart phone and data. I have no idea why no one has sued for access yet.
I remember this blog. Magic Lasso Adblock is Apple ecosystem only. Its view on pretty much everything is basically Daring Fireball.
>tends to be misunderstood to mean that Chrome is like Internet Explorer was in 2009
>Despite being the market share leader, there is significant evidence that Chrome is trailing in speed, efficiency and standards interoperability.
>Perhaps the browser with the most disruptive potential is from Microsoft with Edge...... It has also avoided alternative-browser compatibility issues by being based upon Chromium.
Every time this subject came up and I will find people who have never used all three browser at the same time. Or wasn't there during the IE era.
The phase "is Safari the new IE" was actually coined by someone who wasn't even there or doing Web Dev during IE era. It was IE6, not IE7, and definitely not 2008. And the phase somehow catches on to become is Chrome the new IE.
IE was absolutely dominant with 95%+ of browser market share during its peak. Neither Chrome / Blink nor Safari / Webkit ever achieved that. And the most important part was that the HTML / CSS and IE implementation had so many low hanging fruit but NO IMPROVEMENT were made for years. IE 7 / MSHTML released 5 years after IE 6 offered little to no improvement other than a few small fix.
Both Chrome / Blink and Safari / Webkit have continuous development over the years. We may not like some of the direction they are going. But every year there are improvement being made with HTML / CSS / JS features.
Second part being Chrome is a resource hog or slow. Chrome has made tremendous effort into making it memory efficient since 2021 when complain started to pile in. By 2022 and definitely 2023 multi tab on Chrome is far better than what it was. Safari on the other hand isn't doing well on MultiTabs for over a decade but gets zero attention on the issue. Meanwhile Firefox being the fastest browser in terms of least janks and best for hundreds of tabs gets No recognition either.
And lastly Interop. Since 2019 and I believe the first Interop was in 2021. We still dont have a 100% coverage on any Interop year for all three major browsers. I wish Interop could at least agree and publish baseline support that aims to have all browser support by 2025. Instead we are forever stuck in 95% with quirks everywhere.
Actually, quick search leads to [0] (not very reliable, but still better than nothing) shows that Chrome and derivatives take 72%.
As other commenters mention, Safari is mostly locked to the Apple ecosystem, so IMO Chrome on non-Apple systems is around 90%. Firefox is metered to 3% which is lower than reality (due to adblocking).
My personal experience is, however, very similar to IE golden age. In order to interact with state office web apps I need to switch to Chromium. Neither Firefox nor Safari are supported. Vivaldi is a mixed bag (not sure why though). For me this answer questions is Chrome the new IE.
Depending on which country it is, but Safari is anywhere from 30% to 60% of marketshare on smartphone. I have yet to see any government website that is not tested against Safari.
In US I believe that might be true (same site reports around 35%). But those numbers are dropping by a half when you move out.
In India 90%+ reported is Chrome. In Europe Safari is ~20% on average and where I reside it’s around 7% with Chrome being 75%.
Nobody here cares for web correctness. Situation is absurd: e.g. using Safari to input masked password letters for a bank login causes a random number of fields skipping forward. Called that in, no one cares.
When looking at the numbers I would say that US (because of high Safari usage) actually resists Chrome’s monopoly and might not (yet) experience the effects of Chrome IE-ification.
> Meanwhile Firefox being the fastest browser in terms of least janks and best for hundreds of tabs gets No recognition either.
This is likely subjective. Out of the browsers I use regularly, Firefox is by far the one with the greatest number of rough edges as well as the least likely to see those rough edges polished.
To some degree this is inevitable with the difference in amount of resources at Mozilla’s disposal relative to those of Google and Apple, but there’s a lot of low-hanging fruit. In a relatively short time many of these issues have been improved by a small team in the Zen Browser fork of Firefox, which suggests it’s more of a lack of will than it is lack of resources.
The number of websites that only work on chrome really sucks. It's a small percentage, but it's enough that you run into them and I hate that very much.
But unless I'm actively campaigning everyone I know to switch in an effort to save them from it, I'm going to reserve the term "the new ie" for another day.
Not to mention the developer story. Just getting a website to look right in every browser was difficult, with IE very often being by far the hardest.
Yes, Chrome is the de facto standard, and often the only browser thoroughly tested against. Even now though it isn't as dominant as IE at its peak though.
No, Chrome isn't significantly behind on adopting new standards compared with other major browsers (I'm looking at you Safari). IE6 to IE7 was about five years!
I see so many ideological arguments around "X is the new IE" that neglect one of the worst pieces of IE 6's reign of terror: the stagnation. Working around all of its quirks and non-standard behavior had an extremely long half-life; the venn diagram of things that worked correctly across all major browsers at the time was very complex and messy. Even with the release of IE7 it took many years for people to adopt it, and IE7 was hardly a saint either.
There's a part of my brain I'll never get back devoted to all of these workarounds. So many hours lost to weird corporate networks that had quirks mode enabled, different box models (before the advent of the `box-sizing` CSS attribute), random omissions of standards (no `:hover` on elements besides `a`), etc.
> one of the worst pieces of IE 6's reign of terror: the stagnation.
This is the thing that I think developers today don’t seem to be able to get their head around. There was a fourteen year time period between Internet Explorer 6 being released and when it dropped out of usage worldwide. Even if you only had to support the USA, it was still eleven years. People could go their entire careers without ever knowing what it was like not having to support it. It paralysed front-end development for more than a decade.
Deprecating it if your site had much traffic was like pulling teeth! I worked at a company that had IT professionals as its main demographic in 2011 and it was a constant struggle. Lots of corporations were locked into IE6 because they had developed internal applications that relied on ActiveX controls or other non-standard APIs. IE7 was still pretty terrible, and it took even longer to drop support.
CSS was pretty bad but at least well-documented; debugging JS was a whole other hell. There was no such thing as dev tooling, and you got a small alert in the status bar when the page had errors, which opened a pop up that gave you the line number and very little other information. Supposedly you could connect it to VisualStudio and get a full debugging experience, but I never had the luxury. Lots of guessing and checking. Firebug was a huge deal when it launched.
Which standards is Safari significantly behind on?
Note: you have to refrain from listing Chrome-only non-standards. You also have to refrain from listing standards that Chrome shipped years before actual APIs got standardized.
And you see evidence of this influence throughout Chrome.
For example, Apple simply blocked third party cookies which are almost exclusively used for tracking. Chrome waited years until they could add their Advertising Sandbox feature first.
Because Google itself can still track people if they sign into Chrome itself (which it actively encourages by using it as single-sign on for its own services), and thus AdSense can still serve targeted ads, but other ad networks cannot.
When was the last time you wanted to build a website and web browsers got in the way? Those days are long gone. Compared to a decade ago, everything is amazing.
Mobile Safari is the new IE. Random idiosyncrasies that are poorly documented dictated by the whims of a single corporation. Apple has broken stuff multiple times in the past few years.
I was thinking more of every web app needing one or more "if isIE() {} else {}" blocks somewhere in its codebase. Now we have the wondrous pleasure of doing the same for Apple.
Microsoft stopped developing IE when the government sued them for simply including IE with Windows, the same thing Apple does with Safari. But Apple is far more abusive and forbids any other browser engine on iOS, all browsers on iOS are forced to use Safari under the hood.
> Microsoft stopped developing IE when the government sued them for simply including IE with Windows
They weren't sued for simply including IE with Windows (bundling IE and business arrangements to prevent OEMs from replacing was one of several means of leveraging the Windows desktop OS monopoly to monopolize other markets in the antitrust suit), and they didn't stop developing IE when that suit was initiated.
> But Apple is far more abusive and forbids any other browser engine on iOS
Bundling wasn't the offense, illegally leveraging the desktop OS monopoly to monopolize other markets was the offense. Bundling was part of the means but the means itself want illegal, the ends to which the means were employed were.
> "The central issue was whether Microsoft was allowed to bundle its IE web browser software with its Windows operating system."
> "the DOJ built upon the allegation that Microsoft forced computer makers to include its Internet browser as a part of the installation of Windows software."
It's the same exact situation with MacOS/iOS and Safari, but it's actually far worse with Apple and iOS Safari because people have no choice to install another web browser on iOS, all web browsers on iOS are Safari.
Now, finally, the DOJ is rightly going after Apple for doing this, and many, many other abusive business practices.
Safari, the browser that claims to support standards but always comes with caveats, like saying they support transform/transitions and then everything with box shadows flickering
It's also very slow to support new standards, in my experience.
Web push notifications literally took years to make it from macOS to iOS, for example. (Yes, these are commonly abused for spam and other user-hostile things; no, I don't think that's a valid reason to withhold them from the only acceptable browser on their OS entirely.)
Yes it is. I use Firefox wherever I can to not allow one company to take over the internet with their toxic patterns (manifest v3, disallowing screenshotting on pages, breaking their services on other browsers etc.)
Just to (mostly) preempt this because the exact same discussion is had every time this sentiment comes up: Isn't safari the new IE?
Answer: They both are like IE, for different reasons:
Chrome: Pushes proprietary extensions onto the web, which due to their absolute dominance others are somewhat forced to adopt, people develop for it and don't test in any other browser, just like IE
Safari: is coupled to operating system version, lags behind on implementing new features, thus single handedly slowing down when everyone can use new features. Has weird quirks that other browsers don't, just like IE (though not nearly as bad as IE)
So which is like IE? It just depends on what you mean when you say "like IE", the label applies to both because IE was bad for more than one reason
I'm actually far more concerned with the other thing I mentioned, just like on old versions of windows, safari updates are coupled to iOS updates. So if your phone doesn't get any more updates, or you just don't want them, your browser engine is out of date, giving years old safari versions significant market shares. And this impacts stuff like being able to use "gap" for flexbox, which I don't think qualifies as a proprietary chrome feature
I'd love to find out if anyone on the webkit project is aware of that part of the standard, and if so, the project's official position on it. I can't imagine why they'd oppose it.
Did “everyone” agree on and implement them, or did Google implement them and force everyone else in the WHATWG to play catch-up since they’re dominant?
Your own link says it’s supported on Safari for iOS, for years now. It’s obviously not supported on MacOS because that attribute only applies to onscreen keyboards.
So, things that are either impossible (touch events or vibration) or ridiculous (why would I want a website to know my battery level or directly access system hardware?)
Who said that we want native apps to be able to do that?
There are some use cases for those permissions but we (some) would like more control into that. I can't fight most of the websites as a user (they will tell me to use chrome) but it is for them hard to tell me if you want the service (along a billion other user) then move to android. Apple for a better or worse have much more sway than individual user.
I’d love to see these comments about Safari lagging give specific examples. Every time I’ve seen specifics, it’s either only interesting to progressive web apps, or blatantly user hostile tracking/nagging “features”. In my personal experience as a web dev, Safari is often the first to implement new features, and otherwise lags literally just a few months behind, according to their release cycle. WEBP was the exception that was both a real feature and very delayed, but now with JPEG XL it’s Safari first by a mile and Chrome holding everyone back.
if you want a really old example, pnacl. If you want a slightly recent one, FLoC. Not saying those are the best examples, they are just what comes to my head first. I don't really keep up super closely.
pnacl was an example of Google throwing away their homebrewed solution in favour of a common standard (Web Assembly). That seems like a strong argument that they don't push proprietary extensions.
it was an example of them pushing proprietary extensions and eventually removing them again. If I start beating you and then eventually someone calms down and I stop, it's not an example of me not beating you
Yes. By virtue of most other popular browsers being based on it (chromium), with the exceptions of Safari and Firefox. The controller of the project is still Google.
Safari trails chrome because Google didn't like Apple being in charge of the Webkit repo, which led to the Blink fork (the Chromium engine).
Firefox is still a great browser, but it has fallen back to square one on popularity.
From an anti-trust perspective Google should offer to fund their competitors directly instead of splitting the browser out, the eventual result should be revisions to web standards specs to ensure they are correct and detailed enough to be accurately implemented, which in turn makes new browsers easier to implement. Eventually if specs are close to 100% correct it should be reasonable to generate new browser engines from them. Currently that's not possible due to chasms of ambiguity and contradiction, and because browsers like chrome occasionally implement their own design of stuff just because they want to.
> Perhaps the browser with the most disruptive potential is from Microsoft with Edge... With Edge, Microsoft has a chance to claim the position of the disruptive alternate browser.
I believe moving from Chrome to Edge does not change a lot in terms of privacy, proprietary ecosystems, data mining practices, or other reasons that made you switch. In the end, it’s a transition from one tech giant to another of comparable scale with the same practices.
Safar? I don't think Apple has the intention to dominate this sector, so it won't push Safari beyond its current geography. All that it cares about is its * walled garden.
Firefox? Although I use it as my default browser, it is still far from mass adoption. The fact that they beg users to switch to Firefox* say it all: https://news.ycombinator.com/item?id=38806270
But the key difference is that it's leagues better than other browser engines on quality. From the perspective of competition this isn't great, but the network effects are hard to ignore. Firefox and Safari (webkit) just tend not to work as well.
It's very different in terms of quality though. Internet Explorer was a terrible browser and often lagging in implementing standards. The better comparison would be Safari now, which often completely breaks many sites on mobile for me. It also doesn't eliminate a lot of newer CSS animations properly.
This is really very unfortunate because it's good to have competition in browser implementations. Everything is Chrome under the hood now except for Safari and Firefox.
Internet Explorer was an attempt to monopolize and control the early internet. They intentionally left standards unimplemented or just implemented their own insane version of them in order to trap people into the platform.
It's no wonder the product saw them taken to court over antitrust violations.
Safari. I assumed this was overblown until I had the rich experience of developing a Flutter app that needed to work on every platform. Somehow, even Androids chaos is notably better to work with.
I'm not sure which product(s) you're referring to.
Apple has like 6 apps in the Play Store and one of them is for helping Android users migrate to iOS. On the other hand, Google has dozens of apps in the App Store.
And Flutter Web not working on iOS doesn't even help Google. If anything it just hurts Flutter's adoption on the web which is already low. So I don't think there is some grand conspiracy within Google to take out Safari by withholding Flutter support.
They sort of gave up halfway through lazily invoking the NPC bog-standard Google-on-iOS complaint: you need to pay for YouTube Premium to watch videos picture in picture over other apps.
(source: iOS dev turned Googler turned ex-Googler, so I soak in everyone's grudge matches :) )
I think it might be worse. Google has lied about Chrome and privacy so much that you can just assume it phones everything back to Alphabet even if you set it not to.
There's more to it than that alone, if you run psExplorer you'll find there's Edge the browser and Edge the subterranean process that's hooked into desktop search and general user activity while constantly engaged in telemetry.
Sure, these are "just Chrome" components and libraries .. but they're engaged in more than simple web page rendering.
NB: I'm not engaging in Edge is Evil conspiracy here and there are "reasons" for what's going on there that some may or may not accept. Just pointing out the additional below the surface integration.
As a Firefox mainliner for 'legacy' reasons to be fair, I often have to revert to Chrome to get sites to work. I guess there are a lott of dev shops out there that just test on Chrome/Edge (and maybe Safari)
The craziest is its permissive same origin policy compared to Chrome/Safari, like how `window.top.location.href = 'https://example.com';` works from inside a cross origin iframe to redirect the parent.
Depreciating old "features" like supporting legacy OS versions which is infuriating. Firefox is an inadequate substitute because too many sites only work in Chrome.
I blame lazy developers for this mess all around, which had caused a perfect storm of shit on the nouveau web.
Maybe in the future in lieu of additional testing, the development team should just check in with you, and if you declare it sunshine and rainbows, ship it.
As a person on a front-end development team that has a “Chrome = success” mandate, it’s not always our decision as to when something ships or for which platforms we are to target. We work on Chrome first and then hope for the time to get things to work elsewhere.
The degree to which Google leadership is capable of fostering innovation of any sort is very much in doubt, but specifically in chrome all they are doing is re-arranging the deck chairs on the titanic while regulators and user preferences tighten the noose on the ad tracking business.
Google is using Chrome and Android to delay privacy rights around the world, that’s it. That’s the whole story.
every time i get a new work machine i attempt to use a browser that is not chrome. last time was firefox, this time was safari. eventually i start using chrome on certain sites because of ublock origin. then, as was the case with aws, certain websites are flakey enough times that i just give in and use chrome full time.
side note: hey aws, why is your rds performance insights dashboard broken on safari? 33% of the time it will "freeze" and i have to reload the page. very un-dude like.
It's a bad thing because Google's monopoly gives them enormous power to influence browser standards, while also having conflicts of interest re: their advertising business.
See for example their recent war against ad blocker extensions.
So then why does Microsoft try to push it so hard on users who are trying to use Chrome? It's hard to believe they're just trying to save everyone the minimal time and effort that's being spent installing a different browser by randomly deciding to force a full-screen ad on an OS update. At absolute best, it's benign but worth not using simply to avoid rewarding whatever misguided incentives lead to them to "market" it like this.
The Edge browser engine is just Chromium. But the Edge browser has loads of telemetry active. Microsoft wants you to use Edge because the telemetry makes them money, rendering websites doesn't really make them money.
We’ll never see a reasonable competitor unless someone like Musk, Zuckerberg, or Bezos gets involved. But that’s not feasible because their companies aren’t internet ad agencies.
No not even close by every single possible measure.
I was there, I suffered through it, Google would have to make TONS of hostile moves for that fact to change.
I have no interest in the arguments of a closed source subscription service that wants me to switch to the bundled browser of the wealthiest company on earth's most popular consumer OS, lecturing me about using the 4th wealthiest company on earth's browser that I freely installed.
The most important one from an anti-trust perspective, every device I've ever had Chrome on I've had to seek out and install/make default Chrome, that includes my mobile devices which used the manufactures browser by default.
If I want to use chromium I can, Safari has been VERY late in implementing certain industry spec standards (SSE's, web sockets, IndexedDB API, animations, relative color syntax, container queries, a bunch of <video> stuff, flexbox, the list goes on and on.)
Safari hasn't actually been particular far behind implementing industry standards. As far as I can tell, it's more that people seem to believe that Google dictates industry standards and base everything on when Chrome supports it as opposed to when it actually gets standardized.
SSE's
W3C draft standard in 2012. Supported in Safari in 2010.
web sockets
This one is true. IETF standard 2011. Supported fully in Safari 2013.
IndexedDB API
W3C recommended standard in 2015. Supported in Safari in 2014.
animations
If we're talking the Web Animations API, it hasn't been standardized yet (W3C working draft) and level 2 isn't even that far.
relative color syntax
Not standardized yet. It's currently a W3C working draft.
container queries
Not standardized yet. It's currently a W3C working draft.
a bunch of <video> stuff
Need specifics.
flexbox
W3C candidate recommendation 2018. Supported in Safari 2013.
This is very misleading, compare implementation timelines between browsers and you'll see that Safari has implemented many of these things year(s) after chromium, firefox and even opera. This of course was because they have tried as much as possible to push people to closed source/walled garden apps.
I still don’t understand what you’re trying to say about Safari. After reading the response (outlining draft vs support dates) to your initial comment it seems like the reality is that your primary complaints dont make much sense. Maybe there are some other features that they were late to start supporting. Seems more like other browsers jumped on new features before they were standardized, and maybe that is at the heart of your original complaint? Safari taking “too long” to support things that dont have a standard?
It *is* misleading because Apple saying that Safari supports a feature doesn't actually mean that the feature in question actually works.
Rather than go through every single point (because I don't have all day), I'll just pick one:
> IndexedDB API
> W3C recommended standard in 2015. Supported in Safari in 2014.
No.
It didn't work in 2014, it wasn't working until 2016. (see: https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26)
So what? It was recommended in 2015 and was working in 2016, what's the big deal?
The big deal is that if you tried to see if you could use it at all, you would get false information:
```js
function indexedDBOk() {
}```
This returned true on Safari, all of the functions did, and a bunch of them looked like they worked too, until they completely bugged out.
So we couldn't use them until it was fixed, *and* because you can't reliably use features until the last two major versions of a browser support those feature and because Safari releases updates locked to OS updates, that means that it wasn't what most would consider "supported" until nearly 2018.
That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.
So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
And instead of improving your project, you have to either try to retrofit the base storage layer of your app, or build a new product based on a different tech. That's assuming you were lucky enough to have the runway to continue and not just have your project fail.
They weren't just late, they lied and those lies harmed developers.
> So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
You spent 6 months developing against an unstandardised technology on a platform with well documented compatibility complexities, and you didn’t test it on one of your larger target devices?
I think that’s on you, friend.
You'd think so.
And so you'd purchase a new iOS device for ~$1000 and test against it.
Then you realise that you're getting bugs from some customers that you literally cannot replicate on your device.
Then you realise that the bugs are type of device independent, so you need to purchase one of every kind of device apple offers for ~$10,000 and test against those.
Then you realise that the bugs aren't just type of device independent, they're actually dependent on a combination of OS version AND type of device.
So you spend another ~$10,000 for a second copy of each device, and set them up to never auto update.
But now you need to wait 12 months for the next iOS update so you can test the current and the previous version, but waiting 12 months won't do.
So you want to rollback iOS versions, but Apple doesn't let you do that.
But they do let you simulate combinations of iOS devices and versions through xcode. So you buy a macOS device and you're out another $5,000 and spend time simulating, but then you realise that the simulations don't actually replicate the device bugs, they're just running sandboxed versions of desktop Safari on the host machine that are scaled down and streamed into the simulated device. And so we've learnt a $5000 lesson on the difference between simulation and emulation.
So here you are, out ~$25,000 and dealing with customer complaints and troubleshooting, the you find something unexpected... You find a customer with a combination of type of device and OS version that you have, and you can't replicate the issue.
So it's not just type of device plus OS version dependent bugs. The bugs are independent to the devices themselves. Yes, really!
So what do you do at that point?
You have no way to reliably test if a feature works, the only thing you can do is take Apple at their word and recommend to customers that they can still access your product through other platforms (Android, macOS, Windows) and just put up with the angry complaints and reviews from iPhone customers that you can't help.
--------
The above comes from personal hands-on experience.
We have purchased multiple of the same device on the same day from the same shop with the same OS on factory settings and have witnessed different behaviours.
Reporting issues to Apple is useless, their responses are absent at best, and hostile at worst.
> That feature that every other browser had working since 2012 wasn't "working" until almost 2018, for Safari, and worse than that 6 year difference, they lied about it working.
Chrome, Firefox and IE had buggy implementations in 2012. Firefox didn't support IndexedDB from worker threads and would corrupt data. Chrome couldn't write blobs and would corrupt data.
Safari certainly required more workarounds due to more bugs than anyone, but the truth is that the IndexedDB standard sucks. For goodness sake, there's still no standard for locking to prevent corruption between two tabs (while everyone supports the Web Locking API now, it's not actually a standard).
We would have all been better off if we tossed it and replaced it with WebSQL.
> because you can't reliably use features until the last two major versions of a browser support those feature
Maybe a bit of a nitpick but this particular comparison is exactly the same with any other browser.
Sure, Safari is locked to iOS version, but iOS adoption rates are insanely fast, about as fast as browser updates. We are talking 90% current major version adoption within 5 months. Here's a source with some historical info: https://worldmetrics.org/ios-version-statistics/
So really, at worse you're looking at being one year behind to cover 95%+ marketshare in iOS.
The latest version of Safari runs on the two previous versions of macOS, so it's even less of a problem on macOS.
> So you could spend 6 months working on a project, release your product, then get inundated with bad reviews because it didn't work for half the population with iPhones.
That could happen to you if you don't test your software on popular platforms.
Let's not forget, Safari and Chrome have the exact same open source core with proprietary commercial applciation development model. Safari has about 1/4 of the user base as Chrome. But here we are expecting the open source community around Webkit to fix bugs just as fast as Chrome?
You could have fixed the indexDB bug yourself if you wanted to. I would say that what you are framing as "Apple lying" about capabilities can be more generously interpreted as "Apple has 1/4 of the community developer resources to find and squash bugs in Webkit compared to Chromium." Really, it's far less less considering that essentially every other browser besides Mozilla uses the Chromium engine. Microsoft is of course another huge company also contributing to Chromium, and once you put Google and Microsoft together Apple doesn't look like such a behemoth anymore. The only thing that makes Apple "bigger" is the fact that they sell a lot of high margin hardware. In reality, the software businesses at Google and Microsoft are far larger and more complex than Apple (e.g., Apple has no enterprise cloud computing business, and essentially no enterprise software business at all).
Apple purposefully does not support immersive WebXR in Mobile Safari. If it did 8th Wall wouldn't exist.
Mobile Safari would regularly break WASM. Like iOS 10.1 and 10.2 just broke it for no good reason. It had a broken WebGL 2 implementation for a long time. This hobbled Unity games.
The compressed textures support for WebGL was also broken for a long time.
The lowest latency WebRTC codecs that Stadia and Xbox Cloud Gaming used were also purposefully not enabled by default. Google had to smuggle in an obscure WebRTC feature for low latency via libwebrtc that Apple just didn't know about.
I have no idea why you guys are going out and defending this stuff. Android Chrome has much better support for web standards that Mobile Safari does, even in situations where the codebase was shared like libwebrtc, because of strategic Apple decisions.
I wouldn't say I'm defending Apple so much as I'm defending the idea that it might not just be making these technical decisions/iterations entirely based on the most cynical possible interpretation of the situation.
For all we know WebXR immersive just isn't ready yet, just like WebXR wasn't ready for VisionOS 1 and shipped in VisionOS 2, which also makes sense considering that Apple's VR/AR business is years behind its competitors.
Broken stuff can just be bugs and regressions.
And I think it's also contextual to point out that Google really badly needs you to prefer Chrome and have the browser with the most features a lot more than Apple needs Safari to be anything more than a functional basic web browser. Examples like Stadia or even Unity in the web browser are essentially features that nobody asked for and that have worked better as native applications for decades. In other words, Google depends on the web browser being "the only application" as much as Apple depends on their users turning to the App Store first.
I totally get where Apple has a vested interest in boxing out competitors in the way you describe, but at the same time some of the complaints end up sounding a lot like bugs or just being generally behind in development velocity.
It was all on purpose. Maybe they haven’t been sued and discovery hasn’t turned up the specific email needed to convince you.
I'd argue calling non-standard chrome/firefox/opera features "standards" is misleading.
This is plain bad faith. If you know anything about web standards, you already know the W3C process requires candidate implementations and interoperability before a standard reaches its later stages. Other browsers implemented the standards earlier because they participated in that process; calling those implementations "non-standard chrome/etc features" is absurd.
Later stages? These features often get implemented at the working draft stage - a stage where major changes can still happen, it has no consensus or even wide review.
Google implementing a draft they themselves authored with minimal review doesn't make it standard just because w3c publishes the draft.
When chrome/firefox/opera all implement a working draft and demonstrate interoperability, they are participating in the standards process. Trying to make it sound like they're doing something non-standard when they do that is simply dishonest.
+1, and I'd argue that calling non-standard chrome features "standards" is what makes it the new IE.
Safari use open sourced webkit, just like Chrome use open sourced chromium.
As usual, there's supported and "supported" with Safari, nobody could build an IndexedDB app in 2014 supporting Safari, I've been there. It's only been really stable through the past 3 to 5 years max.
I feel like you’re putting the cart before the horse there. The W3C takes existing implementations into account before issuing a recommendation.
It definitely is, I was also there, just like everyone was doing IE only sites, not only plenty of people do the same with ChromeOS vision of the Web, they ship Chrome alongside Electron crap.
Safari is the last man standing before a ChromeOS world.
Safari is the last man standing before a ChromeOS world.
Except it isn't. Maybe I'm being slightly obtuse here, but the world is not "Chrome Vs Safari". It's "Chrome Vs Safari Vs native apps". If Safari dies we'll be in a world of "Chrome Vs native apps", and that is what Apple wants. Browsers represent a way to deliver software to users that's outside of Apple's revenue mechanisms.
Apple have every incentive to keep Safari being good-not-great at running web apps, so users prefer the native version (even though most of the time that'll be Electron.)
Am I the only one left happily using Firefox? You know, the only "major" browser that doesn't seem to have these conflicts of interest?
Also happy Firefox user here. Do not worry, there are dozens of us. Dozens!
It's always nice to meet a fellow neverChrome.
The Firefox that gets the vast majority of its revenue from Google, that Firefox?
I think the only full-featured browser with a prosocial funding model is Konqueror, where what little money there is mostly comes from EU grants. Not coincidental that its code quality was so much better that everyone else based on its rendering engine.
Konqueror no longer uses its unique KHTML engine and has switched to working on top of WebKit/Safari, making it just a wrapper, similar to Brave. It’s a pity that the last truly independent player in the browser engine market is gone, but such are the realities.
Konqueror is underfunded and can't catch up with the standards
and until recently, the only browser that allows to split the view into independent sub-windows..
wait how'd you do this
It's in the right click menu, or there's a key command for it.
I use Firefox Mobile but have long abandoned the desktop offering. The only thing I feel like I get from the desktop version lately is a spiritual victory whereas the mobile browser actually has tangible features I prefer like add-ons and the search bar at the bottom.
On iOS it’s still safari backend though?
Yes.
Being the only Android browser (that I know of) that support extensions, namely UBlock Origin, means that Firefox is the only logical choice for me.
Chrome's Manifest v3 forcing UBO into becoming UBO Lite only strengthen my original decision.
Hopefully this move by google would push more people toward Firefox. Although considering the amount of people who happily surf the web with zero adblockers (including every single of my IT colleagues), I'm not holding my breathe.
Kiwi browser (chromium fork) on android supports extensions from the chrome store. Not that it'll help for much longer.
Another happy Firefox user. On desktop and mobile. I always have used Netscape/Firefox.
Notably this desire -- to own a platform by making "native" code for your proprietary OS the "preferred" way to interact with the world -- was exactly the logic behind MS's "embrace and extend" nonsense in the 90's. It still feels weird to me that people don't react the same way when Apple does it.
They don't. Apple gets away with stuff today that would have made Bill Gates blush in 1998.
Imagine if Microsoft was able to just ban any competing browser from running on Windows. We wouldn't be here debating if Chrome is the new IE. IE would be the same old IE (and the web would be a lot worse off today).
Native apps have always been better than browser/cloud based solutions. The only people who prefer the cloud are lazy developers, tech companies who want to sell software as a subscription, and corporate IT who finds it easier than dealing with native software on the computers.
The end user is always served better by native apps.
Mostly I agree with you but sharing URL’s to resources is vastly better on the web. So is distributing updates.
Chrome won't die when it already owns 80% of the browser market.
And if it is bluntness that you want, native apps should wipe both of them, lets get back to the days of Internet protocols and leave browsers for documents, nothing else.
How many Regular Joe people are using progressive web apps in the first place? I think Android users also prefer apps over websites and PWAs anyway. I would guess that if I took a poll of all my real life not-technology friends that zero of them use a PWA, know what it is, or even have one installed by accident.
I think that this idea that Apple is making Safari deliberately shitty to stop PWAs from taking over may have been true at some point, but I think by now that battle has been lost and Apple doesn't have to defend that moat anymore. There's just a plain reality of installing native apps being a better user experience regardless of platform, even though it is more locked down and has its own significant list of disadvantages.
More recently, I have difficulty seeing what's so bad about Safari in this regard. It lets you add web apps to your home screen and works with notifications since iOS 16. Safari has features like picture-in-picture that the native YouTube app doesn't have. It also has extensions. Maybe there are some PWA features that I don't know about here that I'm missing?
Maybe this is my dumbest opinion: say what you want about Electron, every Electron app I've used has been a better experience installed as a native app than used inside a browser. Not much better, but better enough that I didn't want to keep using them in the browser (regardless of choice of browser). Slack comes to mind. I greatly dislike using Slack in a browser, and it's hard to point my finger on exactly why that is.
> How many Regular Joe people are using progressive web apps in the first place?
I know several of them, because Google doesn’t let e-commerce apps in my country sell cigarettes and other products containing tobacco. The android version of these apps guide users into installing their PWA version if they wish to order such products.
Of course e-commerce doesn’t really need app-like features at all and works fine on the plain web.
Considering Safari is mainly used on a platform where it's mandatory, I'm not sure "standing" is the term.
Last man being propped up Weekend-at-Bernie's style?
It is, without iOS and related Safari, anyone doing Web can update their CV as ChromeOS Developer.
It’s not really mandatory, you can use other browsers on both iOS and macOS
Except you can't. Every browser on iOS uses Safari's rendering engine. Chrome/Firefox on iOS are effectively reskinned Safari. This is an apple requirement. The rendering engine being the important part here when talking about standards and such.
> effectively reskinned Safari
It's worse than that, even - IIRC the renderer that other browsers have to use is slower and more limited than the one Safari uses.
So other browsers are effectively reskinned hobbled Safari.
A rendering engine is not a browser. Are all the Chrome engine variants really just Chrome in a skin? I don’t think so they all have unique properties that set them apart. As do Orion, Firefox, brave, etc on iOS
Every time this discussion happens a non-trivial number of people reveal they’ve fallen into this trap of believing other browsers are allowed on iOS. Feels like a consumer protection issue, at some level.
The only browser that seems to be able to get around this is Orion. No idea how they are doing it.
Orion is WebKit. Safari’s rendering engine is WebKit.
I tried Orion (m1 MBP) recently. From about 3wks ago til a few days ago. I liked the UI. But there were a lot of pages that didn’t work correctly. I persevered for a while. But gave up a few days ago and went back to Brave.
I know it’s WebKit. But they are somehow allowing extensions, which none of the other iOS browsers has managed afaik.
Likely just emulating/providing the javascript interfaces needed for FF and Chrome extensions to run.
When there is will, there is way!
Safari is mandatory to have on iOS - it's preinstalled and can't be removed. It's also propped up in the sense of being built on apis and OS features that other browsers aren't allowed to use.
I mean, imagine if DOJ forced Apple to divest Safari and treat it the same as other browsers. What would happen? Parsimonious answer: the same thing that happened everywhere else.
Another piece of evidence is Google tries at nearly every turn to help people write portable code, use best practices like feature detection instead of browser version sniffing, etc... They run https://web.dev/ and the founded baseline https://web.dev/baseline and the web platform dashboard https://web.dev/blog/web-platform-dashboard
MS in their IE days did the exact opposite, trying to make as many proprietary IE only features as possible.
Regardless of all of that, monocultures are bad.
Monocultures that allow for one company to make it hard to avoid advertising and data tracking on the web are even worse.
Just because Chrome implements a feature and then rams it through a W3C committee does not make it a “standard” that Apple must support on day 1. The arrogance of the Chrome crowd is astonishing.
I think some of the complaints in the article were about websites using User Agent string to detect compatibility, rather than individual feature sniffing.
In that small complaint, I would agree. But I think the fault is mostly with the website owners, not with the browser.
> rather than individual feature sniffing
Feature sniffing generally doesn't work for anything interactive. Many bugs in controls, animation, events are not sniffable. Yet developers still need to deliver workarounds.
Feature sniffing works best for static HTML documents - and even then the code to actually do the sniffing can be demonic code (a side-effect or correlation or an obscure discovery).
Using just feature sniffing is a great goal but it simply isn't a perfect solution. I do believe us developers should avoid parsing user agents unless there is no other good solution (never a crutch for lazy bad developers).
And detecting the browser for obsolete browsers is usually a perfectly fine solution. The bugs won't get fixed and the browser won't change. There are exceptions of course!!!
> And detecting the browser for obsolete browsers is usually a perfectly fine solution.
But there are a long tail of user agents and the average web developer does a terrible job at identifying those in the long tail. My password manager on iOS uses the newest Safari engine, but all websites think it is an outdated/obsolete browser because it uses a user agent string they don't recognize.
Also, my bank doesn’t use highly interactive features you mention. It’s almost exclusively links, forms and a little validation JavaScript. Feature sniffing would have been a much better experience.
> Google would have to make TONS of hostile moves for that fact to change
I think the biggest issue with IE6 was not the hostile moves Microosft did, it is that it didn't do anything. The browser was just frozen. That's why it was relatively easy for Firefox to take a marketshare.
Frankly, with some of the APIs Google are adding to Chrome, I'd rather they'd do a little less.
So, no, the problem with IE was 100% Microsoft's hostile competition tactics. Yes, part of that was trying to deprecate the "world wide web" as a platform, so yes, IE6 got very crufty toward the end of its days.
But by that point it was clear it was already dying and IE7 et. al. were introduced late as an attempt to catch up. During the period when the real bullets were flying, IE6 was actually a really great browser, just one that forced you into using a menu of Microsoft technologies because it didn't support the "standard" stuff. Remember that XMLHttpRequest, the basic tool underneath all modern dynamic web UIs, was originally a non-standard Microsoft invention.
And yes: eventually this proved unsustainable and innovation in the standards-based browser world eventually proved too fast for MS to keep up, and it lost.
But the tool that broke the back of that monopoly absolutely wasn't Firefox. It was Chrome.
I would say that the 30% market-share Firefox had in 2009 was breaking the monopoly much more than the 3% Chrome had a time.
Sure IE6 had many non-standard APIs, but even the fact that all hobbyist browsers back then were implementing tabs and IE6 never had that, speaks to its stagnant development. To be honest I'd prefer some things Google is now pushing through th W3C as standards to be left as Chrome specific APIs and leave the rest of us alone.
That and browser sniffing to serve intentionally broken CSS on Microsoft's websites to competitors like Opera, I remember this because it directly effected me at the time.
I mean at least we still have websites like this from over 20 years ago that still document the bullshit, people who weren't there CANNOT fathom the how despicable they were.
https://www.wiumlie.no/2003/2/msn/
Google is quite similar. Here's former CEO of Mozilla talking about it: https://archive.is/2019.04.15-165942/https://twitter.com/joh...
Safari was late until a couple of years ago when they started implementing new features more aggressively. Now it's always Firefox. Just check how long it took them to add support for the :has() selector and RegEx Lookbehind. We're years into "manifest v3" and background workers are nowhere to be found.
Funnily enough it was Firefox who figured out a workable algorithm for :has IIRC
Absolutely not.
Firefox has mindbogglingly bad performance with :has() even if their superficial tests tell you otherwise. I experienced minute-long lockups just because I used :has() on a large element like body. Chrome and Safari had no issues with those selectors.
I stand corrected. It was the absolute legends at Igalia. See links and explainer here: https://github.com/mozilla/standards-positions/issues/528
Of course it is. None of that is relevant, my younger coworkers only qa in Chrome so it’s IE 5.5 all over again.
The audience for computers in 2024 has grown to maybe 1,000x what it was in 2008. Everyone has to rediscover the meaning of being able to choose.
https://www.statista.com/statistics/273018/number-of-interne... maybe 3.7x
Yeah no way it’s 1000x lol
Can you actually now? Or is Chromium still webkit under the hood because Apple?
> using the 4th wealthiest company on earth's browser that I freely installed.
99% of the time I use Chrome it's because some site does not support Firefox (and that often includes Google sites/apps). (The 1% are for APIs that Firefox, consciously or out of resource constraints, does not support.)
In what sense am I "freely installing" Chrome in this situation?
Just today I had a family member reach out to me, unable to use government e-signing on their phone after I'd switched their default browser to Firefox (they were getting tons of ads in mobile Chrome, which does not support plugins and accordingly also no ad blockers). Turns out they support only IE/Edge, Safari, and of course Chrome...
> every device I've ever had Chrome on I've had to seek out and install/make default Chrome
My Pixel came with Chrome preinstalled, as far as I remember. (I don't recall if there was a browser selection screen.)
Sure, that's a Google phone, but then again Windows is a Microsoft operating system.
> the arguments of a closed source subscription service that wants me to switch to the bundled browser of the wealthiest company on earth's most popular consumer OS
Oh, I'd also not advise anyone to switch to Safari. Apple absolutely would pull exactly the same or worse as Google if they could, I have no illusions about that.
I can't wait for the day they're finally forced to actually allow alternative browser engines on iOS and switch to Firefox everywhere.
I see this argument a lot. I use Firefox on my Mac, iPhone and my Windows work PC. I can’t remember the last time there was a website that was broken because of Firefox.
Do you happen to have any examples? I’m curious to see how broken/what the issues are.
Not who you are replying to, but before I switched to Vivaldi (a Chromium fork), I saw lots.
Among them: Logging into some of my financial accounts doesn't work on Firefox. Enterprise software and gear like VMware and management UIs of various devices on the network. (They foolishly hard-coded their devices to reject any UserAgent strings that weren't Chrome, IE, or Edge.) Sites that use some kind of poorly-implemented tracking/fingerprinting to make sure you're a human. (I would routinely get stuck in infinite CAPCHA loops even on normal sites.) For a while, Slack video/audio calls did not work on Firefox because Slack chose to use codecs that FF didn't support. Video calls on FF are still hit-and-miss on various platforms, ran into it on Facebook just the other day.
These are all just off the top of my head, of course. There are plenty more that I've forgotten.
I don't use Firefox currently but I did for a couple years recently. For a while Teams was blocked and/or broken in Firefox due to calling features Firefox didn't have at the time.
A few sites would silently break, e.g. restaurant online order pages, but work in Chrome. Never really looked into why, it was just annoying and intermittent (might work one month but not the next).
YouTube occasionally had some issues. For a while it was on an old version of Polymer that used Shadow DOM V0 (experimental) instead of V1.
A good list is here https://webcompat.com/issues?page=1&per_page=100&state=open&... keep in mind some of these are "is extremely slow in Firefox". Sometimes that's just that Firefox didn't have the same set of optimizations (not necessarily even fewer optimizations, just not ones built against) and other times that's deeper seated like the Shaw DOM V0 example where the fallback for the page was to use some older.
I use chromium for office365, including teams. Lots of little annoying bugs with firefox (which I use for every single other website on the web).
I don't understand this because I have used Firefox exclusively since it first came out and never run into broken sites. What exactly are these exotic sites you are visiting that break in Firefox? You mentioned an elusive government website but I have used many (IRS, SSA, Edu, etc...)
>What exactly are these exotic sites you are visiting that break in Firefox?
In my case, an example of a non-exotic site is Youtube streaming 4k 60fps videos. I tried with latest Firefox a few months ago and it was still stuttering and glitchy. But Chrome plays smoothly with no issues. I previously mentioned that 4k playback has been a long-standing issue: https://news.ycombinator.com/item?id=28783904
On one hand, my computer is fairly old ... but then again, Chrome works fine on that same old hardware.
Never seen this; however, youtube prefers pushing VP9 over H.264. Maybe your computer cannot use hardware decode for VP9 and can for H.264? (Since you mentioned, it is an older one). Maybe the h264ify extension would help.
What firefox cannot do and chrome can is HDR playback.
> however, youtube prefers pushing VP9 over H.264. Maybe your computer cannot use hardware decode for VP9 and can for H.264?
No, even if I download the 4k 60fps file using yt-dlp with forced h264 codec settings locally to my harddrive, Firefox still can't play the mp4 file smoothly.
So it's not really a streaming issue or h264 vs VP9 codec issue. The Firefox core engine doesn't seem optimized to playback 4k and 8k high-frame-rate videos with low cpu utilization. Even VLC for 4k and 8k isn't as smooth as Chrome. I don't know what the Chrome team did but they really optimized that code path to play back hi-res videos.
Interesting, I recently had the opposite experience. Wanted to enable hw decode on an older Intel system and only got it to work on Firefox. Tried several different instructions from the web on how to force chrome to ignore any blacklists for drivers or anything, but still no luck.
Oh and a while ago I noticed (on a more modern system) that enabling hw decode makes chrome ignore the aspect ratio of the video and displays it like the pixels are square. Again Firefox handled it fine.
(Linux, h264 in both cases)
YouTube is routinely broken for Firefox, especially when navigating around in places like shorts. I actually find this to be a feature because it prevents me from continuing to mindlessly consume. But it is broken.
Elusive to you, essential to people living in my country. (You can't do your taxes without it.)
And look no further than Google themselves: https://labs.google.com/search/install
Maybe that explains it, I don't use Google search at all. I do use gmail/youtube however.
That's a very arrogant attitude.
I'll give you one example: I sometimes can't open OpenAI API documentation due to some stupid Cloudflare captcha checks. No, on Firefox, however many times I click that checkbox, I can't go through the verification, just to read some static content. Not even if I disable adblock and tracking protection.
I don't even see a checkbox at all on Chrome or Edge.
Cloudflare captchas are an excellent point.
Sure, technically nobody is excluded: Just solve the captcha! Fraud heuristics are only reasonable, right?
But it's all fun only as long as your situation occurs within the 90th or 95th percentile of all data labeled "good customer". Good luck if you're out side of that...
But thats not Chrome's fault.
I mostly use Chrome on Linux (fully Google distributed, closed source Chrome...so not Chromium) and I see those cloudflare captchas at a much higher rate than I do when using Windows or macOS.
This is also my experience. But to be fair I have a heavily modified privacy-centric Firefox, and I disabled some features in the config, and I disable js and large images and of course tracking/ads by default, and I delete most cookies on browser close, and I run Wayland on Linux so... any breakage is probably on me.
I almost always find that when sites do not work with Firefox (also Wayland on Linux) it works with Firefox (on the same machine) without the same plugins and settings.
Enabling JS is not enough, so I think its liked to privacy plugins, or running inside a container.
the cynic would say if you can't be tracked, you can't be monetized. unfortunately, being successfully un-de-anonymizable means you can't be distinguished from a bot.
The likely reason why they don't support Firefox is because it has less than 5% marketshare. It isn't a Chrome only site. You said that they support Chrome, IE, Edge (if they support IE then I'd assume that they might also support pre-Chromium Edge), and Safari.
That is just the nature of using a niche platform. I primarily use Linux on the desktop. I have to keep a Windows install around for the times that I need to do something that can't be done on Linux. Resources are limited and so high marketshare platforms are prioritized. That's just how it is.
The onus is on the app developer to make sure their app runs on a variety of platforms. It's not Chrome's fault for third party developers being lazy and not supporting Firefox.
>It's not Chrome's fault for third party developers being lazy and not supporting Firefox.
What if it's Google themselves? From my original post:
> [...] and that often includes Google sites/apps
[Citation Needed]
What google site or service requires Chrome?
I don't know of anything that is completely broken, but some functionality requiers chrome:
On Google Docs, paste as markdown, copy and paste from menus, paste without formatting, etc. only works on chrome. This functionality could be done with standard APIs, but instead google uses a hidden, pre-installed extension to implement it.
Offline mode doesn't work on firefox for either gmail or google docs.
Google doodles don't show up on Firefox Mobile, unless you spoof a chrome user agent.
Youtube has repeatedly had serious performance problems on Firefox.
"AI overview" (which I happen to find really useful) was only available on Chrome and Safari for at least a few months.
Sure, it's a lab experiment or whatever, but these are just words, and the effect is that I have to use a different browser to be able to use them, for absolutely no technical reason. (The LLM is running on Google's servers and provides plaintext. I think Firefox could handle that.)
Just visit this on Firefox if you want to see for yourself, including a big "install Chrome" call to action: https://labs.google.com/search/install
Doesn't really support your statement then.
Meet is as shitty on Safari as Google feels they can get away with
There are less options for screen sharing on Google Meet.
Are you objecting to single sign on or something? Or some browser extension that is only published for Chrome? What are you talking about?
Some Google sites explicitly say "install Chrome to use this", e.g. this one: https://labs.google.com/search/install
As an example of how perfidious some of the discussions on web standards are, on Wikipedia:
https://en.wikipedia.org/wiki/Comparison_of_browser_engines
In teeny tiny font near the bottom:
"Given the market-share dominance of Blink-based browsers,[4] if Google chooses to not support a standard, like JPEG XL,[30][31] it will not become relevant on the Web.[30][31] Such standards are not listed in these tables."
So if Chrome implements something that Safari doesn't, then its a deficiency in Safari. If Safari supports something Chrome doesn't, its not relevant so will not appear in any comparison tables.
Chrome is 100% the new IE, as it is the being treated as the sole arbiter of what is a web standard or not.
You can see it here, too. And in all discussions around PWAs. And on sites like whatcanwebdotoday. Anything Chrome ships is considered crucial, critical, and standard. And other browsers are shit because they don't immediately implement everything Chrome implements
Time to break up chrome.
Yes.
If it works on Chrome, no one cares or even tests for other things.
If there is a JS feature in Chrome they want to use, so it’s impossible to use other browsers (instead of looking wrong) people do it.
Performs fine in Chrome? Ship it.
Yes, Chrome is the new IE in that it’s the only browsers companies care about, just like IE was for a very long time.
Everything has to be Chrome compatible to succeed. That’s the benchmark, not what the spec says.
I manage websites for a couple of non-profits. A very high percentage of traffic is from Safari (mostly on iOS) -- 40% on one site. Only testing in Chrome seems like a bad idea.
It really depends on where in the world we're talking about. iOS is big in some places (like US) but insignificant in others.
It also depends on the kind of site. The more the operator thinks you should be using a desktop, the worse it is.
Yeah one non-profit is a place that people physically so I imagine a lot of people look at it on their cell phone. We have over half of our visitors on mobile.
iOS is important in all rich countries, and if you want to address wealthy people in developing markets. It is very important for these reasons.
In Europe Safari has decent 21%. Thus I would not neglect Apples web browser but calling it very important is going a step to far in my opinion.
One in five is not enough to be very important? I disagree.
people with money tend to use Safari
No, I dont think this is the case. While a lot of devs use Chrome while developing, we're all well aware that 50% or more of US users are using an iPhone. And that's Safari no matter what. So many do a ton of testing there as well. Firefox often gets the shaft.
I know as a matter of fact that many teams'/companys' approach is "We'll develop and run our CI tests on Chrome only. If it breaks on Firefox or Safari, we'll fix it, but that's as much as what we care about." And I'll be honest, for many organizations, it's a good business and financial move.
> If it works on Chrome, no one cares or even tests for other things.
We've been through an extensive standardization pass for this to not happen. Anything not matching the specification whether in Chrome or any other browser should be considered a bug.
This is not at all the same as IE, where it just went its own way.
The unstated major premise of this assertion is that the standard is a spec that every browser must comply with exactly. It's not; there's not a single browser that has ever implemented 100% of whatever was the latest standard at the time, and major browsers typically also include many of their own additions that go beyond the standard.
This latter bit isn't in conflict with the standard; it's an essential part of the standardization process. The typical route for something making it into the standard is for a browser to release their own browser-specific extension and use that as a basis for advocating that it be added to the standard. XMLHttpRequest, for example, started as an IE-only feature and didn't make it into all the other major browsers for several years. It got a published W3C spec a little bit after that, which meant that browsers needed another couple years to also get synced up on their behavior.
In this respect, Chrome has definitely now taken IE's old position: new Web standards have a tendency to start as Chrome-specific extensions, and then the other browsers have to implement their own versions and get them ratified into the W3C specs in an effort to try and keep up. Which in turn suggests that a compatibility-minded Web developer might want to choose a similar strategy from what was done in the past: test on the most popular browser last.
> The unstated major premise of this assertion is that the standard is a spec that every browser must comply with exactly. It's not; there's not a single browser that has ever implemented 100% of whatever was the latest standard at the time, and major browsers typically also include many of their own additions that go beyond the standard.
Sure, but there is a big difference between implenting 99% of the standard and only implementing like 10%
It makes a difference in how easy it is to get it working in multiple browsers.
But if developers don't check, then either one could break the site for all the users.
As I wrote in a similar thread a year ago: Whenever I point out that some bug which happens in Firefox my colleagues usually responds with some variant of "we tested in Chrome, and that is the standard", or "can you ask the customer to use Chrome instead". Even if Firefox or some other browser may be using a proper standards implementation and the Chrome one being the one with some quirk.
> should be considered a bug
Should be, but isn't. At least not in a practical sense.
What about half-assed specifications that Chrome throws over the wall, ships them, and advertises them as standard everywhere, including web.dev? Even though their status is "not on any standards track"?
ChromeOS and Project Fungu.
Yes it should be, but it isn't, that's the problem
I do opposite. I develop and test over Firefox. If it works on Firefox, would work on anything (plus I always doing transpilation to baseline)
Unless you want to have customers on iOS.
Some websites basically force you to install the app for that.
as Apple intended.
I run into enough sites that seem to think nothing but desktops exist and tell you to just not use a phone.
Yes, Chrome is necessary for some sites that don't work on Firefox.
This isn't a chrome fault. It's lazy dev orgs. You aren't going to fix lazy dev orgs.
One issue I keep see cropping up with various corporate websites is they will only allow Chrome and will block any other browser. I would say in 9/10 cases, this isn't because the site uses features not supported in other browsers but rather, developers restrict it to Chrome because that's all their QA's test on.
Absolutely. I'm still not sure what annoys me more: Sites that break on non-Chrome, or sites that won't even let me try behind a cookie agent blocker.
Which is ironic because scores of enterprise companies developed internal systems/reporting/intranets using .NET in the early 2000s, restricting their users to Internet Explorer!
And still have to maintain windows 7 or earlier machines running IE 7 to run internal applications
It's clear that Net Neutrality and web standards are close to a myth. Security-wise, I trust Google over Mozilla though.
That's a different layer of the stack. I could get behind "web neutrality" as an initiative, though!
Not even close. IE 6 didn’t get any updates or new web features for years. It was closed source. It was dead and everyone used it. float:right; zoom:1; was a common necessity… to compare them is an insult to the immense progress and effort spent over the last 24 years… (yes chrome started in 2007, but the teams from Firefox get credit too, many of them went on to build chrome ). The open source movement won, IE is dead - MS shipped edge. We can argue about how Google is evil all day but it’s night and day compared to what the web was like in 2000
Then why does it feel like standards lost?
We don't have float:right;zoom1: but our "necessities" nowadays are even crazier. Babel, vdom, frameworks provided by browser-vendors. Those are several orders of magnitude more complex than previous "workaround" approaches to the web, all unstandardized.
How about Electron? Do we see any Firefox-based desktop apps around or is that market completely dominated by the Chrome runtime? Are app developers happy having only Chromium as the viable solution? (my guess: they're not, but they have no choice).
Where we're going is even nastier than clearfixes and table layouts.
Isn't this a Firefox/Mozilla fault as well ? Afaik there is really no API or support for embedding Gecko & anyone who tries to do that, is on their own, having to periodically rebase large patch sets for embedding.
Possibly. I guess XUL was that API, but XUL is no more.
It helps if your company uses the embedded stuff in other products. Like Microsoft used the Trident engine from IE6 all over Windows components. In that way, allocating resources for developing an embeddable engine is justifiable. Can Mozilla do that? I don'know. Google can (and does it! why wouldn't they?).
There is GeckoView on Android: https://mozilla.github.io/geckoview/
On desktop, it used to be available as an ActiveX component and a GTK widget, at least: https://www-archive.mozilla.org/projects/embedding/embedding...
Wine still uses WineGecko as a replacement for IE engine – might also be worth looking into.
> There is GeckoView on Android: https://mozilla.github.io/geckoview/
But sadly on Android the alternative is simply using a Chrome/Blink-powered webview, which is capable enough for most people and importantly comes at a zero APK size hit. So you need to have pretty special needs before including a complete custom browser engine inside your app becomes an attractive proposition.
(Whereas on Windows for example for a very long time the only OS-provided browser engine was IE, so if you needed more advanced web features, you couldn't avoid shipping your own browser engine in your application anyway.)
Hmm, you’re right, I think GeckoView is “marketed” specifically for making browsers:
> However, Android’s WebView is not really intended for building browsers, and hence, many advanced Web APIs are disabled. Furthermore, it is also a moving target: different phones might have different versions of WebView, all of which your app has to support.
It might still be an okay choice for an application shell sometimes (e.g. if you use a web API that is not supported by WebView and no polyfill is readily available for Cordova/Capacitor).
Babel/vdom is not necessary for web dev. Can't blame chrome for electron.
If something uses DOM and JavaScript, to me it's web enough to be called web, even if it is rendering outside of regular browser expectations (some React Native stuff or similar). The whole premise of this tech is to approximate app development to web development.
Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.
Sheesh, the existence of libraries does not mean standards have failed.
Sometimes it does.
Would normalize.css exist if the standards were more specific around default styles?
Would jQuery/sizzle exist if CSS selectors were available as a DOM API in the first place?
Would vdom exist if DOM was faster?
VDOM would still exist if the DOM was faster. It's a different abstraction that reconciles the differences between the simple data->elements flow and the inherently stateful DOM. If you don't understand why VDOM exists, here's a nice experiment: in your next web app stop using VDOM and always set innerHTML. You'll find that (1) it's actually fast enough so you can conclude that VDOM doesn't exist just to patch over DOM slowness; (2) you are missing some features you get in VDOM.
The answer is that the DOM inherently has state. It could be a textbox's text input and its cursor state, or the focus state, or whatever. But developers don't want to think about this DOM-managed state to simplify their mental model.
Let's ask the next why. Why make the interaction with the DOM stateless?
Because walking the tree sucks, and more specifically building upon the tree sucks a lot (createElement, appendChild, etc). That's why innerHTML, which was _not_ a standard, became a standard after being widely implemented and used.
So, the solution was to almost never read the actual tree, because it is slow and weird. This was solved before React (libs like Backbone and others kept track of state).
Regarding DOM mutation, the browser goes through possibly a lot of stuff (reflow, repaint, etc) when the DOM is changed. React is designed to allow components to optimize this lifecycle. It is very easy to misuse though. You have to know the lifecycle to be able to use it effectively, so, you have to think about the state (or just be allowed to use off-the-shelf components, or be ready for unexpected pitfalls).
It seems something like VDOM could be introduced to the standard DOM API. Some kind of detached DOMDocument that is very sterile and fast. It should be faster than doing it with JS. Remember when we parsed JSON with libs written in JS? Or when CSS selectors were parsed inside jQuery? Do you notice my point?
> Remember when we parsed JSON with libs written in JS?
No, when was that? Because it was always possible to `eval(jsonString)` and get the parsed result. Indeed, that was the whole point.
It was always possible but never safe.
We're oldschool, not savages!
The open source movement has been co-opted. Its core values were laid out in a world where people owned their own computers and were custodians of their own data. There was no cloud, there was no saas, and that meant that owning source code meant you had some level of control over your digital life.
You're right. It is night and day. In 2024, access to source code is no longer, in and of itself, an effective proxy for autonomy. And using how the world worked a quarter century ago as a yardstick for measuring the relative merits of Google's influence on the digital domain nowadays is specious.
Ummm ... 2024 - 2007 = 17
Blink is a fork of WebKit, itself a fork of KHTML and KJS.
2024 - 1998 = 26
> (yes chrome started in 2007, but the teams from Firefox get credit too, many of them went on to build chrome )
When I parked a rental car in downtown SLC last week I had to find a way to pay to park. There was a kiosk with a functional screen, but the touchscreen part of it was broken, so I couldn't interact with it. I plopped my stuff down and sat on a concrete bench in the cold and dark to try to figure things out on my phone.
The QR code sent me to a website to install an app. Google Play store said the app was designed for an older version of Android and couldn't be installed on my device. I eventually found a "pay online" link hidden down the page a bit, then spent several minutes filling in my credit card number and what not. Then when I got to the part where I was to select the expiration month and year, the drop-down menus simply didn't work. I had no way to continue in my default browser, Firefox.
It had been 7 or 8 minutes, the cold was starting to numb my fingers, and I was no closer to actually paying for my parking space. I debated just canceling my appointment and driving away rather than risk a parking ticket, but I decided to give it just one more try in the Vanadium browser. Lo and behold, the drop-down menus worked, and after over 10 minutes of messing with a broken kiosk, a broken app, and a broken website, I was able to proceed to the point where I punched in my parking space number. Which, of course, wasn't marked.
At that point I looked up and down the side of the street and noticed a post with numbers for two spots behind me. I noted which number was bigger to infer whether my space would be one higher than the higher or one lower than the lower and punched that in. After my appointment I came out to find the car parked behind me had a parking ticket, while my car didn't. So I guess I managed to punch the right sequence of buttons on my phone to avoid a parking fine.
However the fact remains that I couldn't legally park my car in Salt Lake City unless I was in possession of a functioning smartphone and was running a Chrome-based browser on it.
Not sure if this is more a story of Chrome being the only browser that's tested and/or compatible with critical services I need to use to function in a major U.S. city or if it's a story about municipalities like Salt Lake City making things as difficult as possible for people so as to collect more revenue from fines.
Front end developers bear the responsibility for this nonsense, and many of the guilty post in this very forum!
There is nothing in what you described that couldn't be accomplished with late 90s-era technology.
Why is an app needed? A simple web page with basic HTML, enter number plate or space number, enter payment info, submit, done. No browser features introduced in the last 20 years are needed. The only improvement is enhancements to security - so we're up to TLS 1.3.
Do we really need spinning pinwheels and bleeding edge web standards to process a simple payment?
The machines don’t take cash?
In the nearest urban center the meters don't take cash. The machines also do not take direct payment. The kiosk on each block also does not take payments of any kind. They force you to use a 3rd party app not actually owned by the city.
There is zero way to pay for parking unless you have a smart phone and data. I have no idea why no one has sued for access yet.
1950: put a coin in and walk away
2024: this
We are not living in the future. I wish more people rebelled against bad "smart" implementations.
If "smart" features are a downgrade in speed and ease, do not remove the old way.
I haven't seen any type of machine (including regular vending machines) take cash for at least 10 years, probably longer. Where do you live?
I remember this blog. Magic Lasso Adblock is Apple ecosystem only. Its view on pretty much everything is basically Daring Fireball.
>tends to be misunderstood to mean that Chrome is like Internet Explorer was in 2009
>Despite being the market share leader, there is significant evidence that Chrome is trailing in speed, efficiency and standards interoperability.
>Perhaps the browser with the most disruptive potential is from Microsoft with Edge...... It has also avoided alternative-browser compatibility issues by being based upon Chromium.
Every time this subject came up and I will find people who have never used all three browser at the same time. Or wasn't there during the IE era.
The phase "is Safari the new IE" was actually coined by someone who wasn't even there or doing Web Dev during IE era. It was IE6, not IE7, and definitely not 2008. And the phase somehow catches on to become is Chrome the new IE.
IE was absolutely dominant with 95%+ of browser market share during its peak. Neither Chrome / Blink nor Safari / Webkit ever achieved that. And the most important part was that the HTML / CSS and IE implementation had so many low hanging fruit but NO IMPROVEMENT were made for years. IE 7 / MSHTML released 5 years after IE 6 offered little to no improvement other than a few small fix.
Both Chrome / Blink and Safari / Webkit have continuous development over the years. We may not like some of the direction they are going. But every year there are improvement being made with HTML / CSS / JS features.
Second part being Chrome is a resource hog or slow. Chrome has made tremendous effort into making it memory efficient since 2021 when complain started to pile in. By 2022 and definitely 2023 multi tab on Chrome is far better than what it was. Safari on the other hand isn't doing well on MultiTabs for over a decade but gets zero attention on the issue. Meanwhile Firefox being the fastest browser in terms of least janks and best for hundreds of tabs gets No recognition either.
And lastly Interop. Since 2019 and I believe the first Interop was in 2021. We still dont have a 100% coverage on any Interop year for all three major browsers. I wish Interop could at least agree and publish baseline support that aims to have all browser support by 2025. Instead we are forever stuck in 95% with quirks everywhere.
Actually, quick search leads to [0] (not very reliable, but still better than nothing) shows that Chrome and derivatives take 72%.
As other commenters mention, Safari is mostly locked to the Apple ecosystem, so IMO Chrome on non-Apple systems is around 90%. Firefox is metered to 3% which is lower than reality (due to adblocking).
My personal experience is, however, very similar to IE golden age. In order to interact with state office web apps I need to switch to Chromium. Neither Firefox nor Safari are supported. Vivaldi is a mixed bag (not sure why though). For me this answer questions is Chrome the new IE.
[0]: https://gs.statcounter.com/browser-market-share
>Neither Firefox nor Safari are supported
Depending on which country it is, but Safari is anywhere from 30% to 60% of marketshare on smartphone. I have yet to see any government website that is not tested against Safari.
It depends on the context.
In US I believe that might be true (same site reports around 35%). But those numbers are dropping by a half when you move out.
In India 90%+ reported is Chrome. In Europe Safari is ~20% on average and where I reside it’s around 7% with Chrome being 75%.
Nobody here cares for web correctness. Situation is absurd: e.g. using Safari to input masked password letters for a bank login causes a random number of fields skipping forward. Called that in, no one cares.
When looking at the numbers I would say that US (because of high Safari usage) actually resists Chrome’s monopoly and might not (yet) experience the effects of Chrome IE-ification.
> Meanwhile Firefox being the fastest browser in terms of least janks and best for hundreds of tabs gets No recognition either.
This is likely subjective. Out of the browsers I use regularly, Firefox is by far the one with the greatest number of rough edges as well as the least likely to see those rough edges polished.
To some degree this is inevitable with the difference in amount of resources at Mozilla’s disposal relative to those of Google and Apple, but there’s a lot of low-hanging fruit. In a relatively short time many of these issues have been improved by a small team in the Zen Browser fork of Firefox, which suggests it’s more of a lack of will than it is lack of resources.
The number of websites that only work on chrome really sucks. It's a small percentage, but it's enough that you run into them and I hate that very much.
But unless I'm actively campaigning everyone I know to switch in an effort to save them from it, I'm going to reserve the term "the new ie" for another day.
Not to mention the developer story. Just getting a website to look right in every browser was difficult, with IE very often being by far the hardest.
IE was a nightmare for a long time.
Yes, Chrome is the de facto standard, and often the only browser thoroughly tested against. Even now though it isn't as dominant as IE at its peak though.
No, Chrome isn't significantly behind on adopting new standards compared with other major browsers (I'm looking at you Safari). IE6 to IE7 was about five years!
I see so many ideological arguments around "X is the new IE" that neglect one of the worst pieces of IE 6's reign of terror: the stagnation. Working around all of its quirks and non-standard behavior had an extremely long half-life; the venn diagram of things that worked correctly across all major browsers at the time was very complex and messy. Even with the release of IE7 it took many years for people to adopt it, and IE7 was hardly a saint either.
There's a part of my brain I'll never get back devoted to all of these workarounds. So many hours lost to weird corporate networks that had quirks mode enabled, different box models (before the advent of the `box-sizing` CSS attribute), random omissions of standards (no `:hover` on elements besides `a`), etc.
> one of the worst pieces of IE 6's reign of terror: the stagnation.
This is the thing that I think developers today don’t seem to be able to get their head around. There was a fourteen year time period between Internet Explorer 6 being released and when it dropped out of usage worldwide. Even if you only had to support the USA, it was still eleven years. People could go their entire careers without ever knowing what it was like not having to support it. It paralysed front-end development for more than a decade.
Deprecating it if your site had much traffic was like pulling teeth! I worked at a company that had IT professionals as its main demographic in 2011 and it was a constant struggle. Lots of corporations were locked into IE6 because they had developed internal applications that relied on ActiveX controls or other non-standard APIs. IE7 was still pretty terrible, and it took even longer to drop support.
CSS was pretty bad but at least well-documented; debugging JS was a whole other hell. There was no such thing as dev tooling, and you got a small alert in the status bar when the page had errors, which opened a pop up that gave you the line number and very little other information. Supposedly you could connect it to VisualStudio and get a full debugging experience, but I never had the luxury. Lots of guessing and checking. Firebug was a huge deal when it launched.
Oh man, the days of no dev tools. Man it really is incredible to think how far things have come.
Which standards is Safari significantly behind on?
Note: you have to refrain from listing Chrome-only non-standards. You also have to refrain from listing standards that Chrome shipped years before actual APIs got standardized.
but Chromium being used in Windows' Edge makes it much more
The only problem with Chrome: It's controlled by an advertising company.
And you see evidence of this influence throughout Chrome.
For example, Apple simply blocked third party cookies which are almost exclusively used for tracking. Chrome waited years until they could add their Advertising Sandbox feature first.
Google's competitors in the advertisement space are all lined up to sue Google into oblivion the moment they disable third-party cookies.
Why?
Because Google itself can still track people if they sign into Chrome itself (which it actively encourages by using it as single-sign on for its own services), and thus AdSense can still serve targeted ads, but other ad networks cannot.
You can see it much more clearly in the lack of an extension API on Android.
Chrome on Android is an absolute nightmare for one reason alone: No adblock.
you can disable 3rd party cookies if you want: chrome://settings/cookies
When was the last time you wanted to build a website and web browsers got in the way? Those days are long gone. Compared to a decade ago, everything is amazing.
Tbh service workers are different across browsers and the specific implementations should be taken into account. That or I am bad at it.
Mobile Safari is the new IE. Random idiosyncrasies that are poorly documented dictated by the whims of a single corporation. Apple has broken stuff multiple times in the past few years.
Apple doesn't have an incentive to make mobile web better.
If they do, many apps would just be websites outside their walled garden.
Then it would be quite different from IE. Microsoft was so averse to breaking backwards compatibility, that IE stopped innovating and stagnated.
I was thinking more of every web app needing one or more "if isIE() {} else {}" blocks somewhere in its codebase. Now we have the wondrous pleasure of doing the same for Apple.
There are so many little bits of…weird in Safari.
https://developer.mozilla.org/en-US/docs/Web/CSS/WebKit_Exte...
Just this morning, I had to go down the WebKit pseudo-element rabbit hole to fix a layout bug in a very standard date-of-birth field.
I don't think that is true. They stopped developing it full stop. Keeping back compat was not the issue.
Microsoft stopped developing IE when the government sued them for simply including IE with Windows, the same thing Apple does with Safari. But Apple is far more abusive and forbids any other browser engine on iOS, all browsers on iOS are forced to use Safari under the hood.
> Microsoft stopped developing IE when the government sued them for simply including IE with Windows
They weren't sued for simply including IE with Windows (bundling IE and business arrangements to prevent OEMs from replacing was one of several means of leveraging the Windows desktop OS monopoly to monopolize other markets in the antitrust suit), and they didn't stop developing IE when that suit was initiated.
> But Apple is far more abusive and forbids any other browser engine on iOS
Bundling wasn't the offense, illegally leveraging the desktop OS monopoly to monopolize other markets was the offense. Bundling was part of the means but the means itself want illegal, the ends to which the means were employed were.
> "The central issue was whether Microsoft was allowed to bundle its IE web browser software with its Windows operating system."
> "the DOJ built upon the allegation that Microsoft forced computer makers to include its Internet browser as a part of the installation of Windows software."
https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
It's the same exact situation with MacOS/iOS and Safari, but it's actually far worse with Apple and iOS Safari because people have no choice to install another web browser on iOS, all web browsers on iOS are Safari.
Now, finally, the DOJ is rightly going after Apple for doing this, and many, many other abusive business practices.
Safari, the browser that claims to support standards but always comes with caveats, like saying they support transform/transitions and then everything with box shadows flickering
and Safari finds ways to break existing features with every minor update.
My codebase is full of Safari version-specific bug fixes.
Do you not have fixes for other browsers too?
No
Other browsers are updated more frequently and do not need OS updates.
Safari users are left behind with a broken browser.
I have more iOS 16.1 users (specific version) than all Chrome users with 6+ months old versions.
It's also very slow to support new standards, in my experience.
Web push notifications literally took years to make it from macOS to iOS, for example. (Yes, these are commonly abused for spam and other user-hostile things; no, I don't think that's a valid reason to withhold them from the only acceptable browser on their OS entirely.)
Depends what you’re looking at. They’re very fast at CSS and JS language features
They adopt new web APIs much more cautiously - or they drag their feet - depending on your perspective
Yes it is. I use Firefox wherever I can to not allow one company to take over the internet with their toxic patterns (manifest v3, disallowing screenshotting on pages, breaking their services on other browsers etc.)
Just to (mostly) preempt this because the exact same discussion is had every time this sentiment comes up: Isn't safari the new IE?
Answer: They both are like IE, for different reasons:
Chrome: Pushes proprietary extensions onto the web, which due to their absolute dominance others are somewhat forced to adopt, people develop for it and don't test in any other browser, just like IE
Safari: is coupled to operating system version, lags behind on implementing new features, thus single handedly slowing down when everyone can use new features. Has weird quirks that other browsers don't, just like IE (though not nearly as bad as IE)
So which is like IE? It just depends on what you mean when you say "like IE", the label applies to both because IE was bad for more than one reason
If I understand - Chrome is like IE for pushing proprietary extensions, and Safari is like IE for not implementing those proprietary extensions?
I'm actually far more concerned with the other thing I mentioned, just like on old versions of windows, safari updates are coupled to iOS updates. So if your phone doesn't get any more updates, or you just don't want them, your browser engine is out of date, giving years old safari versions significant market shares. And this impacts stuff like being able to use "gap" for flexbox, which I don't think qualifies as a proprietary chrome feature
Safari is like IE for not implementing standards everyone else has agreed on and implemented.
Some of those unimplemented “standards” are to protect user privacy. I know this is not universally the case, but it’s worth calling out.
You can fingerprint a browser to > 99.9% accuracy because of Google's lax approach to privacy and security when adding new features.
Of course this benefits the advertising side of the business immensely.
Safari states their position on standards here: https://webkit.org/standards-positions/
IMO they have good reasons for opposing most of the standards
I searched that page and their github repo for "inputmode" (my example from before you posted) and couldn't find anything.
https://github.com/WebKit/standards-positions/issues?q=input...
I'd love to find out if anyone on the webkit project is aware of that part of the standard, and if so, the project's official position on it. I can't imagine why they'd oppose it.
Looks like it is already supported by Safari/WebKit for a number of versions: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
They don't even implement the standards that they have agreed to properly.
Did “everyone” agree on and implement them, or did Google implement them and force everyone else in the WHATWG to play catch-up since they’re dominant?
Maybe there are specific examples of that? But I can't think of any, and it certainly doesn't strike me as common. Random example:
https://caniuse.com/input-inputmode
Firefox: 2013
Chrome: 2017
Safari: Any decade now, I'm sure of it
Your own link says it’s supported on Safari for iOS, for years now. It’s obviously not supported on MacOS because that attribute only applies to onscreen keyboards.
What makes you think onscreen keyboards are not useful in macOS if at least for accessibility reasons?
The browser feature under discussion is clearly intended for small screen mobile devices.
Accessibility keyboards are just keyboards from the web page’s perspective
It's clearly NOT intended only for small screen mobile devices.
There's no reason to restrict suggesting input types to mobile browsers only.
That's exactly why desktop Chrome and Firefox has support it for a long time now.
well apparently Apple disagrees
yeah, as usual. That's exactly the point
Such as?
Here's a breakdown: https://caniuse.com/?compare=chrome+131,safari+18.1&compareC...
So, things that are either impossible (touch events or vibration) or ridiculous (why would I want a website to know my battery level or directly access system hardware?)
I'd guess for the same reason we want native apps to be able to do that.
Who said that we want native apps to be able to do that?
There are some use cases for those permissions but we (some) would like more control into that. I can't fight most of the websites as a user (they will tell me to use chrome) but it is for them hard to tell me if you want the service (along a billion other user) then move to android. Apple for a better or worse have much more sway than individual user.
Just because Google implements something does not make it a standard.
Where "everyone else" means Google used Chrome to make it the standard.
No, not only those, also actually legitimate web standards.
War is Peace
I’d love to see these comments about Safari lagging give specific examples. Every time I’ve seen specifics, it’s either only interesting to progressive web apps, or blatantly user hostile tracking/nagging “features”. In my personal experience as a web dev, Safari is often the first to implement new features, and otherwise lags literally just a few months behind, according to their release cycle. WEBP was the exception that was both a real feature and very delayed, but now with JPEG XL it’s Safari first by a mile and Chrome holding everyone back.
What are these proprietary extensions?
if you want a really old example, pnacl. If you want a slightly recent one, FLoC. Not saying those are the best examples, they are just what comes to my head first. I don't really keep up super closely.
pnacl was an example of Google throwing away their homebrewed solution in favour of a common standard (Web Assembly). That seems like a strong argument that they don't push proprietary extensions.
it was an example of them pushing proprietary extensions and eventually removing them again. If I start beating you and then eventually someone calms down and I stop, it's not an example of me not beating you
Neither of these are proprietary.
Both are.
Safari updates are released for the two macOS releases before the current.
not on iOS which is more relevant since you can't even install other engines
I'm pretty sure you can do that now.
One thing missing: Safari is like a worse IE, because not only does it not run on any other OS, like IE, but it doesn’t even run on most hardware.
Yes. By virtue of most other popular browsers being based on it (chromium), with the exceptions of Safari and Firefox. The controller of the project is still Google.
Safari trails chrome because Google didn't like Apple being in charge of the Webkit repo, which led to the Blink fork (the Chromium engine).
Firefox is still a great browser, but it has fallen back to square one on popularity.
From an anti-trust perspective Google should offer to fund their competitors directly instead of splitting the browser out, the eventual result should be revisions to web standards specs to ensure they are correct and detailed enough to be accurately implemented, which in turn makes new browsers easier to implement. Eventually if specs are close to 100% correct it should be reasonable to generate new browser engines from them. Currently that's not possible due to chasms of ambiguity and contradiction, and because browsers like chrome occasionally implement their own design of stuff just because they want to.
> Perhaps the browser with the most disruptive potential is from Microsoft with Edge... With Edge, Microsoft has a chance to claim the position of the disruptive alternate browser.
I believe moving from Chrome to Edge does not change a lot in terms of privacy, proprietary ecosystems, data mining practices, or other reasons that made you switch. In the end, it’s a transition from one tech giant to another of comparable scale with the same practices.
Safar? I don't think Apple has the intention to dominate this sector, so it won't push Safari beyond its current geography. All that it cares about is its * walled garden.
Firefox? Although I use it as my default browser, it is still far from mass adoption. The fact that they beg users to switch to Firefox* say it all: https://news.ycombinator.com/item?id=38806270
Yes, in terms of market share.
But the key difference is that it's leagues better than other browser engines on quality. From the perspective of competition this isn't great, but the network effects are hard to ignore. Firefox and Safari (webkit) just tend not to work as well.
It's very different in terms of quality though. Internet Explorer was a terrible browser and often lagging in implementing standards. The better comparison would be Safari now, which often completely breaks many sites on mobile for me. It also doesn't eliminate a lot of newer CSS animations properly.
This is really very unfortunate because it's good to have competition in browser implementations. Everything is Chrome under the hood now except for Safari and Firefox.
Internet Explorer was an attempt to monopolize and control the early internet. They intentionally left standards unimplemented or just implemented their own insane version of them in order to trap people into the platform.
It's no wonder the product saw them taken to court over antitrust violations.
Safari. I assumed this was overblown until I had the rich experience of developing a Flutter app that needed to work on every platform. Somehow, even Androids chaos is notably better to work with.
A Google product didn't work right on iOS? Shocking.
Google typically goes out of its way to make its products work on iOS while the same can't be said in reverse.
Intentionally restricting apps from using core features of the OS with a paywall is making its products work?
I'm not sure which product(s) you're referring to.
Apple has like 6 apps in the Play Store and one of them is for helping Android users migrate to iOS. On the other hand, Google has dozens of apps in the App Store.
And Flutter Web not working on iOS doesn't even help Google. If anything it just hurts Flutter's adoption on the web which is already low. So I don't think there is some grand conspiracy within Google to take out Safari by withholding Flutter support.
They sort of gave up halfway through lazily invoking the NPC bog-standard Google-on-iOS complaint: you need to pay for YouTube Premium to watch videos picture in picture over other apps.
(source: iOS dev turned Googler turned ex-Googler, so I soak in everyone's grudge matches :) )
I think it might be worse. Google has lied about Chrome and privacy so much that you can just assume it phones everything back to Alphabet even if you set it not to.
Where I work, edge is the new IE, and there has never been an interregnum. I think people forget that institutions have their own logic.
But you realize Edge is just Chrome with a different interface right?
There's more to it than that alone, if you run psExplorer you'll find there's Edge the browser and Edge the subterranean process that's hooked into desktop search and general user activity while constantly engaged in telemetry.
Sure, these are "just Chrome" components and libraries .. but they're engaged in more than simple web page rendering.
NB: I'm not engaging in Edge is Evil conspiracy here and there are "reasons" for what's going on there that some may or may not accept. Just pointing out the additional below the surface integration.
Safari is great and very performant. Not every rushed “standard” Google forces everyone to catch up to is a good thing.
As a Firefox mainliner for 'legacy' reasons to be fair, I often have to revert to Chrome to get sites to work. I guess there are a lott of dev shops out there that just test on Chrome/Edge (and maybe Safari)
Besides, Firefox has its own problems.
The craziest is its permissive same origin policy compared to Chrome/Safari, like how `window.top.location.href = 'https://example.com';` works from inside a cross origin iframe to redirect the parent.
Unlike IE, Chrome is still moving forward with new features and depreciating old features.
New features to ensure ads are pervasive and can’t be blocked? How empowering! Advertisers say thanks. Wait, Google is the biggest. How self-serving.
Depreciating old "features" like supporting legacy OS versions which is infuriating. Firefox is an inadequate substitute because too many sites only work in Chrome.
I blame lazy developers for this mess all around, which had caused a perfect storm of shit on the nouveau web.
I've run into exactly zero sites, that don't want to update some firmware on some piece of hardware over usb, that don't work on firefox.
Congratulations.
Maybe in the future in lieu of additional testing, the development team should just check in with you, and if you declare it sunshine and rainbows, ship it.
Maybe in the future you can stop spreading fud about how everything only works in the most consumer hostile browser on the market.
As a person on a front-end development team that has a “Chrome = success” mandate, it’s not always our decision as to when something ships or for which platforms we are to target. We work on Chrome first and then hope for the time to get things to work elsewhere.
The degree to which Google leadership is capable of fostering innovation of any sort is very much in doubt, but specifically in chrome all they are doing is re-arranging the deck chairs on the titanic while regulators and user preferences tighten the noose on the ad tracking business.
Google is using Chrome and Android to delay privacy rights around the world, that’s it. That’s the whole story.
if any browser is the new IE, it's Firefox -- poor compatibility, very few people use it, but enough that makes people think we need to support it
https://analytics.usa.gov/
We're now at 0.8% Firefox usage on Gov't websites, that means Firefox support is no longer required at a gov't level (2% usage is the threshold)
Firefox should be shut down in 2025 if all trends continue
every time i get a new work machine i attempt to use a browser that is not chrome. last time was firefox, this time was safari. eventually i start using chrome on certain sites because of ublock origin. then, as was the case with aws, certain websites are flakey enough times that i just give in and use chrome full time.
side note: hey aws, why is your rds performance insights dashboard broken on safari? 33% of the time it will "freeze" and i have to reload the page. very un-dude like.
> eventually i start using chrome on certain sites because of ublock origin.
uBO works fine on Firefox for what it's worth. Maybe even better because of the lack of Manifest v3 restrictions.
i'll have to give firefox another look, it has been years.
uBlock Origin works best on Firefox: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
It is, except this time around it's worse.
Yes, Chrome is the new IE in only one category when IE was popular: market share. Everything else? Not so much.
Only use chrome when safari on mac, edge in win11 and whatever browser on Ubuntu failed.
> Is chrome the new IE?
Oh it's way worse than that: Chrome is the new IE, and Google is the new (old) Microsoft.
(2023)
Are web standards the new proprietary extensions?
can i run chrome on my mobile and sync to chrome on my pc and put an adblocker on both?
Is Apple the new Microsoft?
Safari has been the new IE
okay then i wanna see your chrome IE alternative to v8
I always find it comforting to know that a site would work in chrome.
Chromium is, not Chrome
And that's not a bad thing
- open source
- portable
- crossplatform
- efficient
- always up to date
It's a bad thing because Google's monopoly gives them enormous power to influence browser standards, while also having conflicts of interest re: their advertising business.
See for example their recent war against ad blocker extensions.
I just bought a new computer and was curious, so I thought I'd try Windows first, and . . .
No. Chrome is not the new IE. I am constantly pushed to use Edge for everything, to "make it better" for myself. It's actually sorta creepy . . .
You do know that Edge is Chromium repackaged, like all other browsers except Safari and Firefox?
So then why does Microsoft try to push it so hard on users who are trying to use Chrome? It's hard to believe they're just trying to save everyone the minimal time and effort that's being spent installing a different browser by randomly deciding to force a full-screen ad on an OS update. At absolute best, it's benign but worth not using simply to avoid rewarding whatever misguided incentives lead to them to "market" it like this.
https://www.techradar.com/news/sorry-microsoft-not-even-a-fu...
When you use Chrome and sign in, Google is tracking you.
When you use Edge and sign in, Microsoft gets to track you.
Both companies are selling ads.
The Edge browser engine is just Chromium. But the Edge browser has loads of telemetry active. Microsoft wants you to use Edge because the telemetry makes them money, rendering websites doesn't really make them money.
Edge integrates to Windows, Chrome doesn't.
You can set parental controls on Edge using Microsoft's tools, not so for Chrome and Firefox.
(2023)
And, No.
Chrome is controlled by Google.
The US government will be controlled by the owner of X, Tesla, and SpaceX.
No because Chrome is actually a good browser.
We’ll never see a reasonable competitor unless someone like Musk, Zuckerberg, or Bezos gets involved. But that’s not feasible because their companies aren’t internet ad agencies.