Live data from Hacker News

Progress Delayed is Progress Denied (Safari feature lag)

infrequently.org

11–20 of 31 posts

Re: Progress Delayed is Progress Denied (Safari feature lag)

#11

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...

Re: Progress Delayed is Progress Denied (Safari feature lag)

#12
>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...

Re: Progress Delayed is Progress Denied (Safari feature lag)

#13
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.

Re: Progress Delayed is Progress Denied (Safari feature lag)

#14

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…

Thank god iOS doesn’t have vibration support, we simply don’t want it

Re: Progress Delayed is Progress Denied (Safari feature lag)

#15

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'…

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/

Re: Progress Delayed is Progress Denied (Safari feature lag)

#16
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/

Re: Progress Delayed is Progress Denied (Safari feature lag)

#17
post #10

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…

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...

Re: Progress Delayed is Progress Denied (Safari feature lag)

#18
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.

Re: Progress Delayed is Progress Denied (Safari feature lag)

#19

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 prefe…

> 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.

Re: Progress Delayed is Progress Denied (Safari feature lag)

#20
post #10

Earlier quoted context omitted.

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…

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 reasonabl…

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.
Post reply on HN