Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer, Selenium, etc and so forth).
Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.
The biggest problem with IE from a developer standpoint wasn't the slow feature release cadence, it was that the features it did have worked differently from standards-based browsers. That's very much the position of Safari/WebKit today - code that works across all other engines throws errors in WebKit and often requires substantial changes to resolve.
Safari is also pretty popular on iPhones, in fact it has a full 100% market share. With browser updates tied to the OS, that means millions of devices have those "temporary" problems baked in forever.
When IE was the Emperor it was seen as IE's behaviors were the standards. The perspective at the time was that the other browsers were non-standard. That did get codified into the standards eventually. `* { box-sizing: border-box; }` that is towards the top of almost every "reset.css" is CSS standard for "use the IE box model". XHR was named XmlHttpRequest as an IE quirk and that set the standard we still mostly follow today; `fetch` is a nicer API but we still colloquially call it a part of/relative to/replacement for XHR including various browsers' Dev Tools where to focus on `fetch` requests you click the XHR tab.
Both of those things (and others) became "standards" when IE was moving quickly and breaking things. It took a while for the actual multi-browser standards to catch up. XHR took a few years to show up in non-IE browsers. CSS `box-sizing` wasn't added to the CSS standards until 2012 (11 years after IE6 was released, the "last" version of IE for a long time; five years without a new version). A lot of the web was built easier on those things or better with those things which lead to so many people using IE up to IE6 as their primary browser and so many developers building IE-only websites up to IE6.
Again, as a developer it can be easy to remember the pain of still supporting IE6 in 2005 (five years before tools like `box-sizing` made it a lot easier to support similar CSS for both IE and non-IE browsers, and a year before IE7 finally broke the "IE6 is the last IE" problem). It seems a lot harder to remember why we were still supporting a "dead"/"final" IE6 in 2005 or still supporting a "dead"/"final" IE6 in 2012 when IE10 was fresh and new and very standards compliant (including supporting both `box-sizing` modes) but not yet winning over the crowds of legacy sites: everyone was using IE6 until Microsoft killed it. A lot of things were built for its version of "standards" (many of which were better/easier to develop for versus their contemporary real standards) and couldn't be easily upgraded until the real standards also caught up to how fast IE had been innovating/changing/upgrading the standards.
The risk to the web platform that I think IE represents the most cautionary tale about is relying too much on the browser rushing ahead of the standards, because it could stop at any moment and may take a decade or more for the standards to truly catch back up. Because they did.
If Google decided today to do a "The Browser Company-style pivot" because the Age of AI means that browsers are dead, everything a browser can do should be done through agentic automation, and asked all of the Chrome team to switch to some new agentic harness or accept a soft layoff, how much work would there be to move websites out of being "Chrome-only" or built on top of Chromium? (Which to be further unfair is also sort of what feels like is already left of Microsoft's Edge team working in Chromium today.) It's real easy to imagine that hypothetical, I already named two companies working with Chromium that have just about done exactly that. The hypothetical is not that far from the inside baseball of what happened to IE6 where Microsoft thought browsers were "done" and pivoted the IE team to new roles on "higher priority" Windows work and/or soft layoffs.
We remember the pain of having to support older versions of IE pretty well, but not enough of us seem to remember the pain of how we got to that point and how easy it feels like companies could do that to the web again. Safari lagging current standards is a relatively smaller problem compared to if Chrome gets burnt we suffer another "internet dark age" of supporting ancient browsers for a decade or two due to legacy apps and in turn legacy users that don't or won't upgrade.
(Some would argue that can't happen in the same way that IE did because Chromium is open source and already has many forks. I can't help up but bring up examples like the word "diaspora" and the tale of "the Tower of Babel" that a messy soup of forks that no one can agree on as the new "standard" can be its own slow train wreck disaster.)
> Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back".
There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
It's a matter of perspective. The safer perspective is: Safari isn't holding the web back, Chrome is moving too fast. Developers making Chrome-only sites and tools are moving too fast for the safety of web standards/web platform. Where one of the safety factors is "widely available in multiple implementations, not just a single browser".
> > Safari's problems are temporary.
> What are you talking about?
The point is that Safari may be moving slow, but it is still moving. It doesn't have enough users to hold the web back. It isn't "always a decade behind", it 's "a couple years to a couple months behind", depending on which caniuse or MDN Baseline approach you want to take.
There are some things Safari doesn't want to implement, but has registered safety or privacy or coupling reasons behind such things. Firefox is doing the same.
Safari isn't trapping website developers in "old standards forever", it is encouraging developers to use safe, private, stable choices. Chrome is "move fast and sometimes break things". Safari doesn't want to be that. That's useful for the web as a platform to have one or two browsers considering their implementations. It's a good reason to point out "Chrome-only" developers as being "too bleeding edge" (sometimes emphasis on the bleeding) and out of touch with standards and standards processes.
The only well supported and consistent argument I see in those links is that Safari is bad at PWAs. I agree with that. But (timely rant incoming) I also think everyone is currently bad at PWAs. The current ServiceWorker-based approach is brittle and hard to use because it is too low level and too tightly coupled to what seem to be Chrome-specific concerns. The previous manifest.json approach should have never been disabled in Chrome, it should have at least lived side-by-side and let developers vote by their feet, at least until a reasonably equivalent high-level manifest replacement was built.
I was just thinking about this this week because I have a webpage I built with offline capabilities and an excuse coming up where many of the webpage's users will be offline for a week but might have use for the webpage, but I can't easily turn it into a PWA because it was built as an MPA and there's no great high level tools for writing an MPA's ServiceWorker because most of the high level libraries are so (overly) focused on SPAs. I wish I could just put a manifest.json or some sort of zip archive users could download and have it share Local Storage.
I do pin a lot of this on Google engineers. The side effect is Safari is having a hard time implementing these "standards", but the real cause is the "standards" are over-complicated trash that are also hard to develop for. Everyone including the links you sent can see how Apple's App Store moat gives them an incentive to drag their feet on implementing these "standards" and yet no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards that are hard for anyone to use and harder for anyone else to implement is just another way to drag your feet and keep the whole web platform behind, without looking like you are dragging your feet.
It would feel different, too, if the fully declarative manifest.json approach hadn't briefly worked (well) in Edge (Spartan) and Firefox before Google derailed that standards train with "Chrome-first" ServiceWorker complications. Always seemed like one of the reasons that Microsoft just gave up on the web platform because they couldn't keep up with Google's machinations (and conflicts of interest) in Chrome.
It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.
The safari feet dragging/obstruction goes far beyond PWAs. The chart on this page is one of many examples showing how consistently far behind Safari is - they've been enormously behind chrome and firefox in coverage of tests for 7+ years. https://wpt.fyi/. And here's an extremely comprehensive article on the topic https://webventures.rejh.nl/blog/2024/history-of-safari-show...
As for standards, here's another detailed series to learn from https://infrequently.org/series/effective-standards-work/. Once again, you have it all backwards. Saying "no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards" is not only laughable, but just dumb - Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
Moreover, it is quite clearly an institutional decision to hold back the web, or else they would allow for other browser engines to run on iOS rather than focing them all to be skins on webkit. Again, this is all documented in extreme detail in the articles on that site. If you find it to be still somehow lacking, the author is very open to discussion on bluesky or mastodon (I'd prepare far better though, because what you've said thus far would get eviscerated).
Also bizarre that you are saying that Google Play is somehow at the root of this supposed scheme to make web standards impossible for others to implement. Android is similarly against the web flourishing, but evidently not nearly as powerful in the greater Google enterprise as iphone/app store is in Apple.
As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
If you are actually attempting to communicate in good faith, i can't recommend strongly enough that you read that entire site. And, likewise, read and support the work of Open Web Advocacy. https://open-web-advocacy.org/
Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.