The bombshell article of the week is from Alex Russell of Google/Chrome. Alex has long been super critical of Apple, particularly about how there is literally no option to run any other browser than Safari on iOS. This article isn’t just fist-waving about that, but a dissertation accusing Apple of real harm to the web platform by sluggish progress on Safari and a no-web-apps App Store.
Apple’s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.
I appreciate Alex’s take here. It gives credit where credit is due, it places blame where it feels most fair to place it, and brings data to a complex conversation that deserves it. It’s hard not to get through the article and think that the web would be in a better place should Apple…
- Allow alternative browsers on iOS
- Allow web apps in the App Store
- Move faster with web platform features in Safari
Taking them one at a time…
- Do I want this? Yes. It seems reasonable that my $1,000 extremely powerful computer phone should be able to run whatever browser I want, particularly one from a company that makes a really good one and very much wants to ship it on my phone. In reality, I’m sure the complications around this are far beyond my understanding. I always think about that Chrome update that literally broke macOS. Could that happen on iOS? While lack of features might abstractly make for unhappy customers, a bricked phone very directly makes for unhappy customers. I suspect it more boils down to the fact that Google is an advertising company that innovates on tracking technology and Apple is a hardware company that innovates on privacy. That’s a rock-and-hard-place situation and this browser situation is one of the consequences.
- Do I want this? Yes. I don’t even know how to make native apps aside from software that turns web apps into native apps with magic. If web apps could go in the Apple App Store, it opens the door for people like me (and there are a lot of me). In reality, I’m sure the complications around this are far beyond my understanding. Is quality control harder? I gotta imagine it is. Is security harder to lock down? I gotta imagine it is. Are customers clamoring for it? I’m not sure I hear them very loudly. People do have a choice, as well: iOS is only 15% of the phone market. If you want an alternative browser and an alternative app store, you can have it.
- Do I want this? Yes. Heck, we celebrate little wins that Safari ships. I certainly don’t want to wait years for every clearly-useful feature. It will be interesting to measure the time for
contain
and container queries. That one looms large for me as I want to use it as soon as possible, without polyfills, once it stabilizes. I know the joke goes that “Safari is the new IE” but I don’t tend to feel that day-to-day in my typical web dev work. I feel like I can ship extremely capable websites to all browsers, including Safari, and not worry terribly much about Safari being a second-class experience. (I don’t make games or VR/AR experiences, though.) I’m honestly more worried about Firefox here. Apple and Google have more money than God. It’s Mozilla I worry about being DDoS’d with web-feature onslaught, although to be fair, they seem to be doing fine at the moment.
As far as Safari-behind-ness goes, I think more about the DevTools than I do web platform features.
There is the Apple-is-restrictive angle (fair enough), but also the Apple-is-slow angle here. Slow is a relative term. Slow compared to what? Slow compared to Chrome. Which begs the question: why does Chrome get to dictate the exact speed of the web? I always think of Dave’s “Slow, like brisket.”
There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can check your gut instincts and validate your hypothesis before incurring mountains of technical debt.
I think just enough iteration before a release produces better products. Because once it’s out, it’s out. There’s no turning back or major API changes.
Maybe a slower-moving web is frustrating sometimes, but does it mean we get a better one in the end? My baby bear brain tells me there is a just right somewhere in the middle.
Direct Link to Article — Permalink
The post Progress Delayed Is Progress Denied appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.