Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progress Delayed is Progress Denied (Safari feature lag)

infrequently.org

Post reply on HN
Print view View original

21–30 of 31 posts

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

#21

Post by HenrikJoreteg »

rubatuga wrote: post #14
montroser wrote: post #11

Earlier quoted context omitted.

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

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.

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

#22

Post by HenrikJoreteg »

alpacaillama wrote: post #6

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…

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?

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

#23

Post by chrisandchris »

HenrikJoreteg wrote: post #22
alpacaillama wrote: post #6

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…

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

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

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

#24

Post by K0nserv »

chrisandchris wrote: post #23
HenrikJoreteg wrote: post #22

Earlier quoted context omitted.

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

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

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

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

#25

Post by rsj_hn »

alpacaillama wrote: post #6

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…

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.

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

#26

Post by bagacrap »

fragile_frogs wrote: post #19
musicale wrote: post #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 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.

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.

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

#27

Post by ksec »

rubatuga wrote: post #14
montroser wrote: post #11

Earlier quoted context omitted.

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

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.

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

#28

Post by kaliszad »

Yes, Safari is a pain. There are other and much bigger pains in the browser ecosystem in general, let me give some examples:

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

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

#29

Post by eyelidlessness »

ShinyNewFeature wrote: post #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…

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

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

#30

Post by eyelidlessness »

alpacaillama wrote: post #9

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.

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