Well.. now Safari still is the hated browser to support, instead of IE, because of Apples backwardness
For a while the web view they were making apps use was lagging way way behind Safari itself- was just dog slow & utterly unaccelerated[1], but they finally at least ship moderately capable webviews in iOS now. That was a solid half decade of brutal tyranny- anything trying to use the web platform at all had a terrible time, & alternative browsers were a sick laggy disgusting joke.
This is one of the biggest sorest points about Apple's complete dominion over iOS & their rule by app store (for many): this titan don't even allow healthy competition on the web. They hold the whole web back. Safari would feel like far less of a villianous poison if Apple didn't rule iOS with a bloody iron fist.
[1] http://9to5mac.com/2014/06/03/ios-8-webkit-changes-finally-a... https://news.ycombinator.com/item?id=7843943 (12 points, 8 years ago, 1 comments)
Now, would allowing other rendering engines be better for iOS? I ultimately think it would, but also can understand Apple's stance of wanting to enforce the most performant, secure and energy efficient rendering engine on something as sensitive to these parameters as a mobile phone.
The roll of the webview is more than webkit rendering. It encompasses the javascript engine, all it's capabilities, it includes many many many of the platform APIs. I'd be interested to hear if Chrome or Firefox or any other iOS browsers implement any web apis on iOS that aren't present in Safari, but I doubt it, and I'm not sure whether that's a hard web view limitation.
I think we're trying a little too actively to promote a sense of significant diversity here, where there is in fact a harsh & brutal monoculture. Yes, the user chrome is different. Bookmarks, history, settings & sync sound like the main differences. But fundamentally users are still trapped with a a browser that makes extremely fantastically conservative decisions that they cannot possibly escape from.
> wanting to enforce the most performant, secure and energy efficient rendering engine
Energy efficiency is indeed pretty good on Safari desktop, but there's also plenty of tests that will show Chrome winning. It's impossible to compare on mobile, because Google can't develop for iOS.
I'd be hard pressed to accept accepting Safari as more secure or more performant[1]. Especially as we continue to advance, Safari just doesn't have modern web features. Web bundles? Nope. Early-hints? Modern web optimizations just aren't possible.
[1] https://www.theverge.com/2022/3/7/22965756/google-chrome-app...
Performance wise, Chrome/Blink had a brief lead in March but since WebKit has again surpassed it. Currently WebKit is about 10% faster on macOS.
Security wise - when is the last time you had to update your iPhone/iPad because of a security issue in WebKit? Even on desktop, check the rate of Chromium security vulnerabilities vs WebKit.
> I think we're trying a little too actively to promote a sense of significant diversity here, where there is in fact a harsh & brutal monoculture.
As someone building a macOS/iOS browser I can say that WebView != Browser. There is so much to be built around a rendering engine for something to be considered a browser today.
> Safari just doesn't have modern web features. Web bundles? Nope. Early-hints? Modern web optimizations just aren't possible.
This is not always true.
Yes I am cherry picking, but so were you ;)
Also consider that most users these days do not care about web bundles or early-hints. They care about speed, security, battery life and privacy. I feel as WebKit delivers on these essentials and is a good base for a browser. Having Blink/Gecko on iOS may bring a web feature or two but is also sure to compromise on other things.
I've also heard no such claims, seen no evidence Safari has found new vast wins to "beat" chrome on, whatever that means.
I think it's also absurd that we accept such primitive rankings in the first place, although I myself have shared some of these reductionist claims. Fast at what? There's so many different conditions, so many things we could measure. Is Safari the fastest WebGPU engine? Are they best time-to-first-paint? For what kind of site complexities? Is there JS or just pure HTML? Apple themselves invented Speedometer- an interesting & creative test of loading a lot of different TodoMVC apps, one after another- and for a while dominated it, but Chrome continues to excel[1] (day old article). What data were you looking at, if any, or just heresay?
One category I'd point out: I haven't heard a single web-game developer ever thank Safari for anything. These people deserve good treatment, are doing great work. Safari isn't helping them, isn't fast there.
(Also props to Chrome for optimizing on a brand new platform that they have had far far less time to optimize for.)
> As someone building a macOS/iOS browser I can say that WebView != Browser. There is so much to be built around a rendering engine for something to be considered a browser today.
As a web site developer, it all looks like the same shitty, low feature, piece of crap turtle that doesn't implement shit. I can offer my users no more features on your browser than any other turd bucket WebView based browser. It's not your fault, the platform is just deficient, grossly.
As for wpt.fyi interop testing, I dig it. There's some very good stuff Safari is up to, thank you for sharing. Better colors is excellent. I would note however:
> These scores represent how browser engines are doing in 15 focus areas and 3 joint investigation efforts.
This seems to be 100% only agreed upon areas, where each browser already has some stake. It's all rendering, not platform features. So we basically ignore the fact that Safari doesn't have web bundles, doesn't have early hints, doesn't have http3, doesn't have gamepads, doesn't have midi. I'm barely getting started. Safari isn't always- but quite quite frequently is- an obstacle to modernity.
> Also consider that most users these days do not care about web bundles or early-hints. They care about speed,...
These two statements contradict. Webbundles and early-hints are techniques for performance optimization. I'm willing to bet by 2030 Safari is dragged into doing the right thing here, but right now they keep the web slow.
[1] https://9to5google.com/2022/06/06/chrome-mac-speedometer/
On macOS there is only one benchmark used by all sides to determine the 'fastest browser' title - Speedometer 2.0 benchmark.
It is used in Apple's marketing [1] and in Google marketing [2]
Blink had a brief lead in March when it reached 300, WebKit overtook, the just a few days ago (and a day before WWDC) Google claimed new best score (360 - I was not able to confirm [3]).
[1] https://www.apple.com/safari/#footnote-1
[2] https://twitter.com/googlechrome/status/1533524079717892098
[3] https://twitter.com/vladquant/status/1534301507566202880
FWIW, Speedometer started with & always seemed like an Apple specific test. It greatly favors low optimization paths, because it's just loading app after app after app. It's basically not worth having optimizing compilers, because Speedometer is just testing initial load speed, more or less.
That's a valid number, and I love that others (like Chrome) accept the thrown gauntlet as is, withiut protest, & compete. But this is not really indicative of what life will be like after the first 2s. Maps (or any other app) may run way way faster on an engine that focuses more on optimizing compilers.
Thanks though, thanks for the links. Im not trying to invalidate this. But I do think it is limited, I do think it's origin & what it tests is worth noting in here. It's only one way of looking at performance.
Really doesn't help that they've pull so far back from open standards. They used to champion OpenGL, OpenCL, and open web standards, now they are working like Balmer's Microsoft. Everything internal and they sabotage open standards. Either by not implementing them, or obstructing all evolution at the standards committees.
People forget that Microsoft disbanded the IE dev team from 2001 for at least 5 years - IE6 remained unchanged from 2001 to 2006 and received absolutely no feature updates, HTML rendering or JavaScript engine changes during that time (though there were security patches). The next version of IE wasn't until IE7 was released to coincide with Windows Vista in early 2007.
5 years between major versions! No browser since then, developed by Google or Apple (and even now, Microsoft) has had a gap that long without feature updates.
Evidence ? Pretty extraordinary claim to make.