Progress Delayed is Progress Denied (Safari feature lag)(infrequently.org)
infrequently.org
Progress Delayed is Progress Denied (Safari feature lag)
https://infrequently.org/2021/04/progress-delayed/
30 comments
It is quite a racket. I don't believe they set out to actively harm the web and open standards, but when they make _such_ a killing on app store profits, it must limit the incentives and motivation to invest in Safari/WebKit
Look at webkit.org and tell me if you see evidence that apple isn’t working on it.
Yes, they absolutely _are_ working on it.
I appreciate that `gap` is finally supported in the context of `flex`. I appreciate that WKWebView finally supports `getUserMedia`. The compatibility lines in the graphs from TFA are not totally flat, it's true.
But still -- Apple, one of most well-resourced companies in the world, lags far behind Mozilla, a modest non-profit.
I appreciate that `gap` is finally supported in the context of `flex`. I appreciate that WKWebView finally supports `getUserMedia`. The compatibility lines in the graphs from TFA are not totally flat, it's true.
But still -- Apple, one of most well-resourced companies in the world, lags far behind Mozilla, a modest non-profit.
Surprising that this isn’t getting more upvotes. It’s a very interesting read.
Interesting to note that the author never mentions one of the biggest criticisms of the Chromium project. That they keep adding so many APIs that other browser vendors are forced to follow them instead of what they want to work on. This has been less apparent on mobile because Safari has a large share but not on desktop. The chromium team is known to build things that the standards body doesn't agree on, ship it, and every other vendor is forced to support it because of Chrome's huge marketshare on desktop otherwise their browser will appear "broken". They're angry that they can't do this on mobile.
Then by all means, don't use it.
The point is that Apple's policies don't allow other browsers to actually compete on their platform. So users don't get to make the choice. All browsers on iOS have to be WebKit based by explicit policy that's the issue at hand.
It sounds like you like the default choice, and that's great for you. But if it's truly better, they shouldn't be scared to allow users to make a difference choice for themselves, no?
The point is that Apple's policies don't allow other browsers to actually compete on their platform. So users don't get to make the choice. All browsers on iOS have to be WebKit based by explicit policy that's the issue at hand.
It sounds like you like the default choice, and that's great for you. But if it's truly better, they shouldn't be scared to allow users to make a difference choice for themselves, no?
I think it‘s less about being truly better and more about who defines the standard.
If Chrom(ium) is going to win on Mobile, Google will basically dictate the W3C and that will end very badly. Id already ended very bad once, when IE was „The Standard“.
If Chrom(ium) is going to win on Mobile, Google will basically dictate the W3C and that will end very badly. Id already ended very bad once, when IE was „The Standard“.
I agree with this analysis. I just wrote a comment in an a different thread(which links to a Twitter thread I wrote in response to the OP)[0] about it. Chromium becoming even more dominant on the web cannot be a good thing. It means handing over too much power over the web to a company, Google, that is not aligned with the interest of the open web.
Apple's tight control over browser engines on iOS seems like the lesser of two evils to me. My impression is also that Apple and Mozilla have been actings as checks on Google in W3C and other standardisation bodies e.g. John Wilander[1] from Apple/Webkit.
0: https://news.ycombinator.com/item?id=27024457
1: https://twitter.com/johnwilander
Apple's tight control over browser engines on iOS seems like the lesser of two evils to me. My impression is also that Apple and Mozilla have been actings as checks on Google in W3C and other standardisation bodies e.g. John Wilander[1] from Apple/Webkit.
0: https://news.ycombinator.com/item?id=27024457
1: https://twitter.com/johnwilander
It's not just about safari not adding support for new APIs, but intentionally breaking old APIs. A lot of websites that used to work on safari no longer work, due to their war on tracking and advertising.
Say you are in myCity.gov and you have a website that loads dashboards. These dashboards are iframes that come from anotherDomain.gov, thirdDomain.gov. Well, in Safari they're not going to load because iframes no longer send cookies back to their parent origin unless the iframes are a subdomain of the parent domain. They just broke a thirty year old web standard. That's a massive breaking change introduced by Safari, that makes many corporate intranets and cloud-based delivery sites not load properly in safari. And has nothing to do with not supporting a new vibration API. This is basic old school web semantics that Safari has been breaking right and left because they can't conceive of the internet as anything other than a content-marketing platform.
The web is now used for pretty much everything, and large swathes of it don't load properly on Safari. They don't care, because people mostly use Chrome on the desktop and Safari on their phones, and people have come to expect apps for the content delivery on phones. But this drives the bifurcation further, and solidifies the chrome-only nature of many websites because they are not going to remap their domains to something Safari will approve of in order to get iframes to load properly.
Say you are in myCity.gov and you have a website that loads dashboards. These dashboards are iframes that come from anotherDomain.gov, thirdDomain.gov. Well, in Safari they're not going to load because iframes no longer send cookies back to their parent origin unless the iframes are a subdomain of the parent domain. They just broke a thirty year old web standard. That's a massive breaking change introduced by Safari, that makes many corporate intranets and cloud-based delivery sites not load properly in safari. And has nothing to do with not supporting a new vibration API. This is basic old school web semantics that Safari has been breaking right and left because they can't conceive of the internet as anything other than a content-marketing platform.
The web is now used for pretty much everything, and large swathes of it don't load properly on Safari. They don't care, because people mostly use Chrome on the desktop and Safari on their phones, and people have come to expect apps for the content delivery on phones. But this drives the bifurcation further, and solidifies the chrome-only nature of many websites because they are not going to remap their domains to something Safari will approve of in order to get iframes to load properly.
[deleted]
Also the author never really addresses if the API is needed or not, or if it provides a good experience. If Chrome has it, it is seen as a positive. Personally, i'm very happy that PWAs can't spam me with "You left something in your cart" notifications on iOS.
So don't allow those notifications. I can easily see the existence of a catch-all deny everything by default as well. Safari on desktop happens to have this feature--showing Apple isn't categorically against its existence, as long as it doesn't help undermine their app store monopoly--will occasionally ask me for notifications and, somehow, I always deny them... maybe I have more willpower than you? Just because you have some personality flaw that prevents you from disabling a feature you don't like shouldn't mean that everyone else in the world needs to do without having that feature ever. In a world where Apple doesn't just make quality judgements on content but also makes legal judgments and even moral judgments--being so anti-porn as to be downright misogynistic with an anti-breastfeeding stance--this is a reasonable feature to exist on the web platform, and no one is forcing you to use it.
The challenge is that the notification acceptance rate is so low on mobile devices that it makes it meaningless to implement such features [1]. Practically, user is most likely to accept notifications from sites that they interact with a lot. Those also happen to be the sites whose app user is willing to install. Thus, the notification feature on web is not something that a lot of users require.
> This is a reasonable feature to exist on the web platform
Not really? [1] indicates that notification prompts actually result in users navigating away from webpages clearly demonstrating that this is a user hostile feature.
[1] https://blog.nightly.mozilla.org/2019/04/01/reducing-notific...
> This is a reasonable feature to exist on the web platform
Not really? [1] indicates that notification prompts actually result in users navigating away from webpages clearly demonstrating that this is a user hostile feature.
[1] https://blog.nightly.mozilla.org/2019/04/01/reducing-notific...
As pointed out in the linked article, the stats conflate unwelcome/unrequested notification prompts (e.g. Reddit, which pops up the prompt the first time you open the website (or used to anyway)) and cases where the user explicitly requests/opts in to notifications. I feel like the latter is something that proper web apps that don't utilize dark patterns could make very good use of. Consider the 85% acceptance rate for the camera/microphone prompt; few websites request camera/microphone permissions in the same intrusive way as they request notification permissions, hence it's not declined as often.
Also interesting to note, that some of those APIs are still in W3C drafts. So Chrome just went ahead and wrote its own implementation without the literal standards body agreeing or disagreeing on them. Again, this author is extremely biased and I don't think this article is an informative take for anyone.
I don't know -- this write-up and visualization completely aligns with my experience building mobile web apps.
Over the past few years, I have been for real disappointed that Safari did not support: Vibration API, Push API, ResizeObserver, AudioWorklets, and on and on.
And then the product people say, quite reasonably, "Well, I guess we'll just need to build a native iOS app and pay the 'Apple tax'". Over which I don't think Apple are shedding many tears...
Over the past few years, I have been for real disappointed that Safari did not support: Vibration API, Push API, ResizeObserver, AudioWorklets, and on and on.
And then the product people say, quite reasonably, "Well, I guess we'll just need to build a native iOS app and pay the 'Apple tax'". Over which I don't think Apple are shedding many tears...
Thank god iOS doesn’t have vibration support, we simply don’t want it
Any mention of specific APIs misses the point.
It's fine if they want don't want to implement everything.
The point is that if they don't get to simultaneously say:
1. The Web is a viable way to compete with native apps (which they explicitly said in defense in a current court case). 2. While not implementing features necessary to compete. 3. While not allowing anyone else to build a browser for iOS that implements the features necessary to compete.
It's fine if they want don't want to implement everything.
The point is that if they don't get to simultaneously say:
1. The Web is a viable way to compete with native apps (which they explicitly said in defense in a current court case). 2. While not implementing features necessary to compete. 3. While not allowing anyone else to build a browser for iOS that implements the features necessary to compete.
I think we could have those API only enabled for Web Apps and not within Safari. But then Apple want to push everything to native App. Which is fine if it wasn't for the curation of App Store which has some benefits and problems.
You realize a user has to give permission per webpage right? Nothing wrong with Vibration Support in the browser.
Part of the standardization process involves validating stable, compatible implementations in existing browsers. If a feature is on the standards track it can’t be accepted as a recommendation without that.
>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.
Some counter points:
1) What's an "important feature"? Whatever Chrome/Blink rushes to implement on Google's whim, and if often only a "standard" because Google designed it and pushed for it on W3C and co?
2) There are more than enough features to make most kinds of apps already. The more advanced features mentioned (like webcamera support) are all available in the native SDKs, and are more about full blown applications than about webpages. Where does it end? Do we have to replicate or at best wrap the whole native functionality and run it with several layers of indirection (DOM, JS, the browser backend, over html, etc)?
3) Android allows for web-based apps and alternative browser engines. How do those fare? Overtaking regular Android apps any time soon by any margin? If not, why would they on iOS?
I, for one, don't want to use web apps on my mobile phone. If I had the choice, I'd probably prefer not to use Electron based apps on the desktop either...
Some counter points:
1) What's an "important feature"? Whatever Chrome/Blink rushes to implement on Google's whim, and if often only a "standard" because Google designed it and pushed for it on W3C and co?
2) There are more than enough features to make most kinds of apps already. The more advanced features mentioned (like webcamera support) are all available in the native SDKs, and are more about full blown applications than about webpages. Where does it end? Do we have to replicate or at best wrap the whole native functionality and run it with several layers of indirection (DOM, JS, the browser backend, over html, etc)?
3) Android allows for web-based apps and alternative browser engines. How do those fare? Overtaking regular Android apps any time soon by any margin? If not, why would they on iOS?
I, for one, don't want to use web apps on my mobile phone. If I had the choice, I'd probably prefer not to use Electron based apps on the desktop either...
I know the author will get flak for this because this is HN, and Google Chrome has really bad reputation here (and understandably so). However, just try to develop a modern web app and you will quickly wish that all of your customers used Chrome exclusively.
And "just make mobile apps" is not the answer here. There are many situations where a web application is by far the better choice for a company or a product. It's really a shame too, because Chrome could really use some competition.
And "just make mobile apps" is not the answer here. There are many situations where a web application is by far the better choice for a company or a product. It's really a shame too, because Chrome could really use some competition.
Sort of a tangent, but on the topic of web apps, what I can't understand is how every single browser is still missing position:device-fixed [0] - if you want to let people zoom in, you basically have to recreate the entire zooming yourself if you have any sort of overlay menu whatsoever
[0]https://css-tricks.com/the-fifth-position-value/
[0]https://css-tricks.com/the-fifth-position-value/
As a user, I think what's holding back web is not the lack of APIs but how much web and browsers have repeatedly ignored user preferences, and optimized for tracking and ads.
Go to any news website and it contains tons of trackers trying to fingerprint you. Then, of course, they also have to show you tons of ads leaving at most 30% of the viewport to read any content. The web is user-hostile.
And the leading browser (i.e., Chrome) has not really done anything to solve this problem. While Safari had cache partitioning enabled for 5+ years, Chrome has still to deliver it to users even though it's a clear privacy and security win. Not just that, Chrome repeatedly keeps making decisions that hurt user's privacy and expectations [1][2][3][4].
One simple rule of thumb that I use to compare Safari and Chrome is that Safari cares about users (privacy, gating out APIs that have risk of being misued for fingerprinting), while Chrome cares about web developers (trackers, ads, More powerful APIs). As a user, my expectations align better with the former model. I would be happy if Chrome took a step back, acknowledge user's expectations and focus on progressing the privacy on the web instead of engaging in twitter wars.
[1] https://news.ycombinator.com/item?id=22236106 [2] https://news.ycombinator.com/item?id=24817304 [3] https://news.ycombinator.com/item?id=25337995 [4] https://web.dev/floc/
And the leading browser (i.e., Chrome) has not really done anything to solve this problem. While Safari had cache partitioning enabled for 5+ years, Chrome has still to deliver it to users even though it's a clear privacy and security win. Not just that, Chrome repeatedly keeps making decisions that hurt user's privacy and expectations [1][2][3][4].
One simple rule of thumb that I use to compare Safari and Chrome is that Safari cares about users (privacy, gating out APIs that have risk of being misued for fingerprinting), while Chrome cares about web developers (trackers, ads, More powerful APIs). As a user, my expectations align better with the former model. I would be happy if Chrome took a step back, acknowledge user's expectations and focus on progressing the privacy on the web instead of engaging in twitter wars.
[1] https://news.ycombinator.com/item?id=22236106 [2] https://news.ycombinator.com/item?id=24817304 [3] https://news.ycombinator.com/item?id=25337995 [4] https://web.dev/floc/
> While Safari had cache partitioning enabled for 5+ years, Chrome has still to deliver it to users even though it's a clear privacy and security win.
I had to double check, but this isn’t the case anymore. They shipped cache partitioning in v86.
I had to double check, but this isn’t the case anymore. They shipped cache partitioning in v86.
I think the article conveys a fairly narrow understanding of why Apple would want to move slowly with some features in Safari on iOS. It's a bit reminiscent of complaints about iOS Safari not supporting Flash and Java, and Apple's reasons are likely similar: partly for business reasons, but also for reasons of user experience, security/privacy, and battery life.
As an example, I like game controllers and vastly prefer them to touchscreen interfaces for most games. But Apple specifically delayed game controller support in iOS (and in Safari) to encourage developers to make games that used touchscreen controls and worked out of the box without an external game controller. The rationale was: it's a better user experience to not have to use an external game controller, and it's clunky to have to carry a controller around with your phone.
As another example, multithreaded/parallel webasm is a great feature for developers, and it could also burn a lot of power and degrade the overall performance of the system. A rationale for delaying it could be: battery life and overall system performance are more important than performance of a single web app.
At the end of the day, Apple is certainly trying to make even more money, but they are also trying to figure out what the overall best user experience will be across their entire user base. This is not the same as the best developer experience, and sometimes they are in opposition.
Developers, for their part, can vote with their feet. If they truly believe web technology is the best way to deliver apps, then they can develop for Chrome, Electron, and platforms that support the latest bleeding-edge web tech, and ignore Safari.
As an example, I like game controllers and vastly prefer them to touchscreen interfaces for most games. But Apple specifically delayed game controller support in iOS (and in Safari) to encourage developers to make games that used touchscreen controls and worked out of the box without an external game controller. The rationale was: it's a better user experience to not have to use an external game controller, and it's clunky to have to carry a controller around with your phone.
As another example, multithreaded/parallel webasm is a great feature for developers, and it could also burn a lot of power and degrade the overall performance of the system. A rationale for delaying it could be: battery life and overall system performance are more important than performance of a single web app.
At the end of the day, Apple is certainly trying to make even more money, but they are also trying to figure out what the overall best user experience will be across their entire user base. This is not the same as the best developer experience, and sometimes they are in opposition.
Developers, for their part, can vote with their feet. If they truly believe web technology is the best way to deliver apps, then they can develop for Chrome, Electron, and platforms that support the latest bleeding-edge web tech, and ignore Safari.
> If they truly believe web technology is the best way to deliver apps, then they can develop for Chrome, Electron, and platforms that support the latest bleeding-edge web tech, and ignore Safari.
Unfortunately you can't ignore Safari on iOS though, Apple only allows WebKit based browser, which makes any browser on iOS just a skinned version of Safari.
Unfortunately you can't ignore Safari on iOS though, Apple only allows WebKit based browser, which makes any browser on iOS just a skinned version of Safari.
not only webkit based, but the webkit that ships with that version of iOS. A competitor could not ship their own renderer no matter what engine it used or was based on.
- The DOM is very slow/ inefficient and has a terrible API, basically owing to the mutable, object oriented way of thinking about stuff
- Splitting up work into a WebWorker is a hassle and so it is much less useful than it could be
- There are no spring/ physical animations in CSS, so if you want pretty animations, you have to hack it together using JavaScript, CSS transform or SVG animate etc. There is basically no simple framework or library that does this in a simple and efficient way, so most of the web has the basic "curve" animations and not the accelerate/ decelerate animations modelled after a physical (dampened) spring...
- It is very hard to query the progress of CSS animations and mostly you have to just guess
- many things in the browser have a terrible API that obscures the problem and feels almost like a very special language most of the time e.g. the "History" API that actually manipulates the present and maybe creates new history as a side effect of that but has nothing to do with the history of navigation on the website/ you cannot e.g. just list the entries (not even just limited to the same origin or something like that for privacy).
- spell check is totally broken, if you want to prevent blinking, if you want to somehow manage the suggestions in the app and much, much more. E.g. it is very hard to write a Rich Text editor and basically this leads to duplication of effort everywhere, where you want to provide a good user experience without graphical glitches
- there is no int64 in JavaScript leading to all sorts of hacks a correctness problems because of these hacks, there are other similarly bad language features leading to all sorts of problems (e.g. == and === comparisons and much more)
- E.g. in Chromium, it is not clear, how search is detected on a website (without going through the massive codebase obviously). There are known bugs sitting in the bug tracker for like 7 years without progress and that is just stuff I have seen.
In general, the web seems to be missing quite a bit of rigor and feels like a hodgepodge of technologies mostly lacking in any kind of overall design and discussion about usefulness. It definitely is rather a very busy and dirty bazaar after a fire instead of even the building site of a cathedral.
There are thousands of other things that are a problem with the way web "standards" are written and implemented by browsers. Safari is a problem, but the whole discussion should a lot more focused on the origins of the problems and solving the issues methodically instead of focusing on just a broad and problematic, but single manifestation of it.