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.
Chrome on Android is an absolute nightmare for one reason alone: No adblock.
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.
Google is using Chrome and Android to delay privacy rights around the world, that’s it. That’s the whole story.
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.
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 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.
If they do, many apps would just be websites outside their walled garden.
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
https://caniuse.com/input-inputmode
Firefox: 2013
Chrome: 2017
Safari: Any decade now, I'm sure of it
Accessibility keyboards are just keyboards from the web page’s perspective
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.
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.
IMO they have good reasons for opposing most of the standards
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.
Of course this benefits the advertising side of the business immensely.
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.
(source: iOS dev turned Googler turned ex-Googler, so I soak in everyone's grudge matches :) )
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.
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.
Should be, but isn't. At least not in a practical sense.
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.
Sure, but there is a big difference between implenting 99% of the standard and only implementing like 10%
But if developers don't check, then either one could break the site for all the users.
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.)
They adopt new web APIs much more cautiously - or they drag their feet - depending on your perspective
My codebase is full of Safari version-specific bug fixes.
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.
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.
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.
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.
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?).
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.
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.)
> 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).
Anyway, it's not about _blaming_. Web technologies are being laid in a landscape by multiple parties, it's about understanding that landscape.
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?
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.
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?
No, when was that? Because it was always possible to `eval(jsonString)` and get the parsed result. Indeed, that was the whole point.
We're oldschool, not savages!
2024 - 1998 = 26
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.
And that's not a bad thing
- open source
- portable
- crossplatform
- efficient
- always up to date
See for example their recent war against ad blocker extensions.
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 . . .
https://www.techradar.com/news/sorry-microsoft-not-even-a-fu...
When you use Edge and sign in, Microsoft gets to track you.
Both companies are selling ads.
You can set parental controls on Edge using Microsoft's tools, not so for Chrome and Firefox.
>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.
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.
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.
And, No.
Oh it's way worse than that: Chrome is the new IE, and Google is the new (old) Microsoft.
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.
uBO works fine on Firefox for what it's worth. Maybe even better because of the lack of Manifest v3 restrictions.
The US government will be controlled by the owner of X, Tesla, and SpaceX.
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.)
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.
What if it's Google themselves? From my original post:
> [...] and that often includes Google sites/apps
What google site or service requires Chrome?
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
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.
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.
Enabling JS is not enough, so I think its liked to privacy plugins, or running inside a container.
And look no further than Google themselves: https://labs.google.com/search/install
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.
What firefox cannot do and chrome can is HDR playback.
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.
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)
Do you happen to have any examples? I’m curious to see how broken/what the issues are.
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.
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.
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.
> I have to keep a Windows install around for the times that I need to do something that can't be done on Linux.
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.
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.
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.
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 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.)
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.
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.
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).
> Apple gets away with stuff today that would have made Bill Gates blush in 1998.
The end user is always served better by native apps.
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.
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.
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.
Last man being propped up Weekend-at-Bernie's style?
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.
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.
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!!!
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.
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.
Google implementing a draft they themselves authored with minimal review doesn't make it standard just because w3c publishes the draft.
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() {
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.
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).
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.
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.
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.
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.
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.
Monocultures that allow for one company to make it hard to avoid advertising and data tracking on the web are even worse.
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.
MS in their IE days did the exact opposite, trying to make as many proprietary IE only features as possible.
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!
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.
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.
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.
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.
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.
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.
It's no wonder the product saw them taken to court over antitrust violations.
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.
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.
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.
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.
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?
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.
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.
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
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