Hacker News new | ask | show | jobs
by sanxiyn 1286 days ago
> Apple cares about making a browser that renders web pages just adequately enough to be acceptable

I think this is biased. It's closer to "Apple cares about rendering currently existing web pages superbly" while "Google also cares about rendering future web pages".

Once upon a time, V8 won benchmarks and ran demos faster but JavaScriptCore rendered the web faster. This was mainly due to JavaScriptCore having an optimized interpreter and V8 lacking one, and actually existing web at the time didn't execute JavaScript long enough on average to compensate for JIT overhead.

3 comments

The second part of that quote is that the real work happens in apps.

Safari doesn't properly enable PWA features on purpose. So, 10 years later, that's more correct than ever. Anything that can be used to replace an app would see strategically slow or non existent adoption.

Apple breaks existing web sites all the time.

I have reported several rendering bugs. Those are usually fixed in a year or so.

But you cannot update Safari without iOS update, then those sites stay broken for years.

Exactly. This bug (broken overflow:hidden for rounded corners) took 11 years to be fixed. But how long from will it take until we can assume that all iOS users will have a Safari version that does not require the dreaded isolate workaround.

https://bugs.webkit.org/show_bug.cgi?id=68196

Also, I have the feeling that there is exactly ONE person working on Safari. I always run into the same same when reporting or browsing bugs. I hope that this is either an alias used by many developers or the poor guy is making a ton of money.

It's hard to speak for Apple why Safari is where it is.

Pro: battery life

Con: lagging behind on some features

The fact that lack of Safari features drives people through taxed AppStore is just an accidental Apple side effect right? ;)

Google is utterly evil for driving people towards web Ads for profit, while Apple drives people into their 30% tax AppStore by pure altruistic battery concerns?

It seems more like a difference of vision. Apple has a popular desktop and mobile OS. It's fundamental to what the company is. For Google they have Android on mobile, but ChromeOS didn't take off in a big way on the desktop, so Chrome has become their desktop "OS" in effect.

From Apple's perspective a lot of stuff being added to Chrome is just duplication. They have a competent desktop OS already and it's not cheap to build, so why would they get talked into building what amounts to a second competing OS just because it suits Google? It's maybe like asking why Google doesn't build super slick native Mac app equivalents for everything they offer. Why isn't there a native Google Maps app on macOS for example? Of course from Google's perspective that sounds unreasonable - they've got their own platform and would rather use it, why would they invest so much into Apple's? It's sort of the same thing but in reverse.

Google did build Google Earth for macOS. I am not sure whether this supports or opposes your points. Probably supports.
Google Earth was an acquisition and long pre-dates Chrome. They later phased it out in favor of a web app which, IIRC, at first only ran in Chrome.
I tried to avoid speculating.

I believe we agree: control is a strong ulterior motive with both pros (prioritizing privacy; Flash is dead) and cons (native app required for important functionality).

Indeed, battery life shows Apple's goal is being superb, not adequate. For features, that's what focusing on currently existing web is about, instead of future possible web.
The Safari team has been killing it in interop-2022.[0] They've not only improved the most (and are currently leading) but was also way ahead on certain features like the new color spaces.

[0] https://wpt.fyi/interop-2022

> For features, that's what focusing on currently existing web is about, instead of future possible web.

The reality is, of course, much more complex.

For example, once upon a time Apple wanted web components to be declarative: https://twitter.com/rniwa_dev/status/1352322006448947203 And yet Google was "move fast and break things" and here we are 10 years later with Declarative Shadow DOM struggling to become a thing.

However, this aggressive push did surely help Google to sabotage Mozilla when they kept the abysmally slow polyfill for the deprecated v0 of Custom Components spec on Youtube for ages.

This also applies for the many, many, many features of the "future possible web" that both Apple and Mozilla increasingly object to (anything from hardware APIs to web-component-related bullcrap Chrome churns out every day it seems).