Comment by darklion | Hacker News Reader

Comment by darklion | Hacker News Reader

Parent Full thread

> number of web standards only Safari hasn’t implemented is many times bigger than those of Firefox and Chrome

Is that actual web standards, or just what is listed on caniuse.com? The reason I ask is that a lot of "standards" aren't actually standards:

Service workers are not yet a standard: "This is a living document. Readers need to be aware that this specification may include unimplemented features, and details that may change. Service Workers 1 is a version that is advancing toward a W3C Recommendation." (https://w3c.github.io/ServiceWorker/)

Web Application Manifest is not yet a standard: "This document was published by the Web Applications Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members." (https://www.w3.org/TR/appmanifest/)

Background sync is not a standard: "This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track." (https://wicg.github.io/background-sync/spec/)

Cookie store is not a standard: "This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track." (https://wicg.github.io/cookie-store/)

Streams is not a standard, it's just a specification: "This specification provides APIs for creating, composing, and consuming streams of data that map efficiently to low-level I/O primitives." (https://streams.spec.whatwg.org)

So does Safari suck because it's not supporting actual standards, or does it only suck in comparison to Chrome because Chrome is willing to implement technologies that aren't finalized standards and technologies that aren't even on a standards track?

It is pretty funny to defend Apple (or any other browser vendor) using the argument that standards are unfinalized. Running living standards was the coup done by WHATWG, a.k.a. browser vendors.

https://whatwg.org/faq

> The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML, and apparent disregard for the needs of real-world web developers. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

Darn it, XHTML could have been so good if it got mass adoption! It would simplify parsing content and personally, working with XHTML is sane and easy (albeit in a somewhat dated Java stack with JSF/PrimeFaces, which build upon it). It also gets rid of the inconsistent tags in HTML which can remain open, which i think is a good thing.

Then again, i also like XML, maybe to the point of sometimes preferring it over JSON (or at i would if the ecosystem would be there - WSDL was leaps and bounds ahead of OpenAPI/Swagger, but seems like the interest in XML died down), so i don't doubt that many don't feel that way about all of it.

HTML5 has an XML serialization, so if you really must you can use XHTML5 today.

But I think for most people it is in general a bad idea. XHTML parsed as XML means that anything that mashes together strings to generate a webpage, like much of webdev, is prone to generating invalid XML due to bugs in the code, and this in turn leads to catastrophic failure where the page doesn’t just have errors but fails to render entirely. During the period where people were swayed by the XHTML proponents’ arguments it was commonplace for me to visit a website and see only an XML parsing error.

XHTML parsed according to custom rules that are forgiving for errors yet consistent and straightforward to implement would have been a good idea, but nobody implemented it to my knowledge. Luckily HTML5 does specify such a forgiving parsing system, where pretty much any random sequence of bytes can be parsed consistently.

Not only that, XHTML already had the ground work for web components.

XML is pretty much alive in the .NET and Java ecosystems.

There is nothing easy about XHTML. Or rather it is only easy if you ignore the essential parts of it.

The sell of the time to jQuery webmasters was:

XHTML's complexity is too much to deal with and the WHATWG is going to keep all this unnecessary stuff out so you won't lose control to generalized tools like an IDE and systems that favors formally educated language/tool writers, i.e. schema validators and, as we see now, transpilers.

The end result is still everyone using an IDE perhaps due to more irregular features after WHATWG encouraging a framework, but at any rate demonstrating XHTML was not the real source of webmaster stress and future angst.

So now you have more complexity, a still pointlessly irregular format that needs to identify it's magical elements, and, (to get back on topic,) features that must be implemented first in 2 browsers to become standard.

All of this is brought to you by employees of Apple and the other vendors. If WebKit isn't one of the 2 implementations most people choose to work with when pushing a standard then Safari is the dead implementation due to a constellation of choices all made with Apple's support and approval.

Only if one insists in writing it using vi.

Let's not go there.

Show us a vi plugin that can do as well as IDEs and UI designers for edit XML, including validation and XSLT debugging.

I wasn't going there, but then with such an interesting reply I might.

Even caniuse lists those with an UNOFF (that is, unofficial) marker.

Just because Chrome rammed some of its internal API through standards bodies, released it in stable, and called it a standard, does not a) make it a standard, and b) mean that other browsers should rush to implement it. No matter how many HN commentators think otherwise.

Safari sucks because it's only available on macOS.

It's really annoying when doing web development, especially as that's actually the browser that has the most chance to act different from the others.

Also, pisses me off that I need an Apple account to install Safari extensions.

And I need freaking XCode 12 (which requires Big Sur) just to convert my chrome extensions into Safari extensions. Just endless headaches for a simple task.

And iOS also. At least on macOS I can use any other browser. On iOS I can only use Safari (either directly or under the hood).

Not impossible to compile WebKit for other platforms, but sounds hairy. https://schepp.dev/posts/running-webkit-on-windows/

WebKit is not Safari. Someone on my team complained about the UI being broken in Safari. I debugged on Epiphany[0] which is also webkit based, it was broken in a slightly different way. After fixing it, it was still broken in Safari.

If you want to be sure that something works in Safari, you have to test in Safari...

[0]https://gitlab.gnome.org/GNOME/epiphany

You could just use Steam, afaik they’re still using WebKit and you probably have it installed anyway ;)

Or another WebKit based browser (ok, not so many): https://en.wikipedia.org/wiki/List_of_web_browsers#WebKit-ba...

Steam has never used WebKit. They use CEF (Chromium).

Ok looked it up: Steam switched to CEF in 2010 (announcement read „WebKit based“), CEF3 with Blink was considered stable and recommended in 2013. So they probably used a WebKit base for at least these three years. But, unless they still use CEF1, it’s not WebKit anymore today.

Are they using an old, pre-Blink version?

..for Windows ? - Flock (version 3.0 and above) uses WebKit.. but the final release 3.5.3 was in Feb 2011 after:

Zynga Buys Social Web Browser Flock, Jan 2011, https://mashable.com/archive/zynga-buys-flock

Facebook and Zynga Enter Into Long-Term Relationship, May 2010, - (nothing left)

Gnome Web on Linux (WebKit based) is sometimes a close enough approximation to troubleshoot Safari issues, but yeah, it sucks.

Safari : The new Internet Explorer (smh)

You can download Safari for Windows. I don’t know why you would, but you could.

No. You cannot. You would do it to test on Safari. Except you cannot.

> Apple no longer offers Safari updates for Windows. Safari 5.1.7 for Windows was the last version made for Windows, and it is now outdated.

https://support.apple.com/en-us/HT204416

I have a MacBook sitting on my desk that I only ever use to test something in Safari.

I misunderstood. I thought someone said Safari on Windows didn’t exist. I wasn’t aware it was discontinued; thanks for that info!

I could have specified. "recent versions" ;)

