Alex Russell

But this is exactly the point of the article. That'd be like if I needed to build a car, I started with a rocket blueprint in case I also need to go to space in the future.

The cost of speculating a highly interactive site that users will want to interact with is a suboptimal baseline experience until you get there. Provided you get there without losing users, it'll still be a subset of your audience that use your thing in a way that truly offsets all of these costs. If that works for your product/business, then awesome! But if these costs are too high and will hurt your product, then you need to be a lot more deliberate about how you engineer it.

I typically approach the problem first and see what tools work best to solve the problem, rather than work backwards from my preferred set of tools.

> Once you've dug that hole, you either have to live with it, or face a painful rewrite later.

Based on the tools you mentioned familiarity with, wouldn't something like Astro be a happy middle ground? You start as an MPA by default and only add complexity to parts (entire routes or parts of a page) of the application that require it? Also, this hole goes both ways. If you've built your site as a SPA, and you realise that your product just needs to be HTML to stay competitive, it's a painful road to unpick the layers of abstraction you've bought if you don't wanna rewrite it.

> dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering,…

I ended up writing a huge wall of text for this, but realized it was too much. The article I think makes too many proclamations without supporting a single one with logic or evidence, and I'm not really interested in articles that put the onus on me to justify the author. Most everything from the article seems to be lifted from the following article, but rephrased without nearly as much justification: https://infrequently.org/2022/06/apple-is-not-defending-browser-engine-choice/

And the main thing that stands out to me on the above linked article and the parent article is the focus on WebApps (PWAs) or other restrictions Apple puts on iOS.

To which I say "good riddance, toss it out with the rest of the trash", cause I don't need every single website having that much access to my phone and especially notifications. Even on MacOS, the defaults for what can and cannot send notifications are insane and very frustrating, and the less said about Android the better; I don't even use that many apps on my android phone and I'm tired of the countless notifications to dismiss every morning that are just absolute spam. The lack of granularity means that I can't really pick if my delivery app only triggers notifications for actual deliveries versus just random spam notifications; it's either a few useful notifications during a transaction I care about once or twice a week along with dozens of notifications a week, or no notifications at all. The Calendar app default on my phone tries…

It's far worse than "Apple is slow at implementing". I've spent most of the last 10 years with Safari iOS as my primary target platform. I'll try to break down the major issues as unless you are intimately involved with Safari iOS development it can be hard to see the issues by simply using the browser.

1. Bugs
Safari is the the most buggy browser with application breaking bugs crossing into every aspect of development, whether your using WebRTC, Audio, Scroll/UI, LocalStorage/IDB... Safari is the most buggy browser.

Examples:
* LocalStorage / IDB has broken many times over the last 10 years, including breaking for months in production. Normally gets fixed in webkit pretty quick, but takes a month to actually make it to an iOS release.

* Viewport/Scroll/UI/Zoom Bugs - As a collection of issues also related to hiding the header on body scroll, zoom etc.. To fix we had reimplement ALL of user scroll including momentum scrolling, bounce etc in userland js. A mammoth 210 hours of hardcore engineering just to get around bugs that have existed for 5 years.

* bugs.webkit.org is useless as a bug tracking tool, stuff just doesn't get triaged properly, or is hidden away in radar or whatever Apple is using internally and worst of all it just does not get fixed.

Why? It's not the Safari's teams fault, their engineers are all super smart, work hard, care about the web, and some have been building it from the days when Safari was the best browser by far... but you can't build…

I'm not sure what your point is. Web standards have had a turbulent history? Of course that's true.

- CSS 2 was originally published as a recommendation in 1998. CSS 2.1 was pushed as a recommendation in 2011. Maybe something was wrong?

- "Ignored by vendors" is a bit of an understatement, because your "close to 20 years" includes 5 years of the vendor with 90% marketshare not releasing anything at all.

- FWIW, what became flexbox was useable (assuming polyfills aplenty) in Firefox and Webkit browsers 5 years ago[1]. It took some time to standardize, but while frustrating in the present, it's ok to take time to make sure the spec works, because it will be (in theory) around for quite a while.

> It makes it 'easy' by introducing yet another weird box modelism that doesn't really fit anything else that's already there

What many people don't appreciate about layout in general (and WRT to the web, dynamic layout in particular), is that it turns out to be difficult (and sometimes extremely computationally expensive) to implement an expressive layout system that does what we intuitively think it should. A good example is word wrapping, which is easy to tell when it "looks right" (at least to a trained eye), was done by hand by many when printing was done more manually, but turns out to be difficult to assign a metric that handles all use cases, especially when you're trying to be computationally efficient.

Web layout is like a whole set of word wrapping requirements,…

Remember just a couple of years ago when you could get root access on a locked device without any kind of password [1]

Honestly I’m not that convinced iOS is that much better. It’s reputation is so much better than it should be. The number of emergency patches I’ve seen out of them the past few years for many many trivial bugs is amazing.

Just this morning I was reading a post from a Chrome engineer talking about how the fundamental architecture of their security is built around a decision that nobody else has thought of as a good time for many years. [2] It’s only going to get worse over time.

Then to make matters worse they have managed to get an absolutely horrible relationship with the security community [3] who now seem to have zero interest in helping them meaning that the main external groups left looking at their security are those who are going to put them on the black market.

Prior to that researchers were finding so many bugs that the legit market rate for 0days fell well below Android. [4]

I ditched my Mac in 2020 and I’m currently waiting for my current iPhone to no longer be up to the task and I’m officially done with Apple after 10 years of nothing but.

[1] https://www.google.com/amp/s/arstechnica.com/information-technology/2017/11/macos-bug-lets-you-log-in-as-admin-with-no-password-required/%3Famp%3D1

[2] https://infrequently.org/2021/04/progress-delayed/

[3] https://www.washingtonpost.com/technology/2021/09/09/apple-bug-bounty/

[4]…

Look, it's okay to have a side you root for due to emotional reasons but this is just silly. When the Pixel 6a was introduced in 2022, its performance was somewhere in between the 2017 iPhone 7 and the 2018 iPhone XS. No magical thinking about "scroll speed" is going to make up for that underlying performance gap.

Since this is a technical forum, I am going to plug the blog post Alex Russell (not usually described as an Apple fanboy) made about real-world performance for web developers. One of the challenges we have is that normal people hang on to phones for a while and that's especially true for people who buy cheap phones since they often can't afford to buy a new one every year. When a developer testing on an “old” iPhone has a browser which runs code faster than the current flagship Android phone (iPhone XS ~= Galaxy S22), that means that they effectively have no idea what the web is like for a person using a $200 phone which they've had for a few years. There's a great chart here:

https://infrequently.org/2022/12/performance-baseline-2023/#devices-1

Now, the Pixel line does have a decent camera so that's potentially a plus but it's not really relevant to the device's capabilities or long-term support situation. It's also unlikely that a single test is telling you that such an old sensor is really the best thing in the world rather than Google's ML pipeline is good at adjusting images to make them appealing to phone users.