Fifty problems with standard web APIs in 2025
(zerotrickpony.com)136 points by dhruv3006 6 days ago
136 points by dhruv3006 6 days ago
I've been saying this for years, and it gets down voted occasionally, but safari/webkit feels like the new IE6. I know Chrome is very bullish with adding extra features and is aggressively pushing some standards, but I've rarely had to write "workarounds" or hacks for Chrome when writing web-standard compliant code for other browsers, but I've had to frequently do it for Safari.
It's been a few years since I've had battle Safari quirks, one example that stuck with me from a couple of years ago is that LocalStorage is not available in private browsing mode. Other browsers just treat it as ephemeral/SessionStorage basically.
Also I remember our Sentry being _littered_ with random React internals throwing (it was like a couple of different things), but it was only ever iOS that had those issues.
Chrome probably has the benefit of being updated frequently rather than more of an annual cycle. But Safari still isn't anywhere near IE6 levels of awfulness.
> The web has supported these basic functions for over a decade. Surely in the year 2025, I thought, HTML5 is a good choice for these simple needs.
> What really happened was, I hit over 50 surprising problems related to gaps in web standards, requiring me to spend over half of the total development time
The half part might be surprising, but the fact that the web is broken in all the big and little places shouldn't really be, isn't that part of deep web lore that you get even by looking at the omnipresent dom tree, but especially if you're a druid and forest-native?
Like, "No you can't control the real size of anything" has been one of the many fundamental cascading flaws of that peculiar joke of a design system since forever, no?
I feel like there are a lot of iOS/iPadOS 17 and below devices holding things back right now. Desktop browsers are in a really good standards space now with their constant and frequent nagging for users to update.
iOS Safari's reader mode heuristics has always been mediocre at best, and it's getting less useful by the day as more publications knowingly cripple it. It used to be that you can get around some soft paywalls with reader mode, especially if you turn on "Use Reader Automatically" which distills the content before JavaScript kicks in to remove it. Nowadays that works on fewer and fewer commercial websites, and the other day I noticed something truly shocking on a pretty mainstream tech publication (don't remember which one unfortunately): I can see like two paragraphs of content before the paywall, but when I turn on reader mode, the content shown is literally a list of Christmas laptop deals (that is not visible on the non-reader page), with the title being the only relevant thing.
The ai detected it was talking poorly about it and decided to retaliate.
Apple is the only ones holding anything back on iOS. They forbid any browser except Safari. At least if they let Google Chrome or any other browser maker use their own browser engine, iOS could have a capable browser installed. It is one reason among many Apple is being sued by the DOJ, but so far no progress forcing them to allow other browser engines like they did in the EU.
I’m typing this in Vivaldi on my iPhone 11 in the UK.
I acknowledge my privilege.
Yet another step towards a total Google monopoly, yay!
this felt not as a "50 problems in web api" list, but more like "50 reasons to stop caring about iOS and just leave it rotting"
They can get away with it because iOS users have a higher propensity to pay than any other platform. So it's often not a good idea to stop caring about iOS, assuming you want to make money, anyway. Even if you don't, iOS users are just different from Android and web, so they're often desirable regardless.
> They can get away with it because iOS users have a higher propensity to pay than any other platform.
It used to be true, but the last time I saw evidence was in 2015 or thereabouts.
Is it still true in (almost) 2026, though?
I'm so glad every time I see something like this that I don't do webdev for a living.
I've cross-compiled code for mobile before, and I've made personal websites before. I sure wouldn't want to do that for a living.
Ok, the complaints about Apple being behind the Google "standard" are probably legitimate, as long as we keep in mind Chrome isn't a standard.
But the part about a virtual mouse cursor so you have hover... no. No no and no. No on Apple, no on Android, no on any touch only device.
The iPhone took the world by storm because they designed their UI for fat finger touch only. Back then, Google speed redesigned their unreleased Android along the same paradigms when they saw how easy the Apple solution was to use.
If you have a mouse heavy game, no matter if you do it in native code or html, you have to have different interfaces for touch and mouse/kb if you want it to be playable.
Interesting article which reinforces my decision to never engage with web development in any manner other than throwing WASM paint on a Canvas.
> But a purpose-built game framework like Unity would have polyfill to protect you from more of these layout and audio problems
Unity doesn't polyfill, it just relies on WASM for everything which results in significantly more consistent behaviour provided your browser supports WASM to begin with.
> Unity and Godot might be better choices, but I have no experience with them and I assume they only make sense for games.
Unity has been used for non-game purposes successfully, and there are also other WASM-compatible frameworks specifically targeting non-game GUI use cases.
Unity in the browser fails basic interactions like copy and paste. All WASM paint on an Canvas apps on the browser have similar issues with non-english input, accessability, integration with tihngs like dictionaries, password managers, etc...
So, no, do not do Wasm + Canvas
To be clear, I am not suggesting the WASM canvas approach for ordinary web pages. WASM is for things that are unto themselves full-fledged applications, with the convenience of instant access to running them in a sandbox on any platform. The game described in the article certainly makes more sense with WASM than HTML5, as it uses web APIs for doing something that isn't displaying a standard web page but instead needs to conform to a specific set of characteristics to provide a consistent and polished user experience.
Also, while Unity doesn't, features like canvas copy-pasting can be implemented manually or by another framework. Non-English input works fine with WASM; if it doesn't render, it's because the application developer didn't include a font that supports those characters, since there's no fallback-font kind of thing going on. But this stuff is exactly the same as developing any kind of non-web application; if the framework doesn't provide a feature, you have to provide it yourself. It needs to be approached from an application development perspective rather than a web development perspective; you don't get the freebies of web, both the good and the bad, but this gives you much more control and capability.
The only reason to use the web is because it reaches everywhere. you then hoble it by making it not work in 2/3rds of the world you might as well have just shipped a native app.
Also, I think you're under estimating the amount of work required. No one wants your custom solutions. They want the OS solution. They want their OS IME that they use in every app, not the one you built from scratch for your "blat pixels to the page" app. They want their passkeys from their OS, which are only available via web features and are not available from "blat pixels to the page" apps. They want their auto correct to use all the words in their local OS dictionary but that's not available to "blat pixels to the page" apps. I could list several more issues like this
You appear to be misinformed. OS-level features like IMEs and dictionaries work in WASM as they do with any native application. There is nothing special about HTML elements that enables them in a way that doesn't work with WASM; they are, after all, OS features, not HTML features, and the browser is just another native application. If somebody chooses not to integrate OS features in their application, that's a reason not to use their application, but it really has nothing to do with WASM in any way whatsoever.
> The only reason to use the web is because it reaches everywhere. you then hoble it by making it not work in 2/3rds of the world you might as well have just shipped a native app.
I also think this is a ridiculously reductionist take. While I myself consider language support a priority (and incidentally, happen to believe for instance most Linux distros have long kneecapped the spread of Linux by not being accessible to non-Latin users) [and conversely believe WASM does not hobble language support, otherwise I would not be interested in it], that is not even close to "the only reason" to use the web. There are plenty of people in the world who host websites in only their native language. Even if you don't care to support foreign languages, deploying to the web gives you (a) instant cross-platform support with comparatively low effort and (b) zero friction to users, who can instantly use your application without an installation process which itself entails security risks. Would the use of WASM for a niche English text adventure put off Chinese users who might otherwise play the game if only it was written in HTML5? Probably not, they were never going to play the game in the first place.
It sounds like they were testing with iOS 12? In practice that has fallen out of use and doesn't need to be supported any more. Yes, a bunch of problems are to do with Safari specifically, but if you target relatively modern versions only (iOS 16+ is pretty reasonable IMO) it'll save a lot of pain.
Yeah, supporting iOS 12 in 2025 is odd. I was investigating browser support levels just recently for a library and also settled on iOS 16 as a reasonable level.
For reference, iOS 12.x and below are used 0.33% globally https://browsersl.ist/#q=safari+%3C+13+or+ios+%3C+13. Selecting iOS 16 would still exclude less than 1% globally https://browsersl.ist/#q=safari+%3C+16+or+ios+%3C+16. In both cases the vast majority would be older iOS which is unfortunate because I assume they're on older devices with no upgrade path, but you have to decide on the transpile/polyfill cutoff at some point and browser support has an extremely long tail.
While this list is accurate enough, I assume the developer doesn't have to support older Android phones, because ... yeah. That's hell.
But it is interesting that most of the listed issues that are genuine bugs are fairly minor, while the show-stoppers are largely Apple trying to protect user's from bad actors.
Which, as a developer, I hate. But as a user, I appreciate.
Surfing the web on my Android devices is absolute madness in certain segments of the web.
I could probably give another 50 as could everyone else reading
Biggest peev for me is inconsistent support for transparent (alpha channel) video
The full screen thing -- have you tried saving the SPA to the home screen?
Together with some meta tags, that launches full screen and stays full screen, like an app.
The bashing on apple for this "to sell more apps" is nonsense, Apple originally designed and intended for HTML5 apps to beat Flash.
One of the earliest games for iPhone was PacMac, it was a SPA web app saved to home screen, it worked great.*
OTOH, in 30 years of web dev, I never got pages about raccoons to work either.
* Haven't checked this lately to see if they deprecated this.
> The bashing on apple for this "to sell more apps" is nonsense, Apple originally designed and intended for HTML5 apps to beat Flash.
Whatever their apparent intention might have been ~15 years ago, it would be hard to argue that Apple puts a lot of resources into trying to protect its fiefdom. I don't think it would be all that different to suggest they (Apple) wouldn't try to control how people pay for apps by preventing app developers to offer a web-based payment option, on the basis of their past relationship with HTML5. A huge component in their success with iPhones has been control over the entire supply chain.
That said, it is a somewhat conspiratorial take that is probably better explained by laziness, bad choices, and control over proprietary UX patterns (that suck), than generalized competition, but it's not much of a reach. They also compute localStorage limits differently and have always diverged for stupid reasons
Interestingly enough Apple has put a ton of effort into Safari recently and have shot up to the top of the interop leaderboards.
https://wpt.fyi/interop-2025?stable
I don't really buy the conspiratorial takes either. I think they just had different priorities for their browser.
I think it's fair to say that Safari is no longer late. That comes with 3 caveats.
1. Safari isn't updated independently of the OS, so users who don't update or whose iPhones don't get updates anymore will be forever stuck on old Safari versions.
2. Being timely on new features does little to alleviate the pain that comes from all the old messiness.
3. Different priorities driven by economic incentives of protecting their 30% cut. Fair enough. But shutting out alternative web engines on iOS is definitely a dick move.
Unfortunately this is more misdirection from Apple.
When they were asking for community input as to what developers wanted to be a part of interop 2025 that then had to go for a further non-public round with the browser makers.
Apple then proceeded to veto all of the most popular suggestions and insist that then running grep over their codebase in order to fix a comparability bug [1] with chrome and Firefox version 1 was somehow a legitimate contribution precisely so they could game the interop stats that you’re citing here.
The moment you look at the real statistics (https://wpt.fyi/results/?label=master&label=experimental&ali...) where Apple can’t game the system the story becomes much clearer and the criticism much more justified.
[1] https://web.dev/blog/interop-2025 (scroll down to the text decoration topic)
Unfortunately it was and still is. https://en.wikipedia.org/wiki/Safari_(web_browser)#Version_c....
MacOs is slightly more forgiving in that the last 2 versions can get the latest safari. However, people tend to keep a computer a lot longer than a phone and many don't or can't update macOS, so it's not much better.
I kinda feel like "Fifty problems with standard web APIs in 2025" is an inaccurate title.
More like "+40 reasons to ignore iOS as a target when making your HTML game"