Back when it was available, because the designer on the customer team is the only person with an iPad and somehow the rendering bugs on Safari need to be fixed for his milestone approvals.

Counterpoint: I don't think it matters much if something is final or not, because what matters more is market adoption.

Second, especially with HTML5 and Javascript I believe, they don't do big, formal versions anymore, but evolutionary and incremental design. This prevents a lot of administrative and bureaucratic overhead (see also Java's standardization process and stagnation after 6), at the cost of having fixed targets to work towards.

Or, to take it a step further (and in a slightly different perspective):

Does Safari suck because it's not supporting actual standards, or does Chrome suck because it's trying to make sure that the web only works on Chrome, like Microsoft did with IE 20+ years ago?

> Does Safari suck because it's not supporting actual standards, or does Chrome suck because it's trying to make sure that the web only works on Chrome

This is a weird argument when Firefox supports many of the standards that Safari doesn't, as well.

It's not really weird at all, that's actually what happened with IE. It wasn't that IE was lacking but people used it anyway, IE was doing really cool stuff but in it's own way.

AJAX is one example, IE introduced XMLHttpRequest back then and it took 15 years to become a standart. So people built their cool websites around IE features that were not actually standards and once Microsoft screwed up IE people found out that you can't switch to alternative browsers because websites were built to support IE.

As the IE experience degraded(has become famous for crashing and taking the OS with it) and there was a room for improvement, Netscape become Mozilla and they introduced actually good browser that later will become Firefox but because most people used UI, web developers had to accommodate IE by writing IE specific code everywhere. That's where the hate for IE comes from, it wasn't fanboys hating IE, it was developers hating IE because they had to write extra code all the time.

Firefox may support some Chrome features but how sure you are that Google will keep making a good browser? For many, Chrome is already a degraded experience for what it was and it is actually very nasty in favouring Google properties and tracking that can be a disaster if switching away from Chrome becomes as hard as it was with IE.

Or is Firefox willing to compromise on more technologies that aren't yet standardized than WebKit is?

Without knowing whether the "standards" being tested are actually standards, it's impossible to know.

Firefox has been copying Chrome for a long time now. Either Mozilla doesn't believe that they have the market share to succesfully challenge those "standards" (I think its the other way around, they keep loosing market share because anyone who wants Chrome uses Chrome) or they don't want to risk their primary funding source. Either way, something being implemented by Firefox does not mean that WebKit has to implement it too.

not some of the tools are propose or standard some of then from Mozilla foundations and try to be implemented safari tend to implement standard a lot more slow than the other because this isn't the core business, and let browsers do more things and you don´t need to use the app store.

Mostly because it is the only way to still be relevant, and as the charts prove it is not doing a great job at it. Typing this from FF by the way.

I think blindly copying Chrome in so many ways is actually making Firefox less relevant.

Or Apple makes piles of cash from the app store. So having a native like app experience on web tech hurts their bottom line.

I keep hearing that BS argument. Do we have a "native like app experience on web tech" on Android?

Have people given up mobile apps (native or wrapping WPAs) there and use web apps on Chrome on Android?

