Trying again: Apple's iOS store shenanigans include a subtle & unique catch-22 journalists should grok:
- when apps violate policy, Apple says "use the web"
- ...except every iOS browser is required to use Apple's engine...
- ...and it's Apple keeps it year behind
This is hidden from view because no iOS browser maker dares to submit a browser that shows a "this isn't _real_ Firefox" (e.g.) banner...because what is the user supposed to do? Buy a new phone? They also can't afford to be cut off from all the world's rich users.
But why is Apple's engine & browser years behind?
Because Apple doesn't fund the WebKit team with anything like the headcount they'd need to keep up. And let's keep in mind that this isn't down to some sort of cash crunch.
This is a choice.
The under-funding has compounding consequences:
Developers are used to Apple ignoring; most don't even bother to file bugs on WebKit:
Browser makers who want to co-design new features know asking Apple is stones into a bottomless well (tho we persist).
This leads to a situation where, even when Apple catches up (e.g., Service Workers), critical follow-on features flagged by high-profile sites and partners are missing (e.g., Nav Preload).
All browsers have bugs, but late catch-up + key issues + yearly pace == massive delay.
There's a way out of this problem that doesn't require Apple to invest a reasonable amount in WebKit/Safari (tho everyone would welcome that regardless):
Allow competing browsers, the way *EVERY OTHER OS* does. Other vendors would _love_ to deliver a better web to their users.
So to recap, every time App Store shenanigans flare up, commenters should look hard at the argument that the web on iOS is some sort of alternative. You don't take my word for it, either. Go talk to developers. Do _they_ think Apple's iOS kept-web is good enough?
(typos, FML)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I need to blog about the Principle of Minimal Client Complexity, but one way to understand why I push back so hard on huge stacks of JS is that when you move thing to the client, you don't add risks from each uncontrolled dimension, you _multiply_ them.
What are those risks?
By way of disclaimer, know that while I platonically wish for your datacenter stack to not suck, I do not *care* if your datacenter stack is a frankenstein's monster of microservices and graphql and docker kubernetes in a single rack.
Do. Not. Care.
What you do between consenting CPUs that you own, across links that you control, talking to storage that you pay for, is -- for the most part -- not usually what's wrong in a modern frontend.
Also speaks to why Aeron is an idjit. But I digress.
Times are tough, and profits are at a premium right now. Here's one weird trick for making more money: HTML.
That's right! JS is costing you. Rip it out of your site and watch engagement/conversions rise.
If you're a frontender, know a few things:
- bad results have been leading to frontend teams getting quietly flushed for *years*
- bad site outcomes aren't always material..
- ...but now that there's more focus, it can help our teams to deliver better
It may feel like there isn't anything we can do to forestall layoffs and downsizing, and in the main that's true, but at the margins the best defense is to deliver better results.
In e-commerce at least, that's aligned with performance...and that's improved w/ less JS.
Frontend needs to stop looking for silver bullets. The correct answer in almost every case is *moderation* coupled with *product understanding*.
If you don't know who you're serving, you can't make good tech choices, and we should be conservative abt client complexity regardless
I've called this the Principle of Minimum Client Complexity, and it holds across both native and web. Everything you run on the client is _at risk_.
At risk from hardware and network foibles. At risk from OS wonkiness. At risk from a lack of control. So *do less* there.
And if there's even an inkling of a chance that your thing can be included in another larger thing -- say via SDK or embedding -- for goodness sake, understand that your customer is *already at the limit*. There's no headroom left for you, so you must first do no harm.
One consequence of Apple kneecapping web apps has been that native is now the default, and because native gives away so much by default, huge amounts of personal data are at risk. Far from being a privacy champion, Apple has facilitated its erosion:
Where web is the dominant platform, users can pick browsers that have their interests in mind rather than the app developer's. This shrinks the space for performative, white-knighting actions (e.g. ATT) by platform vendors, but it's structurally more effective.
Apple & Google want you to think they're brave and principled for putting out a small subset of the fires they lit with incendiary cluster munitions across a huge swath of computing.
It works because they can always count on tech press not to think in terms of substitutability.
The frontend community wants to wash its hands of the decade we lost without naming the causes and consequences of the dogma that swept away better, more grounded approaches and replaced them with MBs of JS.
That's not a recipe for healing what was broken.
I'm constantly seeing fresh disasters based on popular-yet-fading tech stacks on a daily basis.
Sites built on this stuff won't blink out of existence when the devs who made these messes decide they no longer want to Angular/React/CSS-in-JS/Apollo/redux their way to failure.
So we should applaud the shift & be grateful for the change in consensus. But we can't pretend the plot wasn't lost for 10 years. Or claim "nobody could have known":
Toxic positivity can't be allowed to whitewash the failure of the JS-first crowd (again)