Didn't think so....

Oh, and would you also be happy if your native apps on Desktop were replaced by more Electron?

I almost exclusively use web apps. I can't remember the last time I installed an actual native app. It's been at least a year.

Anecdotal evidence but I use plenty of websites where native apps are available.

EG Social Media, Google search, news websites, Youtube.

> web apps on Chrome on Android

I don't bother installing the web apps, but access them as websites through my mobile web browser (Firefox Android).

devil's advocate: Safari is too good for performance so they can replace native app experience, meanwhile sadly Chrome isn't.

Safari haven’t actually beaten Chromium in most performance benchmarks for a while now.

https://twitter.com/slightlylate/status/1485387199738642432?...

ref: https://httptoolkit.tech/blog/safari-is-killing-the-web/

Counter ref: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

More like Safari sucks because Apple wants people to buy native apps from its store. A lot like Microsoft wanting the web to suck so people would buy Windows apps instead. It's not a super secret conspiracy that requires inside knowledge and a network of spies to figure out.

This is such a lame argument. You want it to be true but have no evidence that it actually is true.

A lot of the Chrome team's "standards" have problems with accessibility, workability on mobile, security[0], privacy[1], or just battery life. Some are neat experiments that are or only will be used in the wild by advertisers to track and identify users.

Because the Safari/WebKit team doesn't have to chase users for revenue like Mozilla does they can afford to be more conservative with what Google "standards" they support. Being able to offer a tighter privacy posture or efficiency is part of the iOS/macOS sales pitch.

[0] https://github.com/WICG/webusb/issues/50

[1] https://www.theverge.com/2021/4/16/22387492/google-floc-ad-t...

Safari implements different behavior on desktop vs mobile. They support push notifications on desktop but not mobile, they support large offline storage on desktop but not mobile. What convincing argument exists for this dichotomy except that they want to force people to ship on mobile through the app store?

Desktop Safari has a much different power domain than mobile Safari as mobile has alway-on cellular radios (in the nominal iPhone case). iOS has a very power optimized push notification system run through Apple's infrastructure. Notifications for a device are coalesced and sent as a batch to keep the background power of the cellular radio as quiescent as possible as often as possible. It's the same reason there's a background processing API. The notification and background processing APIs also work on iOS where an app can be jetsamed at any time. There's no swap on iOS. Web notifications aren't compatible with iOS' background processing policy and there's not a good way to make them so.

Desktop Safari doesn't have a cellular baseband to worry about. Even the wake-briefly-from-sleep-to-check-email feature in macOS is only activated when the Mac is on a wired or previously joined WiFi network. It doesn't randomly blast signals in your backpack on the subway trying to check e-mail and notifications draining the battery. There's also not the same jetsam policy on macOS since it does support swap.

Batteries have finite power density and an iPhone has a finite volume for a battery. So there's only so many watt/hours that can fit into an iPhone. Unrestricted background network/processing means much reduced battery life. That's a bad thing for a phone. It's doubly bad for a device that's a device that's also an electronic wallet and navigation aid.

Smartphones aren't laptops and neither phones or laptops are desktop systems constantly plugged into mains power. A system that makes sense for a desktop on mains power plugged into Ethernet with 32GB of RAM and essentially unlimited swap does not necessarily make sense on a battery powered device with only radios for connectivity and a fraction of the RAM and no swap.

But I get it, Apple Bad and everything they do is a vast conspiracy.

Chromium IS the standard. Firefox knows this and implements what Chromium supports. Safari doesn't, so Safari is the new IE. If you don't believe me, search for the phrase "is Safari the new IE" and see what web devs have to say about it.

> Chromium IS the standard. Firefox knows this and implements what Chromium supports.

This is untrue. There are many cases where Firefox has decided not to implement something Chrome has. Here is a list of specifications that Firefox does not yet implement but has considered:

https://mozilla.github.io/standards-positions/

Many of the ones listed as “harmful” are implemented by Chrome.

> Safari is the new IE. If you don't believe me, search for the phrase "is Safari the new IE" and see what web devs have to say about it.

I’v been developing for the web for over 20 years and that’s total nonsense. There’s nothing that makes a developer stand out as inexperienced quicker than saying that Safari is the new IE. It just shows they have no conception at all about how Internet Explorer held the entire frontend development world at a standstill for five years. Safari on its worst day is nothing like Internet Explorer.

Except that IE was never both faster and more battery friendly than the competition.

IE6/7 launch times were much faster than Firefox (this was important before SSDs were common) and general performance was better on IE. I used Firefox for about 15 years mostly because of it's ad-blocking capabilities, even though it was generally a slower browser than IE. IE was "slow" only after Chrome became a thing... which was faster than IE. Firefox wasn't.

Having said that, in this context, these things don't matter at all. You can make a barebones browser which only supports HTML and CSS and get several fold improvements in battery life and performance. That is why IE was bad. It did not support newer better functionality that other browsers did.

Reply on news.ycombinator.com