For developers, Safari is crap and outdated
blog.perrysun.com
blog.perrysun.com
This is just false, or at best only half of the story to make a false equivalence. IE was cutting edge until Firefox. The biggest problem with IE was all the insanely weird shit it did, not missing features. It would “fix” missing tags, that would then be broken on every standards compliant browser, had active x, and had an absolutely insane amount of security bugs.
Mobile safari ain’t the IE of the modern day. It’s just fucking not. I’m sorry. Chrome is closer to IE than Safari because of market share AND developers developing exclusively for it forgetting anything and everything else.
Does mobile safari still suck? Sure. But we don’t need to call it IE or constantly drone on with comparisons to IE. Let something suck in its own unique and shitty way, please.
> Apple took years to finally add WebRTC support to Safari, far enough behind Chrome and Firefox that it practically became a running joke among developers and even industry observers.
Really? Because no one I know uses WebRTC and would rather use ffmpeg and sockets to do serious work like that over a desktop application.
> But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.
Yeah, what we all need is Web Bluetooth.
Perhaps if Apple had supported WebRTC earlier their engineers could have influenced the way it works to make it better. That's the main problem with ignoring standards in an org the size of Apple - you don't get to contribute to them. I don't mind that Safari runs behind the other browsers because progressive enhancement enables me to deal with that. I do mind that Apple are failing to be a meaningful part of moving the web forwards, and are basically letting Google do whatever they like.
Are forced to use it. And millions more would be forced to use it if Safari handed it on a plate as well...
Which is why as devs we have a responsibility to save them from bad tech.
That said: "PWA: because people don't care about tech" would be an apt marketing slogan.
Are millions of developers using Widevine, too? What kind of stupid argument is that?
It's not Electron that's eating your RAM.
"Far behind Chrome" should never be used in a sentence. Ever. Chrome releases up to 40 new "standard" features once every two months, many of them are just internal Chrome APIs with a "standards spec" in the form of a draft.
Specifically for WebRTC. It was shipped in Chrome 23, in May 2012.
Guess what? Here's the timeline:
- In 2010 Google buys a company called Global IP solutions with some proprietary tech
- In May 2011 it opensources this tech
- In October 2011 publishes the draft spec
- Just 7 months later ships it enabled by default in Chrome
Do you know when the final stable spec arrived? In May 2018, full seven years later after Chrome enabled it by default.
That's why Safari had it implemented since September 2017, because the spec was finally in a proper shape.
No idea why Firefox rushed headlong into it though.
your timeline, to me, indicates less that the spec was rushed & bad, and more that it took apple 5 years to get off their hostage taking kick & finally face the music & do what should have been done years ago, which is implement. once apple did start to implent, 1.0 came soon after: because that is how specs work. companies implement, they find what's not right, & they improve, then make a 1.0.
I would definitely be interested in a changes over time review of webrtc. my feeling is that the core ideas & protocols were largely stable, but needed tweaking & elaboration, needed conformance suites elaborated. I could be wrong. this is in contrast to something like spdy, which evolved seemingly a good number of times in major ways, before ultimately getting parlayed into quic+http3.
Chrome is the new IE but with better manners if you consider the non standard Chrome specific stuff that makes websites to work only in Chrome.
Developers hated IE for not being standart, you had to write two versions of your CSS, you had to make your code accommodate the Box model differences(is the border included in the width of your DIV?) and bugs just to make the UI properly display a standart compliant HTML and CSS. You had to deal with JScript, Microsoft's JavaScript that is mostly the same but not exactly.
Due to the marketshare, Microsoft was able to push its own non-standart technology and pushed people to use IE if they don't want to be left out. This is very similar to what Google is doing with Chrome, sabotaging FF through popular Google properties like YouTube[0] and leaving out features if you are not using Chrome.
Apple may not be perfect but Google is not the "good guy" here.
[0]: https://www.zdnet.com/article/former-mozilla-exec-google-has...
My case was a WebBluetooth based download of data from a web page. Now I have to maintain two apps. Thanks.
Chrome and Android are very dominant platforms, if it is something groundbreaking that can be done in that model it would be done in Android and Chrome and Apple will adopt it. Google is not an underdog.
The website installation process is much more painful than apps because first you need to install it to see it.
For most websites you need to read and accept the tracking terms and if you are not happy with the default options you need to do custom installation.
For the majority of the websites, the next step is to decide if you like to sign up for e-mail marketing or create an account. Many will then ask you to follow them on their social media. On desktop, they will ask you to receive notifications too.
After 2 to 5 clicks you have your website installed and can start looking for the content in between the ads. They don't have much monetisation opportunities so you will get all the ads at once.
The installation is also not very persistent, if you are not using the website daily you will go through the same the next time.
I would say that if you were familiar with the web technologies you would have seen the parallels.
When you type an address of a website or click on a link your browser would download the website data from a server, which is very similar to what happens when you tap "Install".
Once your website data is downloaded, the browser would execute the instructions in that data. Usually further resources would be downloaded and, UI drawn and functions executed. This is again very similar to any apps that you run once downloaded.
Installation of an app implies making it ready to use. You can download an executable that runs right away or you can have an executable that prepares the environment for use. This is again exactly the same with visiting a website, it might be ready to use right away or in might need a set-up of the environment.
In 2021, most websites need a setup process before use, you need to set up the ways you are about to be tracked and what information is to be shared with their partners. You need to decide if you like to sign up for newsletter, if you like to follow their social media accounts and more often than not you will be required to create an account. You will be prompted to set-up notifications too, if the browser support it.
Often the native App installation is less tedious and less painful than the website installation process because the app can afford to assume that the device is a personal one and the stored data wont be erased accidentally, therefore the account creation process can be both transparent and persistent.
With native apps, you get the chance to see the app before installation(App Store pages with description, screenshots and reviews), with websites you first need to finish the installation and then you get the chance to see the website.
Anyway, I hope you see how a website could be installed and in fact is the standart modus operandi in 2021.
I avoid setup screens as much as possible. I close many of the websites linked to on HN but I'm not accepting these newsletter popups and neither should anyone else.
Websites will keep doing this for as long as people accept this behaviour. Depriving our browsers from useful features is not a solution, it's merely digging our head into the sand and pretending the real problem, problematic and aggressive marketing and data trade, doesn't exist.
You achieve a local persistence to some degree through cookies and local storage.
For example, I'm not a huge traveler (obviously not in the past year), but even before the pandemic I'd use AirBnB like once a year maybe. I don't want to download an app for something I use once a year. But before and during my trip push notifications are important because it's basically a messaging app with the owner.
I'm not talking about things like games or something else with complicated UIs, I'm talking about basic CRUD functionality where I occasionally want a push - most of my banking apps fit this as well.
Website installation process is very annoying already. I don't want more. Do I want you to track me? No. Do I want to sign up to your newsletter? No. Do I want to create account to see the links? Please no. Do I want to receive notifications? No.
I need to go through all that just to view a page on a website. Apps are much better, I don't have to install it before seeing what is it all about thanks to the App Store page that includes a description, screenshots and reviews.
If there's something that I need to be notified, websites will send me an e-mail and the mail client will show me a notification about that e-mail which will result in me being notified.
I don't like them being apps because of the amount of privilege they gain. But if every site I visit on the web gains those privileges? That's a step backwards for me.
I, on the other hand, am angry that PWA is even considered as an app model.
A regression, if I ever saw one...
Web Bluetooth is not a web standard. It’s a Google API that only Blink supports. Firefox doesn’t support it either and doesn’t plan to:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
That is absolute bullshit. Browser push notifications have been out for years on other browsers (INCLUDING desktop Safari), and they are the one thing that Apple is dragging their feet on the most because they know it's the most important thing that prevents a dev from just doing a PWA and instead has to do a native app.
This is absolutely Apple protecting their App Store monopoly.
NO
Okay, what about signing up to our newsletter?
NO
Okay, we will track you now all over the internet but if you like you can manage that.
JUST GO AWAY
Okay, btw to see the rest of the article or any of the pictures you need to create an account first.
---
Web technologist are clueless about what the Web has become. Please let browsers remain HTML and CSS viewing tools and make an app that I can review on the App Store page before committing to install it.
I hope Apple never implements website notifications on mobile.
https://support.apple.com/guide/safari/customize-website-not...
PWA's could be allowed to use things like the push API only if added to the home screen and this problem would be completely solved. You don't like browsers becoming app platforms but I am sorry to say that that ship has sailed on desktop and while Apple is fighting it on mobile, it's a fight they will lose eventually.
On the other hand I wouldn't have a problem with the model where PWA's notifications and other functionalities are limited to apps added to the home screen and the options to manage those is exactly the same with native apps. I don't advocate that all apps must go through the App Store.
Yes
Would you like notifications when someone mentions or DMs you in your work chat?
Yes
Would you like to know when you get emails?
Yes
Also only one of the things you mentioned has anything to do with notifications.
The browser is free to refuse every notification request AND make websites believe the notifications have been enabled. Unless smartphone OS vendors are kind enough, you can't do that with app notifications.
It seems you're arguing against the concept of push notifications itself, not whether the native or web app implementation is better.
The rest of them, definitely not. Interruptions are extraordinarily costly. I'll respond within a few hours and when I message you about something, I have the same expectations.
Terrible websites are no reason not to implement a feature on one platform but not another, just a reason to disable them by default. You can already do that in every decent browser, it'll ddeny access prompts without even bothering you. There's no reason to take the option away from everyone because a few people don't like it, that's what settings are for.
The service formerly known as RSS/Atom.
So, at the very least; someone was annoyed at “notifications”.
I disable all notifications for everything by default, I'll look at your software on my schedule and nobody else's.
Meanwhile Google is moving the goalposts of "modern" web development so fast that it's nearly impossible for anyone to keep up. I can't believe the hacker community is so enthusiastic about this—you couldn't get a more canonical example of embrace, extend, extinguish as applied to an open protocol.
It wasn't long ago that we had four or five really strong browser implementations. Microsoft really did try with Edge and then gave up. Now we have just three: Chrome, Safari, and Firefox. And Mozilla isn't looking particularly healthy right now...
For a second I thought you were talking about Apple’s UI frameworks and languages, with all the different Swift versions over the last couple of years and different UI frameworks like Cocoa, Catalyst, and SwiftUI, deprecation of OpenGL and introduction of their own graphics API, etc.
The UIKit was the only UI framework from 2007-2019. Then SwiftUI came and they both work very well together. As other frameworks come for stuff like graphics or device features, they don't really replace each other but stack up. On desktop, it's a similar situation.
How is the situation with the web technologies? What was the hip tech in 2007? AJAX? JQuery? What about 5 years ago? AngularJS? Meteor? Bootstarp? what about now? Is it ReactJS or Vue? What about tomorrow? Is it Svelte?
They all arrange Div's in the DOM but it's different framework each month.
Meanwhile for example you can’t use the latest iOS 15 API (SharePlay) without using Swift, and you need to learn a new half-baked declarative UI API called SwiftUI to write your own widgets. And let’s not talk about trying to run a 1999 executable today.
They all arrange pixels on the screen but it’s a different framework each month.
No one is forcing you to use them. HTML and CSS still work perfectly fine, let the people with curiosity and energy experiment. Nothing is stopping you from using browser APIs with any code you want.
There used to be frameworks specific to each platform (AppKit, UIKit, WatchKit...). SwiftUI replaces those with a cross-platform solution, but it's not all there yet.
Catalyst is basically a sort of stop-gap to let devs easily convert Cocoa Touch apps for Mac.
Long-term, SwiftUI is the only thing that will matter.
This is the single most user-hostile restriction I’ve seen on iOS.
I absolutely despise presumptious software that feels entitled to my attention as and when it chooses. I have my browser set up to wholesale reject all push notifications, I don't let the vast majority of my apps send me push notifications, and any application that feels entitled to pollute my inbox (email already has an awful signal/noise ratio as a communications medium) with useless email alerts gets uninstalled or unsubcribed from immediately. Frankly browser notifications should never have been a thing, it's just another varient of the spamdemic that plagues the modern software landscape. I'll look at your software when I choose, and if the software starts dictating that it gets removed or silenced without exception. I honestly don't understand how most people stay sane with their phones and laptops pinging and flashing away like a pinball machine all day.
Without them, I would have to regularly check the app of interest for any important updates, losing both time and mental space with another thing to keep in the back of my mind.
Thanks to push notifications, I can defer interacting with the app to when it's actually relevant.
Also as I argued in another comment [1], web notifications are simply better than native app ones. Push notifications are here to stay, the choice is in the implementation, not whether they'll become culturally accepted or not (they already are, iOS users simple are nagged to install native apps to have them).
Excessive notifications are a dark pattern which needs to be resisted, not encouraged. I'll continue blocking every single one of them and looking at apps on my own schedule, I will not allow random software to interrupt my flow because it thinks it has a right to my attention. Littering is culturally accepted too, but that doesn't mean either littering or its digital equivalent should be.
But I think you are really underselling the downsides of push notifications. They are easily the most heavily abused feature of the modern web anywhere they exist. If every single app responsibly used push notifications then sure, it would be great. Here in reality push notifications aren't some personal majordomo making sure only important issues are brought to our attention, push notifications feel more like walking down the Vegas strip having leaflets constantly shoved in your face.
I think its premature to say that we have the answer and just maybe Apple dragging their feet on this will help us find a solution that is better than the advertiser friendly free for all that Google is pushing.
Strong agreement here.
There's a significant (single digit %) of sites I run into that ask me to accept push notifications or ask for my email before any of the content loads. I usually close the tab when that happens.
This whole thing really goes to the different mindsets of Apple/iOS and Google/Android fans. The Apple camp is fine waiting for functionality to get something that is decently thought out, the Google camp wants everything now and will deal with the consequences later. We've seen this repeated with copy/paste and with background processes on both platforms. Android got there first, but the earliest Android implementations had serious limitations and issues.
Isn’t it generally accepted by both small children and adults that having a Dad is better than not?
Sure, teenagers rebel for a while against anyone caring about them, but they tend to grow back out of that as soon as they have to parent too.
On the subject of notifications in general, Apple lets their users be spammed more by not adding granular notification categories like on Android.
Your comment doesn't reflect reality. If Apple took notification curation seriously like you imply, I would seriously consider switching to their smartphones, but they don't.
If you haven’t tried it already, you may be interested in iOS 15’s new “Focus” feature set. Even tackles that last point on set up.
The exception to this are services which trick you into accepting their notifications because they are beneficial to the experience while using them (ride hailing and delivery apps), and then use the same channels to spam you with marketing (Uber, ...). For those I simply chose to disable notifications altogether and instead let the drivers call me if I'm ever late.
E-mail fits that description better, because you almost always have to give out your address to register (even with Google SSO & co), which is then used for spam and you have to opt-out after the fact.
They aren't granular though, you either opt in to all or you get none. This is particularly annoying when you're using something like LetGo or OfferUp, because you basically need to opt in to receive messages from people interested in buying your second-hand stuff. But once you do, they take the opportunity to spam you with engagement boosting ads querying you if you have anything you want to list or telling you "we've selected these sales for you."
It's an extremely unpleasant design pattern for anyone who values their own time and attention.
>I have my browser set up to wholesale reject all push notifications
I am struggling to understand the reasoning here. You don't like feature X but fortunately there is a configuration to turn it off. But you would still like it taken away from everybody else?
Perhaps I am misrepresenting your position, could you clarify?
I find the idea that everyone should be instantly available at the click of the fingers to their friends, colleagues, managers, and crapware on their phones absolutely revolting. Push notifications are just interruptions as a service, out of band communications like that should only ever be used for important things but they just get endlessly abused as a form of spam in practice. The advertising industry already has enough tendrils to pry its way into our lives, I'd deprive it of yet another if it were up to me.
What's the justification for allowing it for a certain class of apps, but disallowing it for another class of apps, where the difference between the 2 categories of apps are just the technical infrastructure on which they are based?
Neither is intrinsically right and I think it's good that there's choice, what's winding me up is this idea that everyone should adopt the Google model unquestioningly as though Google are a standard unto themselves. I'm very much in the Apple camp, but it's not out of any love for Apple and more that I don't like the advertising industry and want to keep it as far away from my life as I realistically can. To me push notifications are like popups in the '00s, yes there's legitimate uses in limited cases but abuse is so widespread I'm going to treat every one as guilty until proven innocent.
Push notifications are extremely useful for a few niche applications. Do not throw the baby out with the bathwater.
This depends entirely on what decade you focus on. There was a significant period of time where even the "cutting edge" version of IE was the furthest behind on implementing new standards. When you combine that with the way IE handled updates and versions, older versions of IE created huge problems for developers.
So there is an era of IE that is very similar to Safari today.
After developing during the IE 5.5/6 years there's no way I'm giving you a pass in calling IE cutting edge.
Besides, nobody got promoted at Microsoft for staying the course and making incremental improvements. Once there were no more balls to be knocked out of the park, developers moved elsewhere to buff up reviews and get bullet points for major projects.
Apparently they got close enough to getting this working that a bunch of South Korean banks and such bought into it heavily, which meant you could only do online banking in that country, for a while, on either a windows phone or an actual windows machine.
However, they narrowly missed getting developer buy-in on that stateside, before the whole "XMLHttpRequest" thing went crazy, and we started building javascript apps for everything.
Yes, it was better but it didn’t really count, as Apple just emerged from its near-death experience and Steve Jobs cut the deal with MSFT to make IE 5 the default browser for the Mac.
Apple’s marketshare was tiny back then and many people in the industry didn’t think Apple would be relevant much longer.
Ironically, after the 5-year deal had expired, Apple shipped Safari 1.0, which was better than the vaunted IE 5 for Mac.
If thats not cutting edge, I dont know what is.
The first iPhone and “desktop class” Mobile Safari was a watershed moment and everybody started using WebKit for their mobile browsers after that point, including non-Apple devices.
Look at what the mobile web was like before the release of the iPhone. Then take a look at what it was like the year after, when people had started making their websites “iPhone compatible”.
By it's death - IE6 was absolutely stagnant and fallen behind.
You also need an iOs device and a Mac to debug Safari, like you did need a windows computer to debug IE.
Safari serves that role today. There are tons of things I'd love to do but can't because they're not supported on iOS Safari.
Nowadays the Microsoft browser, Opera and others are just Chrome skins. Google is pushing various drafts and essentially dictating web standards and then even when a browser like Firefox does support those Google flavoured standards, it still gets blocked outright on new Google products or gets a limited feature set on existing ones. Or it gets hobbled by Google oopsies.
Why would anyone want to play in such a rigged game...
[0] https://developer.mozilla.org/en-US/docs/Web/API/Element/scr...
We had whole versions where it was basically stuffed, and even in the recent versions, I'm getting random errors where it just refuses to write to disk.
If they don't want to implement PWA, fine, their walled garden and wall that, claim it's for privacy etc etc. just don't half ass all the APIs around it then! Leave them out!
A co-worker asked me "uh, why does the app use 120GB for indexeddb?"
Wildest bug I've ever had to deal with. Unfortunately it wasn't even just a safari issue.
Yeah, I get that it doesn't make sense for Apple, business wise -- which is why they are not doing it. But it sure would make sense to developers.
PWAs are here to stay.
The question just revolves around how integral an app is to the business. Online banking probably requires an app. A restaurant that offers online ordering probably does not. A video game requires an app. An online encyclopedia does not.
If your statement was true, there wouldn’t have to be any complaints about Apples ‘walled garden’ because there is no ‘walled garden’ for PWAs.
The word users tend to have for non-native apps isn't about performance or such, it's about UX.
That word is 'shit'.
Nearly every single PWA developer thinks about how brilliant it is that they can write for two platforms at once but forgets that it means that you ALSO have to do every single last bit of legwork that Apple and Google did for you to give a good, correct-feeling UX on mobile and that the more you do the more you pay that performance cost and build yourself a tech debt prison. And don't get me started on the nightmare that is Ionic and Angular.
PWAs absolutely have their place: Apps that you might want to use...sometimes.. with notifications. That's it. Nothing more makes any sense.
No sitting around waiting to download and install updates. No corporate phone-wiping security policies. All the features that mattered, even if Safari didn't look quite as nice and missed one or two.
PWA vs native app doesn't matter at all to the competition, they are gonna be there regardless (esp. B2B scenarios). Whether a website or app works better for B2C is really highly market dependent.
Probably they made the choice after listening to an opinionated story about ‘sitting around waiting for updates’. Which nobody does, of course, because if you mind that you just turn on automatic background updates.
At least in this story Safari is good enough to have the features that matter. The world is safe.
As for safari, we supported IE11, chrome, Firefox, mobile / android chrome, desktop and mobile safari. Safari easily added about 10% to our development budget, and safari users got a downgraded experience in certain cases. Not ideal, but close enough for me to not feel bad calling it the "new IE" (and yeah, I remember developing sites for IE 5.5 and 6).
Edit: speaking of auto updates, I have it turned on myself, and just yesterday had to wait around to update my mobile bank app to virtually deposit a check- log in, get kicked out to update, wait to download and install, then log in again before I could proceed. Not sure why, but auto update isn't a cure-all.
There's tons of mobile apps that never needed to be anything other than desktop sites honestly. Facebook, actually, is a perfect example.
That said, an app for learning as an example should actually have a very different mobile experience as a user wont want hour-long study sessions on the subway (or in line at a subway restaurant.)
I should have specified B2B in my original comment though, B2C I have no experience in.
How about people publish their catalog, and then, like, 3 or 4 interoperable "shopper" apps (with preferably at least one developed in the open) can emerge to do the heavy lifting? The way it works now, where Amazon and O'Reilly and AutoZone all have to hire for developers mirrors the ridiculousness of the streaming media platforms, where just because Amazon or Disney+ or whoever has the content and Netflix doesn't, people act as if it makes complete sense that we should have to enter their dumb app and use that provider's shitty title browser and video player, instead of the user picking the app that works the way they want and using it to play from whichever catalog has the content they need.
That statement doesn't seem to make sense to me since Apple store's limitations make PWA's relatively more interesting on Apple devices than they would be on Android -- an existing application is not inferior to a non-existent one. On Android you can just serve the native applications yourself if Google doesn't like them. On Apple you can't so web application it is.
Name a place where safari is being innovative on the web.
Google's PWA agenda (displace native apps with web apps) is in opposition to Apple's (displace web apps with native apps) on iOS.
Apple's business interests are in opposition to PWAs, and Apple would also make the same argument you are citing that native apps offer a better user experience, performance per watt, privacy, security, etc..
However, mobile Safari can support something like Amazon Luna, so it can sidestep the app store to some extent as far as games are concerned.
The idea of IE being purely an "outdated" browser seems to be one perpetuated by young devs reading & misunderstanding old blogposts. The narrative is attractive because it fits the impatient desire be an early adopter of "shiny new thing", but it doesn't match the reality of how IE6 actually worked.
Safari is compliant. It's behind but compliant. That makes it incredibly easy to develop for because backward compat. & progressive enhancement work well if you're not too lazy to develop according to well-known best practice.
What doesn't work well is the spec. du jour that the Google have just added to Chrome before submitting to a standards body and are proceeding to use their monopoly position to pressure other browsers to adopt. That's IE6 behaviour.
Any attempt to say that otherwise is just wildly incorrect.
Back then all browsers had unstandardized behavior, there was plenty of Netscape specific and IE specific hacks. Some of them were intended as EEE, some of them were result of weak standardization or mere technical limitations of their respective architectures.
At the time of their release, Opera was the most standards-compliant browser. Beyond Opera, I'm not sure where Firebird, KHTML, etc. stood relative to IE4 specifically, but IE5.5/6.0 were well behind most contemporary browsers (lets exclude Netscape shall we; it was in crisis at the time and promptly discontinued). Opera, KHTML, Firefox and Webkit all passed Acid2 long before IE (IE8 was the first version).
It's worth remembering that Acid1 was released in 1998; IE6 was released in 2001. So this wasn't a time before web standards and cross-browser compat: they were very much a part of the discourse at the time. A discourse MS largely refused to participate in.
> Back then all browsers had unstandardized behavior, there was plenty of Netscape specific and IE specific hacks. Some of them were intended as EEE, some of them were result of weak standardization or mere technical limitations of their respective architectures.
That is true, but it was largely due to bugs other browser makers were working on fixing. The EEE had a heavy influence on MS' motivations to get fixes out (whereas with Safari there isn't really any evidence of any EEE being present).
A good counter-point is XMLHttpRequest. It was non-standard mainly because "AJAX" was a new-ish idea and standards didn't exist. There's good arguments that Microsoft's engagement with standardisation efforts of AJAX APIs was non-existent/actively-hostile, but at the end of the day the various APIs they implemented were pretty easy to detect (even the ActiveX variants), and generally could be targeted in a very cross-browser-compatible way.
That was very much the exception to the rule though: the majority of pains were layout related, and involved not extra nor missing features, but rather features that were in common with other browsers that were deliberately implemented in a different way.
That definitely does not correspond to my recollections. It was only in Opera 7 (2003) with the new Presto layouting engine that drastically improved standards compliance.
> Beyond Opera, I'm not sure where Firebird, KHTML, etc. stood relative to IE4 specifically
There wasn't any Firebird (neither Phoenix) at the time of IE6 release so how can you discuss this in relation to IE4 is beyond me. Mozilla Suite was still in 0.x beta and a year away from official release when IE6 was released.
"The real work on KHTML actually started between May and October 1999" (wiki citation) so I don't think they had a big impact on the discussed time period.
> but IE5.5/6.0 were well behind most contemporary browsers
So let's get concrete, which browsers were better in 1999-2001?
> It's worth remembering that Acid1 was released in 1998; IE6 was released in 2001. So this wasn't a time before web standards and cross-browser compat: they were very much a part of the discourse at the time. A discourse MS largely refused to participate in.
Are you aware that IE6 is Acid1 compliant? IIRC the first one as the GA released browser (discounting Netscape 6/Mozilla 0.X betas).
> Opera, KHTML, Firefox and Webkit all passed Acid2 long before IE (IE8 was the first version).
Which is a direct consequence of the fact that Microsoft after IE6 release dissolved the IE development team. IE8 was the first substantial update of IE in 8 years. (IE7 was a minor update)
In practice this means Chrome implements an idea and the idea "wins out" because Chrome does it, until Chrome does a new idea.
That’s certainly not true: it was indeed outdated for much of its life. Yes, through IE6, it did things differently; beyond that point, though, it simply fell behind. It stopped evolving in any meaningful way—with the possible exception of tabs being introduced in IE7–while other browsers continued innovating.
From IE6 through IE11, Internet Explorer wasn’t just doing things differently; it was truly behind. Tasks that could be achieved without JavaScript in other browsers requires JavaScript (or worse) in IE. Eye candy like gradients? Maybe you could get away with some of IE’s custom CSS extensions, but you had to get lucky or change your design.
I may be young by your standards, but I vividly remember developing for IE5 and IE6. I even remember changing my plans for a project when Chrome was announced. IE really isn’t that old.
It's true that IE6 took more flak than it really deserved because people forget how good it was for the time when it first became available. But you can't seriously claim that IE didn't fall far behind as newer browsers developed and eventually took over. You just can't. And you can't seriously claim that Safari isn't falling far behind in the same way today.
This makes the same mistake as many sibling commenters here in that it equates "new features" with "good".
You're making out that IE6 didn't deserve flak in the early days because it had innovative new (non-standard, incompatible) features. You're making out that this was somehow a good thing. It wasn't. This was the cause of IE6 problems.
The general argument in comments is that IE5.5 / IE6 ~circa 2000-2004 was not problematic; that it only became problematic later due to the lack of updates or new features. In fact, the problems were present from the start: in 2004 developers were developing exclusively for IE6, putting "works in IE" badges at the bottom of their pages and excluding all Opera & Firebird users.
This was then exacerbated by the lack of updates to IE, but again–the reason this became more problematic wasn't because IE wasn't updated, it's because IE was different in the first place. In ways that are unlike Safari today.
> you can't seriously claim that Safari isn't falling far behind in the same way today
I can seriously claim it because it's fundamentally different: Safari is falling behind in a standards-compliant, consistent, detectable and progressively-enhanceable way. IE6 differed radically from specifications when released, and then proceeded to fall behind in fixing this divergence.
What I'm pointing out is that IE6 falling behind would not have been a massive problem if it hadn't first diverged radically from agreed compatibility with other browsers.
The box-model is the biggest example: specifying any padding AT ALL in CSS in 2005 meant you were making a choice between showing the specified padding correctly in IE, or in every other browser. Without brittle hacks discovered by tireless volunteers, there was no way around this: the same property did radically different things in IE vs others.
In 2021, if Safari doesn't support a feature, it doesn't support it: the property simply does nothing (neither useful nor harmful). Yes, maybe there are exceptions for edge-case bugs but these are fixed in patch releases, since (unlike IE6's different "features"), they're actually considered bugs by Apple.
No. You seem to be reading that into something I wrote but it's not what I actually said.
New features are certainly important. There is no progress in the capabilities of the Web platform without them and our requirements for web sites and applications today are far more demanding than they were a decade or two ago.
However adding new features is not the only thing that matters in a browser. The quality of implementation also matters. For years Chrome was pushing support for new CSS3 features that we take for granted today like rounded corners and gradients. Unfortunately the rendering in Chrome when you used those features often looked like some kind of poorly blended, poorly aliased, low-res bitmap from the 1980s so if you wanted a professional-looking site you still had to use images anyway.
Safari is falling behind in a standards-compliant, consistent, detectable and progressively-enhanceable way.
No, it isn't. It has had numerous problems where it didn't even follow standard behaviour or have a good quality of implementation for features that it did claim to support. Maybe you've been lucky enough to avoid them, although I don't see how you could have worked on more than the simplest of web sites and interactive features on iOS devices without running into some of the more common problems.
The box-model is the biggest example: specifying any padding AT ALL in CSS in 2005 meant you were making a choice between showing the specified padding correctly in IE, or in every other browser. Without brittle hacks discovered by tireless volunteers, there was no way around this: the same property did radically different things in IE vs others.
Maybe not the most convincing example. IE's behaviour on this one was much more logical and useful than the standard definition. Web developers today typically use CSS features that were added later to use IE's box model by choice.
But also not the most convincing example because you're talking about several years after IE6 came out. As many of us have said throughout this discussion, the problem with IE wasn't so much what it did at the time IE6 was released, at which point IE was completely dominant in browser market share, but that afterwards it didn't keep up with other browsers as they gained share as well and didn't improve its standards compliance as those standards started to matter more.
In 2021, if Safari doesn't support a feature, it doesn't support it: the property simply does nothing (neither useful nor harmful).
I wish that were so. It would be preferable to what we have today, which includes both missing features and present features with poor quality of implementation. Let us know when rotating an iPhone between portrait and landscape reliably handles basic responsive design properly instead of doing its own strange scaling that often leaves some parts of a page wildly out of proportion with others. I've lost count of how many days I've wasted working around iOS Safari issues in just that one area alone.
I left a more substantive comment deeper in this thread, but just want to correct this small point: we're not disagreeing, you've misread the line you quoted. Note the qualifier "purely". I'm not saying it wasn't outdated, I'm just saying the fact it was outdated wasn't the sole cause of problems.
(i.e. I'm saying that being outdated doesn't cause problems: being both outdated AND deliberately incompatible does. Safari is only outdated)
The issues with Google monopolising the direction of standards development are the major issue facing browsers, users and developers on the web, today.
I get that you’re disappointed Safari doesn’t support the same stuff, the same way as Chrome. Tough. You’re attempting to develop and deploy to a platform with backwards comparability baked into its design and development process. If you want to use the new shiny, do so, but accept what you’re doing carries the risks it has and work that into your strategy. You can hope Safari will implement what you want, but unless you’re contributing to Webkit, or on a W3C committee, you don’t have much skin in that game.
As a web developer you should be considering the needs of your users first. Some of your users could be on Lynx, on that browser which comes with Haiku, on a shitty phone from 8 years ago. THAT’s the web.
I'm not targetting Lynx, Haiku, or 8 year old shitty phones. Nor are most web developers.
And the attitude that you must support those things is detrimental to the web. It makes people feel like they're doing it wrong of they don't spend all their time chasing those rare edge cases. Which if you're trying to start something new, can kill your productivity.
I'd rather have web developers target the common platforms only, than have those developers give up and switch to native apps.
I'm on an older MacOS version with Safari 12 (too lazy to update, but that's on me), and there are sites that work just fine one day and then break the next because they changed how they want to load random content for their forever scrolling.
I'm sure there's a business case for the development team, but as a user, all I see is that what worked just fine for users before is now broken. The same happens with Firefox too because of Chrome-focused optimizations that a lot of sites seem to make don't always work with Firefox.
For me as a user, I don't see it as Safari/FF holding developers back, I see that because of some unknown benefit, I'm being corralled into using Chrome. I make my peace and just don't visit sites that decide on such changes, but the benefit for me as a user for these changes is completely non-apparent. It's very tempting to write it off as "it's convenient for the devs" due to lack of any relevant information on why such changes are made.
Your issue however also ties in to what the article said about how Apple does not auto update Safari. You're tied to Safari 12 partially because the upgrade flow is a huge disruptive process as you have to update your entire OS to a new major revision.
Who can say why those sites are breaking for your version of Safari. Web devs do love to just use the "latest and greatest" APIs just for fun, but it could also be that their changes have improved the experience for the rest of users on modern browsers, and that for them outweighs the loss of users still of Safari 12.
I'm not saying every use of new APIs is justified by web devs, the population of web devs is too large and varied to make any statement about the group as a whole. I am saying that the lack of modern features by Safari and Firefox _is_ a detriment to users and web devs, and it pushes developers to make native apps instead which I would argue are a worse experience for many users for certain use cases, and a worse experience for many developers as well.
Sorry, but to be clear, my lack of update is just that -- lack of ambition to do so. I don't really have a compelling reason to update MacOS or Safari.
>Who can say why those sites are breaking for your version of Safari. Web devs do love to just use the "latest and greatest" APIs just for fun, but it could also be that their changes have improved the experience for the rest of users on modern browsers, and that for them outweighs the loss of users still of Safari 12.
This is kind of my point though -- WebDev is kind of unique as I see it as there are far more opaque changes than with other software disciplines. Changelists are pretty common for every other software discipline, but I'm not sure I can recall too many websites ever mentioning backend changes they make.
WebDev changes and fast, and a general feeling is that "outdated" in WebDev appears far faster than anything else (e.g., a friend uses my old 2012 MacBook Air -- it works perfectly still, runs modern Editing and Authoring software (adobe suite), plays videos, works on most websites just fine. Some sites like imgur just shit the bed on it except for Chrome because of browser compatibility) For a situation like this, when absolutely everything else runs fine except for a single website on browsers, it feels hard to blame OS Vendors when it's only the site that is having issues being displayed.
>I am saying that the lack of modern features by Safari and Firefox _is_ a detriment to users and web devs,
I'm not sure I'm convinced for the reason above, but it's not really possible for an end user to comment because of:
- Lack of transparency on why the changes were done in the first place
- LifeCycle for features in WebDev are much different than other software life cycles
- Old OSes and hardware can run comparatively contemporary software (i.e., new and modern) without issue, it's only WebDev that bumps into this
- In many cases, the old stack worked "fine" for users regardless of browser
This is where the impression that it's just feature chasing comes from. You can say Safari is a detriment to me, but it has the best battery life (expected), is fastest on MacOS (also expected), has a UI I really like and prefer (likely expected as it's made to look like the rest of MacOS.
The new feature that web developers want to use from Chrome isn't just weighed against my experience on your site; it's weighed against the overall browser performance the computer performance, and the browser experience with the computer.
I might visit a single site for 10-30 minutes on a given day. I'm using the web browser almost constantly for many many many sites. When one site tries to tell me my browser is insufficient/outdated and it's the only one that is causing issues, I don't feel particularly persuaded by this. It's not about raw numbers; Hacker News performs the same way for me today as it did the day I joined, and while I'm sure they've done gobs of optimizations for the amount of traffic and users they handle, from my point of view as a user on many browsers, the experience is the same.
From the perspective of users of existing software that seems to break with no reason I agree. It's stupid how heavyweight imgur has become when it used to just be a fast simple website that worked everywhere.
Maybe you're content with the functionality your system has now and need no more, but I am still on the quest for new things I can do digitally, and easier way to do things I already can.
Take Figma for example, I'm not even a designer but even I enjoy having access to a collaborative drawing app that is trivial to share with other collaborators. If browsers had not agreed to implement Canvas and all rolled it out, Figma would likely not exist. Perhaps they could have created a packaged native application for all major operating systems, but in reality that's a ton more work, and a huge impediment for users to convince collaborators to buy/install some native app so they can work on a drawing together.
What other software are we missing out on because the barrier for interacting with USB/NFC/Bluetooth/Notifications/Background-Sync is too high.
In a world with native apps only, only the big players can afford to target all platforms, and only the big enough use cases can justify the expense.
> Perhaps they could have created a packaged native application for all major operating systems, but in reality that's a ton more work, and a huge impediment for users to convince collaborators to buy/install some native app so they can work on a drawing together.
> What other software are we missing out on because the barrier for interacting with USB/NFC/Bluetooth/Notifications/Background-Sync is too high.
These are quite a bit overstating the problem. The barrier to entry to develop a native app using safari is quite simple, and you can extend safari to do many things, including being spawned by golang and adding other FFI's for javascript functions. The barrier to entry is your willingness to learn and you only see these complaints coming from new developers. Taking a canvas API and implementing yet another collab drawing app is not innovating, it's using an API.
On the flip side, each new API brings more and more surface area for attacks. And if we keep stacking new APIs we don't have enough time to mature and secure up the existing ones. Notice the only example apps given are attempts to replace native apps with web apps.
Sure I can make a native app that extends Safari with the APIs I need, and I can also do that again for Android, and again for Windows and again for macOS. Or the browsers could implement features developers like me want and I only have to invest once.
Replacing native apps with web apps IS innovative.
Sure the app's functionality is the same as those before it, but the delivery and interaction paradigm is so much improved for users. Being able to invite a friend to participate on what I'm doing without them having to install a native app IS a step forward in user experience.
This is one file at best per platform, even less now given the frameworks available. And what you learn in the process goes on to benefit your career forever.
> Being able to invite a friend to participate on what I'm doing without them having to install a native app IS a step forward in user experience.
This is entirely subjective. And webapps have their own version of this by forcing usage of chrome, forcing account creation, forcing facebook usage, etc. Web experiences for anything complex doesn’t exactly instill confidence given the shaky experience and devs inability to create seem less offline experiences even with all the required transports available.
Then there’s performance aspects of things. Things like Unreal Engine Editor running in the web, or blender, just seems ridiculous. Sometimes you need native performance.
There’s also security issues with each additional API and web has a bad history with security.
People are making and remaking collaboration apps every day. They’re a dime a dozen now. Apps that truly are innovative that people use to create more things are still native apps for good reason. Otherwise the current set of features supported by safari is enough for me to do my daily work and I feel like Im missing nothing by not using chrome.
If only Chrome implements that feature, it’s not “a modern feature” for the web. It’s an “experimental technology”. It’s only a “modern feature” when several browsers implement it.
I’m not against browsers having features. They can add whatever they want. Devs can target them too.
But “the web”, the platform, the standards process, the language specs, the method of their development is all about maintaining access for the widest range of users for the longest time possible. Or it was. There’s nothing about it stopping you from restricting your own market to support users and devices you want to support… but insisting all mainstream browsers support all the brandest-newest features because ONE of them added it does a disservice to the platform.
Firefox abandoned FirefoxOS, Apple is focused on the App Store.
What's the last interesting API proposed by someone other than Google?
In some cases, yes, but in others, no. For example, Safari still clings to their proprietary image formats. That means I need two versions of each image: something legacy or proprietary for Safari users (PNG, JPEG, HEIF) and something to appease the Google Gods (WebP) so I don't get blasted by Core Web Vitals. It's the IE PNG and SVG issues all over again. (Yes, I'm aware that Safari keeps claiming they've added WebP support--it's broken and has been broken since its inception.)
It's this proprietary, "we're going to do things our way and ignore the conventions" that annoys me. Chrome does it, too, but at least Chrome users have the ability to choose another browser; no such luck on iOS. WebP has been around for a long time now as an unencumbered format; there's no reason to continue avoiding it other than those sweet, sweet royalties that Apple wants to collect on HEIF.
> If you want to use the new shiny, do so, but accept what you’re doing carries the risks it has and work that into your strategy.
No, I don't want to use the new shiny; I want to eliminate the old bloat--all the compatibility code required to achieve the same experience across a variety of browsers while simultaneously appeasing search engines.
I don't want to be forced to use Apple's proprietary image and video formats to achieve decent performance in Safari--formats that other browsers often can't reasonably support. I don't want to be forced to do things the "Apple way" and rely on JS when I could be using CSS that works in all other browsers.
This is the same path that IE took. Right now they're at the IE7 stage: you can get roughly the same effect that you can with other browsers, but you have to go about it differently. At the same time, they're starting to lag behind. IE7 really exemplified this lag: it took them far too long to add tabs. Proper PNG support was in a similar boat but took even longer.
> Some of your users could be on Lynx
My sites would work better in Lynx if I didn't have to spend so much time making them work in Safari--but they do work in Lynx; they're just less-than-pretty because, guess what, Safari lacks support for the CSS that I need to accommodate semantic HTML.
> on that browser which comes with Haiku
It can't be that important if nobody even knows what it's called.
> on a shitty phone from 8 years ago.
Phones from 8 years ago run sites a lot better when they don't have to download redundant code and JS polyfills to achieve what could've been done with pure CSS. Although, if they don't support TLSv1.2, they're not going to be able to connect to some of my sites anyway; tough cookies. (They'll still be able to access my static websites, where enforcing modern encryption is less of a concern.)
WebP uses VP8, which requires hardware support to run correctly. Apple's "proprietary" format is also open, and created by a standards body instead of Google. VP8 also has some patent claims on it by Nokia, even though Google has released it under a free patent license. I'd definitely second guess that if I were a legal dept. So really you're arguing that you prefer Google's proprietary format over Apple's. To each their own but know your desired format isn't as free and open as some would hope.
> Chrome does it, too, but at least Chrome users have the ability to choose another browser; no such luck on iOS.
What if iOS users view this as a feature? I know I certainly do. It's impossible these days to know with certainty which apps are running in a browser. And given Chrome supporting all the things it supports it can be a security issue. So knowing an app must be using webkit to me is a feature.
> I don't want to be forced to use Apple's proprietary image and video formats to achieve decent performance in Safari
Again, Apple's formats are open. And further this should be completely transparent to you as you should have conversion scripts in place already.
> My sites would work better in Lynx if I didn't have to spend so much time making them work in Safari
My experience is a bit different. I develop for Safari, then check it in Chrome and FF. It works most of the time with few exceptions that Chrome implements to perform it's magic.
> It can't be that important if nobody even knows what it's called.
That's actually the point. It supports the standards and you get a few extra market participants you wouldn't have if your customers happen to run that browser. You don't need to know the name at all, so long as it supports the standard. This benefits us by having more and more browser engines and competition, instead of the 3 we have today.
> Phones from 8 years ago run sites a lot better when they don't have to download redundant code and JS polyfills to achieve what could've been done with pure CSS.
The question is, is any of this needed? If it's CSS it clearly doesn't anything to do with the functionality of the site right?
No, it isn’t. It’s useless without HEVC, which is encumbered and requires royalties,[0] most of which go to Apple. VP8 is free (as in “free beer,” not as in “freedom”).
> What if iOS users view this as a feature?
They can view it however they like. I’m typing this on iOS and find it disappointing.
> Again, Apple’s formats are open.
HEVC is not open.[0]
> My experience is a bit different.
Chrome has its own issues, though, as does Firefox. Safari just seems to have more than the other two. For example, for the longest time, Safari was the only browser to support color() and DCI-P3.
> That’s actually the point.
While Safari might not have the nasty Google habit of coming up with their own standards, they do have the nasty IE habit of failing to keep up with widely accepted standards. For example, to this day, HTTP/2 server push remains broken and will crash Safari if you attempt to push a zero-byte resource.
> The question is, is any of this needed?
If you want to cater to an audience that prefers a clean, efficient UI while simultaneously avoiding creating a horrible mess of dark patterns, yes. If you want to run on as many browsers as possible without looking like a Word document, yes. If you want to appease Google so you don’t get deranked, yes.
[0]: https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...
HEVC is H265 which is not as widespread. But either way, one benefit to Google I guess is you can avoid the $2.60 device fee. But also scroll down and see how many companies were involved in HEVC vs VP8/9.
> HEVC is not open.[0]
Source code is readily available, codec formats are as well, all that's keeping it from being open is a licensing fee.
> Chrome has its own issues, though, as does Firefox. Safari just seems to have more than the other two. For example, for the longest time, Safari was the only browser to support color() and DCI-P3.
Again, not my experience. I have only had to perform CSS hacks on chrome because chrome adds some CSS features ala IE.
> If you want to cater to an audience that prefers a clean, efficient UI while simultaneously avoiding creating a horrible mess of dark patterns, yes. If you want to run on as many browsers as possible without looking like a Word document, yes. If you want to appease Google so you don’t get deranked, yes.
So using safari I am part of the audience that doesn't want a clean UI? That's the entire reason I use a Mac and Safari. So the question stands. What does CSS have to do with SEO?
How do companies create cross browser experiences these days without making sites look like "word docs"? Apple themselves seem to have quite a design and css heavy site.
Since Safari is such an issue for you, why not just block the sites? Likely because you'll lose market share. So instead you try to demand your customers switch to something you prefer they use to make it easier for you to make money off of them. When will you Google shills leave the rest of us alone? Also how much are they paying you to promote Chrome these days?
In short, it isn't about "IE vs Safari". Both have multiple versions. What was awful was that IE was behind the times. Everything else was basically fixed by pasting a few lines of code from awesome people. Safari is way more work today than IE was back in the day and doing any modern web development is a breeze today - until you need to make it work in Safari.
There's a bunch of good and bad arguments in sibling comments: some of them may be subjective. But this quote really caught me out. Wow.
Wow.
Presuming that you've been developing website for more than 10 years, and that your knowledge of IE6 is based on hard experience and not just reading... what on earth are you doing that is so difficult in Safari?
It’s like complaining that Xbox consoles are inadequate for not playing PS games when it’s already established that they won’t from the jump.
Well, kind of. There are all sorts of minor glitches that only happen on Apple devices. A common complaint is iOS Safari's interpretation of vh units. It might be technically correct (because the spec is sufficiently ambiguous to argue that Apple's choice meets it) but it's still obviously broken for common practical applications that work everywhere else such as attaching content to the bottom of the visible area. The handling of the "notch" on devices that have one is likewise arguably technically correct but obviously broken.
So the objections to Safari aren't just about not supporting Google-style PWAs features. Some of them are about other big features too. Support for HTML5 media elements and the backing technologies has been very lacking by modern standards and numerous special cases have been needed over the years only to support Apple clients.
This is true but it's true of all software. And they tend to get fixed in patch releases (rather than waiting for a new major version). Even for bugs the Webkit team leave open for years, I think there's a big different between maintaining major incompatibilities in central features for years, and being slow fixing some edge-case glitches.
But it's not, is it? We're not talking about minor bugs here, we're talking about anomalous behaviour or unusual interpretations of the specs. Safari is far worse than any other major browser in that respect now that IE has largely faded away.
That's not what I recall. As I recall, IE wasn't difficult just because it was behind the times, or because it was deliberately different; it was difficult because it had lots of bugs and inconsistencies. There were plenty of subtle incantations one had to use to make it behave consistently, and to avoid its worst bugs. We dealt with it because unfortunately MSIE still had lots of users, but once the number of users became low enough, all that bug-avoidance code was dropped by web developers.
Adding to that, MSIE's Javascript error messages were extremely cryptic. In my workplace at that time, we made a MSIE-only site (it required an ActiveX control for media streaming) run as much as possible on Mozilla/Firefox (of course the media player didn't work), just to be able to get better Javascript error messages when debugging errors on our Javascript code.
Noticed that "vw" and "vh" CSS3 units dont work in it like they do in other browsers. Upon digging, found a medium article explaining it - but as I was in safari, the article's code snippets or images wouldn't load properly.
As much as I got a bit hyped to try using safari after WWDC - I just can't. It's so discombobulated regarding web standards that I wonder if it can even count as a "web browser" any more than emacs can.
Whatever Medium's needs are for putting images and the written word on the screen were satisfied a decade+ ago. The fact that that Medium article doesn't work is a consequence of how web developers have normalized the practice of passing the blame for their failures and lack of competence on to the browsers and browser makers by extension.
We shouldn't even use the term "web developer". The entire industry, bolstered by analogizing themselves to mobile app programmers, have snowed the world and warped expectations that they are or should be anything other than experts in digital content publishing. The entire notion of "full stack" (which embodies a lie in the very term) should have never even happened.
If we really want to pick bones, where the engineers working on web browsers and "web developers" are both fair targets, then the overwhelmingly pressing matter would have to be how the latter are a piss poor substitute for anyone competent the skills they should possess, which would involve library and information sciences and a smattering of practical tech discipline. The industry is a perfect example of the rampant "consultant effect", where people create massively complicated stacks that often don't accomplish anything that their forebears couldn't manage, and then get paid bloated salaries for mastering the tools and workflows that are ostensibly meant to solve the very problems that they are responsible for foisting onto the world in the first place.
Organizations want to buy a solution to their problem instead of reorganizing themselves to develop the fundamentals required to not have the problem. It's like managing your back-pain with pain killers without actually doing any physical therapy or lifestyle changes to fix your body mechanics. It's a temporary solution that puts you on a ladder to needing ever more intensive interventions.
The problem of displaying images and text on the web was solved in the first [EDIT: an early] HTML spec in the mid 90s. Yet web sites still manage to screw it up and make it unnecessarily dependent on JavaScript. I always thought the web would be a lot more pleasant if web "developers" would just stop programming for a bit and learn a little HTML.
With a bit of effort you can embedded chromium in Emacs so it's basically true.
Who survived those times, with the evil F12 debugger, can confirm.
Safari is a joy to develop with and it sucks I have to switch to chrome for its extensions.
Like many others have started- it’s common these days for devs to create modern apps that work on modern browsers but break in weird ways on Safari. That’s enough of a similarity for the analogy to convey the idea.
Web-P / WebGL support aside- Safari often fails to render complex SVG animations for obscure reasons. It can’t even render a hex-based CSS radial-gradient that looks the same as it does on Chromium or Gecko.
It’s really bad, and Apple benefits from that. They are holding the web back as IE once did in the past.
Though maybe I just proved your point about missing the forest for the trees :-P
Your idea of equality are skewed by popular mainstream media. We should not strive for equality because life is not equal, but we should strive for fairness. If you want equality between me and an NBA basketball player you'll have to break their legs or something because I can't play basketball if my life depended on it, so there, that's an example of life's natural inequality, which is fair.
Fairness means equality of opportunity, not the equality of outcome. Arguing for the equality of outcome is tyrannical and pure evil.
Equal rights means equal opportunity though, not equal outcomes.
You're right; fairness means equality of opportunity. Arguing for removal of equal opportunity is "tyrannical and pure evil".
I prefer people who evolve like Biden, Obama, and Clinton did, instead of devolve like Trump did, by selling out to haters in exchange for political power.
As far as I know (and I've asked people who've known him for a long long time), Brendan has always been badly against gay marriage, with no plans of ever evolving or apologizing or even explaining himself.
And yes I've asked Brendan himself about it, and he outright refuses to explain or justify or apologize for either his hateful opinions or his hateful actions that hurt other people.
Brendan Eich went way beyond simply holding an opinion when he purposefully contributed money to the campaign to tear apart other people's marriages and destroy their families.
Brendan's money paid for TV commercials blasting lies, stereotypes, prejudices, and attacks against gay people.
Brendan's goals were satisfied: Proposition 8 passed, and marriages were destroyed because of his support, thanks to the anti-gay propaganda campaign he helped fund.
Brendan Eich knew quite well what he was doing by supporting Proposition 8, and he totally meant to do it, and he has never apologized or evolved, or even "argued his opinion" as you falsely claim he uses his means to do. He never even meant for his opinion to be known, let alone argued for it in pubic.
https://en.wikipedia.org/wiki/2008_California_Proposition_8
But I strongly suspect he isn't thrilled that GamerGate and Alt-Right have made him their unwitting hero and martyr and poster child, and that they keep spreading the lie that Brendan was fired from Mozilla because of cancel culture, when Brendan actually resigned of his own free will, and Brendan has said repeatedly himself he resigned and was not pushed out, and the Mozilla board said "Brendan voluntarily submitted his resignation", and the board actually begged him to stay, and this is all very well documented and not contested except by batshit crazy conspiracy theorists.
https://blog.mozilla.org/en/mozilla/faq-on-ceo-resignation/
>Q: Was Brendan Eich fired?
>A: No, Brendan Eich resigned. Brendan himself said:
>“I have decided to resign as CEO effective April 3rd, and leave Mozilla. Our mission is bigger than any one of us, and under the present circumstances, I cannot be an effective leader. I will be taking time before I decide what to do next.”
>Brendan Eich also blogged on this topic.
https://brendaneich.com/2014/04/the-next-mission/
>Q: Was Brendan Eich asked to resign by the Board?
>A: No. It was Brendan’s idea to resign, and in fact, once he submitted his resignation, Board members tried to get Brendan to stay at Mozilla in another C-level role.
Safari isn't perfect but neither are the other browsers. And as far as not supporting every little thing Google decides to shove in the browser, good! I'm glad Google is working to push out new ideas for the web, but I'm also glad Safari is keeping them honest by not providing wide support of those ideas until they go through a standardization process.
I was there. I call bullshit. Competitors like Opera and IE for Mac (a completely different codebase and product) could do alpha-transparent images in the background, CSS sibling selectors, display:table-* and dozens more. For a few fortunate Web developers who were strong willed enough to heed the call from Alistapart to standards compliant code, we were able to circumvent the lack of "cutting edge" features – typically already published years ago – by employing HTC <http://enwp.org/HTML_Components> and hiding this from other browsers with conditional comments. Nowadays this would be called a polyfill.
The reality is that IE suffered immense neglect.
https://www.youtube.com/watch?v=tVq1wgIN62E&ab_channel=Dames...
https://medium.com/rbi-tech/safaris-100vh-problem-3412e6f137...
Mobile safari might not be the IE of the modern day, but the lack of support for core standards and focus on random shitty features (like hiding full urls in address bar) is akin to how M$ managed IE.
Biggest problem with Internet Explorer was it was slow. That's largely the result of the weird shit you mention. But if Microsoft had kept IE fast, it would have denied the field to Chrome.
I remember someone telling me they couldn't use anything else other than IE6 at a non-tech job years after it was deprecated and at least two major versions behind.
^^^ This! Yes, exactly! ^^^
I'd have thought the world had learned it's lesson with developing websites exclusively for IE, but apparently not. When you develop a website to make use of a single browser and break in (m)any others, you're purposely attacking the way the Web works. It's all designed around standards for a reason.
This is completely incorrect. IE lacked CSS2, it lacked proper PNG support, it lacked HTML5 tag support for ages, its DOM implementation was missing functions for the DOM spec that it implemented, it lacked SVG support entirely, it didn't have meaningful developer tools (no, the browser toolbar didn't count because it crashed so much) until IE7... The list goes on. It's simply revisionist to say that IE wasn't missing features. It was nowhere close to the cutting edge, even when its releases were cut.
IE lacked just as much as it got wrong, even at the time.
IE was far ahead of its time in the beginning, bringing us advancements like XmlHttpRequest which set the stage for websites to become webapps. Eventually though the entire team behind it was disbanded and dissolved into other divisions, which let the technical debt accumulate into the eventual mess.
What made it so bad is that web technologies started to progress faster and faster, constantly building pressure on IE to adapt, but it just couldn't be made to work across all of the integrations with Windows, plugins like ActiveX, historic compatibility promises, enterprise policies, and newer rendering stacks used by Firefox and Chrome. Perhaps they should've retired several years earlier or brought out Edge sooner, but the IE story has both a terrific rise and a crazy fall.
My problem with IE was mostly with its ( lack of ) development.
>IE was cutting edge until Firefox
It was cutting edge for IE 5, and IE6 only fixes some of IE 5.5 issues. Remember this was the early days and there were thousands of low hanging fruit. It wasn't even standard complaint problem, ( as much as I would like to write one piece of DHTML code that work across all browser ) like many here have stated M$ decided to do it differently and I actually would not have a problem with that if their version was actually better ( Some features were indeed better ). But they stopped. IE 5.5 was already a relatively small changes from IE 5 which was the really big release. And IE 5 if I remember correctly was before 2000.
I would not have been so pissed about IE if M$ at least release some update. It wasn't until security issues got so serious did they decide to move their ass to do something. So from my point of view, Safari in this case, despite their slow release cycle, is still trillions times better than IE. I would normally have stood up for Safari on PWA and Safari as IE issues, but the pain of App Store lead me to change stance. And to add insult to injury they even claim PWA as an alternative to Native Apps in the trial.
Apple used to have a very coherent strategy and message, even to the way how things are being discussed in court. Now it is a pile of mess.
Don’t get me wrong, I wish Safari had more features, fewer bugs, and an evergreen release cycle. It’s clear Apple do not see themselves as competing with Chrome, largely because of iOS, and I do want them to take it more seriously. But the people who write Chrome explicitly do not care about other browsers, and think that the world would be a better place if Chrome were the only one. Between that behavior and the whole AMP fiasco, I’m surprised so much of the blame gets thrown at Apple for destroying the web. Am I supposed to be writing PWAs now, or AMP pages? If Reddit can’t figure it out, how the fuck am I supposed to?
Reddit is a multi billion dollar product and one of the most trafficked sites on the internet.
As far as Reddit, I'm surprised the 3rd party apps using the API haven't gotten ads yet. They're heaps better than the official Reddit app.
The article mentions explicitely: WebRTC, VP9, WebP, notifications, home screen icon shortcut, Local data storage, camera, microphone, USB port, and some more.
The only one in there that is not supported by w3c, as far as I know, is USB. All others are proper W3 standards yet unsupported by Apple WebKit/Safari.
Many of these complaints are about technologies that are fully standardized and supported by all other mayor browsers.
That doesn't contradict your point per se, but it basically feels to me like Google is dictating the standards right now. So I'm not sure Apple needs to play along.
W3C nowadays only retifies standards that are in widespread use, and Firefox is no longer relevant in our browser matrix for deliveries, with a single digit usage.
It’s actually and Apple vs. APIs and technologies that allow fingerprinting on the web thing.
Nobody mentions that Mozilla has sided with Apple much of the time to not implement some of these same APIs and technologies.
It is not about privacy. It is about revenue.
If you follow some of the conversations on GitHub when a proposal comes up from Google, which I sometimes do, there’s no simple way to make some of these APIs private. And when Apple proposes ways to do so, Google balks at them because… their revenue is based on advertising that tracks users across the web. It’s not rocket science.
Remember, Google is the only company that ships a mainstream browser that doesn’t come with privacy settings by default. There’s no features in Chrome to block trackers or limit how 3rd party cookies are used unlike Safari, Firefox and Edge.
Apple’s market cap is around 2.5 trillion dollars; while they make revenue from apps, it’s a rounding error compared to their overall market cap or their iPhone revenue.
Not all of that $20B was profit, but based on what we know about the economics of running such stores, it was about $15B of profit. That is 25% of all of Apple's profit in 2020.
Apple will do anything to protect that income stream. If the way to protect it is to cripple the web, well, you can't make an omelette without breaking a few eggs.
Of course it isn’t. Apple had longstanding (years long) bugs with IndexedDB. Their PWA implementation has been buggy from day one. They don’t implement push because it threatens their native app ecosystem, not because of privacy concerns.
Yes, there are some APIs with privacy concerns. But that’s a small part of the story of Apple’s neglect.
A sibling comment says:
> The article mentions explicitely: WebRTC, VP9, WebP, notifications, home screen icon shortcut, Local data storage, camera, microphone, USB port, and some more.
Some of these things enable (more) fingerprinting, but VP9 and WebP? Nah.
I have all kinds of Apple stuff--phones, laptops, accessories--but a lot of what they do is strategic in service of enlarging their profit margins (look at right to repair, for example). I don't necessarily blame them; capitalism is a race to the bottom here. But let's not cast Apple in this light of noble privacy defenders. They're doing that to make money too.
The W3C doesn't exist, hasn't mattered for 15+ years, haven't you heard? It's not even the HTML WG that matters anymore (which took over from W3C in an ad-hoc way). It's basically Google, and that's that.
https://webapicontroversy.com/ and WebHID timeline: https://twitter.com/dmitriid/status/1419436102373584905
There are countless other examples
Don't get me wrong. I think WHATWG (Domenic et al, and Hixie before) worked very hard to bring HTML forward. And the idea to have a loose workshop of "browser vendors" agree on how to evolve browsers might've looked like a good one at the time. But is nevertheless not what standards are about, especially when it drives "browser vendors" out of business or out of producing browsers alltogether (such as Opera, Hixie's original employer, and even Microsoft).
Also, Mozilla lending credibility to such an effort hasn't helped Mozilla either when Firefox has fallen from its position as dominant and innovative browser to low 1-figure usage.
At a certain point years ago, work done on "web standards" has become a Google stealth ops to own the Web even more than they already do. As it stands, WHATWG will be remembered as the ones to have killed the Web, and oddly enough, Apple as the last ones standing in opposition to a web owned by Google. Certainly not webdevs caring about fscking PWAs and push notifications that absolutely nobody wants.
And Apple are not obliged to have 100% feature parity with Chrome.
…hence why people complain about Apple’s neglect.
Even on desktop, Firefox is sliding towards irrelevancy, with just 7% market share.
They are gunning for monopoly. No shame in that. The chrome app is the biggest gateway to the internet globally and winning that war means complete dominance as the world moves towards web applications. Using the carrot rather than the stick.
But therein lies the rub. Safari is betting on being bundled with macOS/iOS. That's a cool few million users with nary a breath of effort. I can at least empathise with Apple. Why put in the effort like a schmuck selling fried chicken, chips and skateboards door to door when I can lay back and just collect the meatball bacon cheddar pizza rolls falling from the sky?
It is pretty shameful if you’re simultaneously claiming to be the biggest defender of the open web.
> Why put in the effort
It’s pretty clear why at this point: developers hate them and antitrust regulators are looking for the right opportunity to go for the throat. Apple screwed up when they killed Safari on Windows, they could have had a solid shot at being the #2 browser in the world on the merits ten years ago and they totally blew it. Eddie Cue even wrote about this in some of the emails from the Epic discovery: https://twitter.com/PatrickMcGee_/status/1389632382244847623...
In any case, I'm the furthest from supporting Google or anything they do. But they aren't better or worse than Apple Inc.
To defend google, yes their software has the windows problem. They have to support an absurd amount of devices. So them pushing standards is just a big whale trying to get ahead of itself. No harm in that as long as devs don't go for bleeding edge features and harbour any expectations of cross browser compatibility.
In not blaming Google or the regulators. They can duke it out as long as the public benefits.
Safari wasnt all bad when IE was a thing. It's just that they took IE's spot by being obtuse and generally the rich kid who's a wierdo.
Thanks for the tweet link. Is there a site where leaks like this are common? I really liked it more than I should and how much Apple surprisingly looks at Google. I'd always thought Apple is above looking at companies serving peasants with peasant devices.
But the real shame is for the system, the laws, that allow that to happen.
Shaming Google or Apple does not do much. Legislating against monopolies like AppStore would be the solution.
I'm sure Microsoft (Xbox game store), Sony (PSN store) and Nintendo (eShop) will be on board with banning proprietary app store monopolies owned by the hardware vendor.
For Google, the browser is closely associated with their revenue streams. If you profit by showing ads across web properties, you’d naturally prefer to have more control over how those properties are viewed.
The motivation can be benevolent in some aspects (to show more ads, we want people to want to browse the Web more—so we want to support fancier tech enabling fancier websites to be developed more easily) and less so in others (we want to control the viewing mechanism to ensure people keep seeing ads; we want to become the de-facto standard of browsing so that we don’t have to worry some newcomer eating at our revenue stream; the more complex the spec, the bigger our moat).
To Apple, the browser means relatively little on desktop; on the more sandboxed mobile OS it matters more due to being responsible for a lot of the attack surface.
And these days more often than not Mozilla (which has no stakes in either apps or online advertisement) sides with Apple: https://webapicontroversy.com
Sure if seems sketch to access USB from the web, but as a user if I'm trying to achieve something and I can't do it on the web, I'll end up installing a native app which has way more access to my system.
As a developer I would much rather be able to just deploy cool things on the web instead of having to package up native apps for every platform just to do things like read/write NFC tags, or send notifications to users who want them.
Mozilla considers the periodic sync API "harmful" because you could use it to track users IP and consumer resources when it's not clear they're interacting with the site
Their stated position:
> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed, however, addressing them for periodic background sync appears substantially harder than doing so for one-off background sync.
But you could achieve very similar behaviour by using Web Push (which they _have_ implemented) and just sending periodic push message. So now as an honest web developer if I want nice background sync behaviour I have to implement some Rube Goldberg system of periodic push messages from a backend rather than just asking the system to wake me up every now and then.
The fact that something was implemented, shipped, and has security/privacy hole is not an argument to implement and ship something else with a similar hole.
It's like taking a room, and refusing to add a back door for "security" when the front door already exists.
Besides, it's quite possible that the hole in WebPush does not allow for some/many scenarios that a background sync would.
Yes, they will. So the question remains: why expand the hole?
If I can unlock your computer with your password or with the word "hello" and you have no intention of removing the "hello" feature, would you not agree that we might as well remove the password entirely?
How do we increase the attack surface of service workers by adding background sync, when we can get nearly identical behaviour using push?
If you goal is purely to not increase the attack surface, you might as well never add any new APIs ever.
> when we can get nearly identical behaviour using push?
The devil is in the details: is it nearly identical behaviour? How nearly is it identical? I personally don't know.
This is not an argument to just go ahead and implement WebUSB/Bleutooth/Serial/whatever.
> As a developer I would much rather be able to just deploy cool things
Ah yes. It would so very nice if we could just trust all developers to not be malicious actors.
How many IoT devices could have just used bluetooth for interactive with them, but instead they all phone home to some central cloud server because the user experience of just hitting a web page is better than installing some clunky native app.
Should we "just go ahead" and expose everything? Of course not. But there's room for thoughtful implementation of these features that users want. A super secure platform that nobody uses provides security to no one.
Yes, there is. And that's exactly the position of both Firefox and Safari: don't rush in and implement stuff just because you can.
It needs to be thoughtful, but the firefox position appears to be that web apps have no business accessing bluetooth or usb. Which as I explained earlier leads to user installing clunky native apps to interact with their bluetooth/usb gadgets, or the gadgets being deployed with phone home functionality so that user can still access them through a web portal.
If firefox wishes to remain relevant they're going to have to implement the things that developers and users want. Nobody wants a dumb document browser anymore, that ship has sailed. Browsers are a ubiquitous application platform.
There's a third possibility: that you give up achieving that something. The "activation energy" of installing an app is higher than loading a website, so if the user's desire for achieving that something is not strong enough, the native app won't be installed.
And besides, most users know (or should know) that installing apps can be risky, while a website is supposed to be sandboxed. That is, absent exploitable browser implementation bugs, going to any website should be safe.
>Why did developers and software engineers hate IE so much? Because IE was seriously outdated, lacking support for cutting-edge web APIs and technologies enabling the modern websites and web apps we use today.
This meant you could guarantee that any website you designed and that you ensured followed web standards and rendered perfectly on every browser known to man would either break or display completely differently on IE. So you had to then pollute your lovely clean code with countless ugly hacks and conditionals just to ensure your site rendered the same on IE as it did everywhere else.
That was why every web developer not working in a Microsoft bubble loathed that browser.
A whole lot of cutting-edge JavaScript can be polyfilled/transformed to work on IE11 (automatically in most cases, with something like Babel), and the module/nomodule pattern can stop that polluting your bundles for modern browsers. It also has decent flexbox support (just a few oddities easily worked around IIRC), although its grid implementation is incomplete and uses an older version of the spec that in most cases just isn't worth the effort.
Nope. IE6 was the most standards-compliant browser out there in 2001. The problem was that it did not move from its 2001 state for many years (development was dropped).
Web developers have increasingly the attitude of "I don't want to learn how to make apps, I want to use HTML/CSS/JS for all apps I make", and this plays directly into Google's interests, which benefits from everything being web, because it has its tentacles all over the web (through search, analytics, ads, dns, hosting and so on).
So Google keeps adding questionable features to Chrome and pushing them as standards, including bizarre things like Bluetooth and USB access from web apps, and consistently trying to paint Safari as crap and outdated, and Firefox as stale and out of touch.
And unfortunately, it's clearly working.
I'm a developer, and among other platforms I also target the web, and let's be honest, web devs are among the least educated, least sophisticated, most entitled and most whiny bunch there is. I'll get the downvotes for saying this, because many of them are right here on this site, but it needs to be said.
It's increasingly rare to see even a decent web site these days that isn't some horror show cobbled together from megabytes (literally) of JS frameworks and JSON, if you wanna know why, here's why. We've created a monster and that monster now wants to eat all platforms, so everything everywhere including on your desktop, laptop, tablet and phone, is just tons of React/Angular spaghetti and you better like it.
App Store revenue was over $70B last year, with a 20% increase every year. Let me put it into words for you: seventy billion dollars. This is more than the total revenue of Intel, HP, Walt Disney, Unilever, FedEx or Pfizer, from the App Store alone. Most of that revenue comes from iOS apps. There is no way Apple would implement every new web standards mandated by its main competitor just to lose some of that revenue. Web devs should stop whining and come back to earth.
> web devs are among the least educated, least sophisticated, most entitled and most whiny bunch there is
This is exactly what I see. I'm a C/C++ developer, and recently started to re-make my website[0] (very WIP) together with my partner, and I've had a few web-devs and other devs tell me that it's really fast (i didn't notice because I'm used to sites like HN), and I just said "it doesnt use js", and I kid you not, at least one or two couldn't even believe that(???). It's crazy how simple you can make a website, with just standard html and css.
I don't understand the push for frameworks and other js stuff, honestly. You said it - Megabytes. That's all you're really adding when all you want is a simple little website.
Of course you need it for interactivity, and any kind of account system will get more complicated, but the amount of sites that are just a webapp is horrifying.
[0]: https://hescaide.me/
> let's be honest, web devs are among the least educated, least sophisticated, most entitled
is just plain wrong and unnecessarily outrageous.
There is a huge pool of front-end web developers when compared to other "specializations" and many person coming to it from other professions, so I guess you could easily have a poor experience with some if you're unlucky, yet I both work with JS-people and C++-people and I cannot really say that one is less "educated" or even less "sophisticated" (whatever that means) than the other.
For sure, front-end devs are often less interested by the lower level technical details of a platform but they know how to code a maintainable and readable application with a complex state and a complex often-changing business logic and are even for the most part not afraid to learn another language, e.g. for personal projects: in my close colleagues some worked with elixir, another switched to go, I enjoy C++ and Rust... At least in the bigger companies I worked with, JS and C++ devs also went to the same schools, they just had different interests in programming.
---
As for the "this plays directly into Google's interests" part, sure, I agree with that sentence.
But even considering this, I and most people I know would agree that launching a web application leads to much less friction than running a native app: nothing to install/uninstall, easy interoperability with other websites, easy to share a given page with others, easy to copy/paste anything, automatic plugin support and it's also easier to modify and update features through user scripts...
I know this is not the more popular opinion here but I personally am happy for this continued push towards the web platform, even if does not come from pure intentions.
(1) Web dev is easier and more productive to learn incrementally than just about anything else - I personally learned how to do HTML and CSS long before I learned any other programming. That was the gateway that eventually led me into the CS field. A lot of others follow that path, but perhaps don't take it as far.
(2) Web dev is so ubiquitous and in such high demand that companies are willing to hire anyone who "knows enough to be dangerous" with this tech. That's actually a *good thing* IMO since it means a lot of people are getting good jobs with the chance to learn and grow into a career, instead of being stuck in worse jobs. But it does reinforce point 1 and lead to web devs skewing towards junior devs and away from formal CS education.
(3) Hackers are heroes in our culture. The agile, lean startup, MVP, indie hacker, low-code, etc. trends are all movements celebrating people who can just hack shit together that works right now as being fundamentally superior to artful engineering that builds elegant things at high cost and requiring much more time.
(4) General cultural trend toward "influence" as a career driver. There's almost nothing that opens doors for people today like having a popular blog or YouTube channel does, and peddling simple angry click-bait rants to the masses is an easier path to build a following than careful and considerate thought leadership.
All of these combine to create the mass of "whiny web devs" that you're complaining about.
Finally, to be fair, web dev is such a vast field encompassing so many people, I think you'd be surprised how many people working in web development (including myself, for example), share your exhaustion with the hipster-script-kiddies who think that building things just for Chrome is fine, that framework churn is exciting, that electron is just as better than native, etc. So I think your criticism is on point and justified, just be mindful that you're painting with a very broad brush and there are loads of web developers who aren't on this whiny "chrome is the only computing platform" bandwagon.
And I'm not even talking about some newfangled APIs like WebUSB and such (I don't really care about those personally). Safari's handling of regular HTML + CSS is regularly broken compared to other browsers. (At least in my experience.)
Open the site in Chromium. Yep it works. Open the site in Firefox. Yep it works. Open the site in Safari. Ugh... it's broken.
That's something that I encounter on a regular basis.
It's really inexcusable that Apple, being the richest company in the world, has a web browser that's this bad. But they don't really have any incentive to do better. Thanks to their walled garden the only available web browser on iOS is Safari, and since no developer can afford to ignore iOS as a platform they have no choice but to deal with it.
IE gave us wonderful features (XMLHTTPRequest) but as soon as MSFT found they had a monopoly, development stalled and the world got stuck with IE6, which lacked even basic features like PNG image alpha transparency.
When/if a court orders Apple to allow alternative web engines on iOS, and they start losing market share to Firefox, Chrome or Edge because they are including features that Safari does not, Apple will finally put some effort into Safari.
It’s just not on the parts that you and other developers want it to be on. It’s definitely on the parts that I (as a user) want it to be on (security, privacy, and battery life in roughly that order).
It is unlikely that a court will be able to force Apple to expose OS APIs that would allow for the insecurity of WebUSB or WebMIDI on iOS, even if they do force other engines. And that’s a good thing.
- Web USB - Web MIDI - Web HID - Web Push - Web Motion Sensors - Site protocol handlers - Web Serial Ports - Web local file editing - Payment handlers - VR - Attention
That is, I make it so that sites aren’t even allowed to ASK me for those permissions. I know that a regular did a Web MIDI site recently that is sort of neat, but the protocol is essentially impossible to secure.
Each and every single one of those things provides additional security risk, fingerprinting opportunities, and privacy leaks BY DESIGN, and I can’t ever see turning them on.
When I talk about Apple dedicating resources to Safari I mean that IndexedDB was broken for years. And was broken again just last month:
https://www.theregister.com/2021/06/16/apple_safari_indexedd...
This isn’t engineering that priotisises battery life. This is flat out neglect. Aren’t there unit tests for these kind of things pre-release?
I don’t want to be able to interface with a MIDI keyboard on my site, I just want to be able to store data reliably.
Push notifications: no, obviously I don't want seo-loaden-adwords-stuffing.blog to send me push-notifications. But I do want m.twitter.com, weatheralerts.app or m.issuetracker.local to send me those. I don't want cdn.random-ad-network.com to read my location. But I do want weatheralerts and publictransport.planner to read them. bird.watcher is free to use my camera and littlealchemy.app is free to use localstorage.
Apple decides for me that I don't want this. Protecting users' privacy would mean research and innovation in how to make those choices. Anything from centralised whitelists to better UX for those permissions. Apple invests in none of these and instead denies it to all.
If neither Microsoft nor Apple can keep up, and the Hacker News crowd thinks that's okay, we might as well give up on the notion of an open web and rename it the Chrome Platform.
But cui bono? Apple benefits directly from crippling the web since it protects their App Store monopoly, they happen to have the perfect means of crippling the web by ensuring there will be no browser competition on iOS, and it is the area where theyre shipping their worst software. It is hard to believe that it is a coincidence rather than a cynical corporate optimization game.
Is that an opinion or do you have insider knowledge?
I did not say they did not. What I said was...
> that does not materially help the bottom line.
Security, privacy, and battery life sell phones. Better PWA and WebRTC would cost them money because those modern Web technologies compete with the App Store.
Because that's what people want.
In the context of Apple's Safari engineering priorities, which is the context of this discussion, Apple has delivered real security, privacy and battery life wins. This isn't even disputed by Apple's detractors.
Even if a court does something like “you must allow alternative browsing engines”, it’s going to be a very difficult thing for a court to rule _successfully_ that “you must allow unrestricted USB access to alternative browsing engines”, as that will completely destroy security.
It’s also what would be required to make people who hate Apple for not implementing the same privacy-busting and security-nullifying APIs that Chrome has done.
I definitely feel like comparisons to IE are apt.
I ran into this on a project a year ago, where our app was completely and critically fucked on Safari with no obvious path to fixing it, short of tearing out a ton of custom data visualisation stuff based on SVG and rewriting it from scratch to use a whole different approach like canvas.
It's one thing to have a rendering bug like Chrome had with flex box a while back where it would stretch elements vertically in certain situations against the spec, there's enough ways to do things in CSS that that can be worked around with a bit of tinkering. But when you've got a rendering bug and the dev tools doesn't accurately represent what's being rendered, it leaves the developer in a terrible situation where they're stuck with a black box with a broken interface so they can't even tell what the true result is, let alone see the inner workings.
I was lucky we only had 5-10 people trying to use it on Safari and I could just say sorry and recommend Chrome. But I can't imagine how frustrating a similar situation would be with a large number of users.
I started using Safari as my daily driver because I use all apple devices and I like extending my battery life. Before deciding that, I did stints with Firefox and Brave, both of whom had poor sync'ing.
I can't remember the last time a site had broken HTML/CSS with Safari. My impression is the desire to have good mobile support keeps Safari support alive.
I think I encountered more broken CSS when I was using Firefox.
I didn't mean that as "broken in the wild". I meant as "broken when I'm actually developing a website".
> I can't remember the last time a site had broken HTML/CSS with Safari. My impression is the desire to have good mobile support keeps Safari support alive. I think I encountered more broken CSS when I was using Firefox.
You're not seeing broken websites on Safari because everyone's forced to test (and fix!) their websites for Safari due to its market share.
On the other hand Firefox's market share is relatively low, and dwindling day-by-day, so there's less incentive for everyone to actually test and fix Firefox-only issues.
That said, I use Firefox as my main web browser, and personally I find it very rare for something to be broken under it, even when it's not officially supported. It probably highly depends on which exact sites you visit though.
Those same divs have border-radius applied, and are nested in another div with overflow:hidden. In FF/Chrome, the image scales as one would expect. In desktop Safari, during the CSS transition, the border radius of the overflowing element goes away and the element with the scale suddenly has square corners outside of the overflow. Once the transition ends, the corners disappear again.
This is on the Safari Technology Preview version
Recently they also broke localStorage & indexDB which are core features of the web (sill broken on the latest stable)
If Safari recognises and/or honours the backfaceVisibility CSS property, then I've yet to implement it correctly on a web page[2].
Safari doesn't allow SVG filters to be applied to <canvas> elements[3]. Applying SVG filters to other elements is (I think) fine.
Talking about Safari and the <canvas> element, Safari will show an italicised text (ctx.font = "italic 12px Arial, sans-serif") to be stamped onto the canvas, but emboldened text (ctx.font = "bold 12px Arial, sans-serif") displays as normal, non-bold text. If you want bold text to show in a canvas element on Safari, you need to use a specifically emboldened font.[4]
... the list could go on (and on) ...
Examples
[1] - https://scrawl-v8.rikweb.org.uk/demo/dom-002.html
[2] - https://scrawl-v8.rikweb.org.uk/demo/dom-008.html
>My impression is the desire to have good mobile support keeps Safari support alive.
I would very much argue the opposite. A good browser in iOS is directly against what Apple want (people in the app store, not in browsers). Safari is at best the absolute bare minimum a company like Apple can get away with and not a line of code more. Having just redesigned our business site I have just finished fixing the site to be the same in Safari as in the other browsers. I was forced to do this extra work to not exclude Apple customers but if I could have left it as is I wouldn't have wasted my time.
Like IE6, Safari is not a normative subset of web standards.
The technologies I want never actually "win". I always have to choose the one that I either hate the least or has some other compelling benefit. The latter is the reason why I'm using Safari.
I'd rather Safari come around (or be abandoned), but pressuring Apple this way is not very effective. How long did they hang on to those stupid butterfly keyboards?
This is unacceptable from professional developers. Progressive enhancement is a thing.
Apple announced at last year’s WWDC (https://developer.apple.com/wwdc20/10663) the areas where they improved interoperability with other browsers and that Safari passed 140,000 interoperability tests:
We made a really big effort this year to improve Safari's interoperability with other browsers. One way to measure that is web platform tests. It's a set of tests used by browser makers to ensure interoperability, so your web content operates the way you expect across browsers. So I'm pleased to announce improved interoperability for service workers, XHR + Fetch, pointer events, CSS, SVG, web assembly, and many more areas. Safari passes a hundred and forty thousand new interoperability test cases this year.
And you can look forward to continued progress in this area.
As the sole developer and maintainer of a Javascript library for working with the <canvas> element, most of the problems I encounter when working on the code are to do with things which work fine in every other browser, but die in flames on Safari.
I'm getting to the stage where dropping support of the Safari browser (and thus all iOS browsers) is something I consider on an ever-more serious basis. One of these days I'm gonna add a big banner message to the library's website stating: "If you need your canvas to work on Safari/iOS, try coding it using [list of competing canvas libraries, with links]."
It's not Safari which is outdated, it's standards that move too fast and come ad-hoc to Google's tastes.
And it's not even about the web anymore, it's all kinds of crap to make the browser a slower, duplicate of native functionality, app platform.
Meanwhile Apple are strangling PWAs to hold onto their app store monopoly, and extremely slow to implement features that other vendors adopted long ago. jQueryUI had its life artificially extended by years simply because Apple refused to add a date picker input type. IndexedDB has been nigh-useless without wrappers because of Safari. They've earned their moniker of the new IE.
The weirdest thing about this is that MobileSafari has supported <input type="date"> for years. Desktop Safari only got support in May.
Strangling is a funny word to use. They never implemented PWA features in the first place. They're under no obligation to do so, either. You can argue whether PWAs are good or not, but I don't think such an argument can be made objectively.
I.E., there's a prevailing view in this thread that web browsers are evolving in one direction, and Safari is slower than everyone else at getting there. IMO this is wrong. A better way to look at it is that web standards are a big blob of shit, and each browser is implementing the subset of that blob that they think is useful. This is how it's always been.
Mozilla has been neutering PWA recently too. Maybe it's just not a good set of technologies?
Mozilla isn't pursing SSBs at this time, but the core APIs of PWAs are still being supported. Their position stems more from a lack of manpower than any strategic decision.
That doesn't seem to be what Mozilla thinks, which is that it was never reliable and no one used it:
> “The SSB feature has only ever been available through a hidden [preference] and has multiple known bugs,” Mozilla’s Dave Townsend explains in a Bugzilla issue tracker. “Additionally, user research found little to no perceived user benefit to the feature and so there is no intent to continue development on it at this time. As the feature is costing us time in terms of bug triage and keeping it around is sending the wrong signal that this is a supported feature, we are going to remove the feature from Firefox.”
https://www.thurrott.com/cloud/web-browsers/mozilla-firefox/...
In my day job we've been building physical devices and rather than building say an iOS app and an Android app that would have to be updated and cost a huge amount of money we went the webUSB/webBT route (hang on hear me out) which is actually an amazing technology, allowing us to do things like transfer data to the device all through the browser, we even plan to open the API so users can build upon it.
Complete breath of fresh air compared to having to write custom apps for each platform and I'm happy we're able to do things that if our company goes under our devices wont become paperweights because the tech is all open and runs in the browser.
Of course this all falls apart as soon as you hit iOS, so eventually we'll have to hire in an iOS developer to write some wrapper for the website and connective tissue between the missing APIs.
Apple's sandboxing and permission models are so aggressive that them pretending for a second that they can't implement webUSB and webBT without good security is absurd, it's simply to ensure only Apps can do "grown up" things like connectivity and full hardware acceleration.
Becomes even more absurd when every modern app on their store demands my contacts to even use the app, where was your care for my security when designing and normalizing that permission flow. [1]
I understand that it would enable many good things, but the world’s just too full of assholes to trust random web applications with such power. The amount of security exploits and spyware they would enable is just too great.
Putting them behind additional permission-prompts is not a solution. The amount of such prompts is already too high, and too many users can be tricked into saying yes.
Do you have an example of how these technologies have been used for ad tracking? I hear this as justification for Apples actions a lot but haven't seen it myself anywhere.
And once hackers figure out a device they can use for attacks, they’ll tell the user some nonsense reason why they need to allow access and then pop a dialog for that device and hey presto you have a massive security mess.
I don’t know any concrete exploits, but the theoretical application is not complicated. Any information you can access about the user’s system (like what USB or Bluetooth devices are visible) will be used for fingerprinting purposes, just like they’re already using screen resolution, fonts, canvas tricks, etc.
Look at something like a C64, which has remained basically unchanged for a few decades and the original is long out of production; and yet people are still writing new software for it. Bugs and limitations become features to be exploited for new avenues of creativity and awe.
Then you have the Google-ified vision of the web, also known as the "modern[1] web", where it churns the "standards" and its browser frequently (often to the detriment of user control), new frameworks spring up by the dozens every week, and websites become overly bloated and stop working in anything but the latest version of Chrome because some trendchasing hipster decided to use $trendy_new_framework that executes a bunch of totally unnecessary code and crashes on attempting to use some new feature, nevermind the fact that the site itself doesn't even require it and could've been written in simple HTML to be perfectly functional down to IE5 or even Lynx.
https://news.ycombinator.com/item?id=25915313
I'm not an Apple fan, but in this case I'm on their side in attempting to hold back the insanity the "modern web" has become: "an enemy of an enemy is a friend".
[1] I increasingly find the presence of that adjective to be a reliable indicator of a bad experience.
However, I think the main complaint here is that Safari is missing support for some pretty low-hanging fruit. Take notifications for example: there's a whole wealth of web-based systems where the user might want to receive notifications, but where building and distributing native applications is completely infeasible. Do we need the ability for websites to send notifications? Of course not. Does it suck that out of every modern browser (including desktop Safari), only mobile Safari doesn't support it? I think so, personally.
There's not one site that's allowed to spam me with notifications on the desktop, and I'm thrilled beyond belief that they can't do it on my iPhone.
And Edge now doing it more aggressively. It tries to collect statistics from users. If most user say no to your website. Your site's permission prompt is going to be judged as spam and ignored by default for everyone (not even the popup is going to show, you only can enabled it manually in setting now)
It helps immensely with no noticeable loss in performance. My fans no longer spin up watching a video on YouTube or DRM protected content from a streaming service, and the computer isn’t hot to the touch either.
Obviously it can't be fixed because it is just not loaded yet. Safari is doing so much things that will be treated as a bug by QA and designer (While it is actually completely intentional)
Progressive Web Apps are a Chrome-only thing by now, since Firefox has practically stripped support. (This was a somewhat experimental thing, anyways, and there are strong arguments, why users should be able to discern installed programs from external websites. You may argue that this makes much sense for Google, but isn't that desirable from an OS point of view.)
WebRTC: While it's true that Safari was lagging significantly regarding WebRTC Data, a basic implementation (for media) isn't exactly new.
Then, there is actually some leeway in the definition of some standards (e.g., storage) and it's not automatically clear that the way, Chrome does it, is the right one. (By the same argument, you may propose that typed arrays must be slower than normal ones, since this is how it had been in Chrome for several years.)
What's rather annoying for developers, on the other hand, is that Safari is following some common trends as propagated by Chrome. E.g., Safari has stripped its comprehensive list view of loaded sources, which had been quite a selling point.
Finally, yes, Safari has a much slower release cycle. However, if you care for compatibility and do not assume that everyone is driving the latest release of an evergreen browser, this shouldn't be much of an issue.
Edit: As I recall it, Safari was an early adapter of the standard (even before its release), which comes with its own caveats. And it's actually because of not breaking things that there are these Safari idiosyncrasies. (The alternative would have been some kind of rolling prerelease standard, as it had been with Web Sockets. Which means, the API remains somewhat obscure and fragile, even, when it is eventually frozen, and developers have become accustomed to using some wrapper, anyways.)
And it isn't so that Chrome wouldn't do it, as well. E.g., a few years ago, Chrome had a major rewrite of the Web Audio framework. With this, any newly created source node would point to a null buffer and any calls to the `play()` method were triggered immediately, referring to this null buffer (instead of automatically pointing to the processed buffer source, as soon as this becomes available, and postponing the call in the meantime). This meant in effect that you could practically play a sound from its decoding callback only (which is somewhat optional and only seldom used). At this point, the Web Audio API had been around for several years and this was breaking about every use of the Web Audio API, there was (including Chrome's previous implementation). Turned out, the standard wasn't exact on this – and it took Chrome several revisions to fix this issue (in the meantime, you could work around this issue by user-agent sniffing only). The standard was eventually updated to define the specific behavior.
(This is probably also why most developers ignore the Web Audio API for the most and use some wrapper instead. Which is much like using jquery to work around IE idiosyncrasies.)
Also, what would it have cost Chrome to implement KeyboardEvent.keyIdentifier to provide a somewhat compatible API?
(This is a fallout of the constant struggle between advertising and browsers, compare the restrictions for auto-play videos. Regarding the latter, if you're not white-listed by Google, you're out of luck on Chrome and your entire site is broken. Safari's restrictions on audible sound are actually transparent in comparison.)
Nowadays, as computers are often longer in use as they are in the support/update cycle, it would be really nice to be able to update Safari beyond the OS level. I get it that Safari is basically running the OS web-view framework and that there are serious issues with this (edit: meaning, updating a single framework out of sync with the rest of the OS), but you should be able to update Safari as a stand-alone application, even, if this means that it's practically running in virtualization using it's own framework overlays.
From my perspective, Apple's conservative attitude is a positive. There are all sorts of web techs that enable the possibility of increased tracking, of websites being generally malicious, of all sorts of things that I don't want.
Historically Apple has been on my side and I will continue to appreciate that until demonstrated otherwise.
Firefox on Android is an excellent browser. Firefox on iOS could be the same if Apple let go of its chokehold.
One of the few things which holds me back of switching to an iPhone is a true version of Firefox
Mozilla certainly keeps the source of their funding in mind when making certain key decisions, in much the same way that elected officials do with respect to their donors. In fact, it's even more significant because Mozilla's funding primarily comes from a single source. And you can't just piss off your sole major benefactor without consequence.
The argument that they have the luxury to make independent decisions would be more plausible if their foundation were funded out of a legacy foundation or something like that.
If I look at Pocket and some of their surprise telemetry decisions, I think it's a reasonable implication. They care more about the standards and "providing an alternative to X" than they do the end user.
1. they can be abused (PWAs)
2. are complex to implement (WebRTC – for the longest time the recommendation in the WebRTC community if you wanted to build a C++ app was to bundle a good chunk of Chrome's libraries)
3. or could be bad for battery (web workers)
So yeah, it makes some developers' jobs harder but generally there's a good reason for punting features.
If they made Safari on iOS actually good (re: PWA notification support), it would burn into their App store profits.
Video streaming apps (eg. Netflix / YouTube Premium) come to mind, but they don't rely too much on in app purchase I think. That leaves news apps like the New York Times which need notifications to deliver breaking stories, and perhaps dating apps with messaging/photo features.
Thing is, for every New York Times, there are tons of "news" clickbait content farm websites out there, and I certainly don't need to elaborate on the risks of "free-for-all" dating apps with no enforced guidelines.
I'd much rather Apple end the anti-steering rules where apps are not being allowed to tell people that they can subscribe on the website. Congress is working on this[1].
Or maybe it's just selection bias - we don't see these types of apps because the experience is so fundamentally broken, noone ever bothers to develop them.
Personally Im not so optimistic. 30% is a huge chunk of revenue and is completely unworkable for anything that doesn't have a huge margin built-in.
There is also a very interesting project for programming certain ESP32 boards using WebSerial for easy to use home automation. You import some yaml and flash an ESP32 board without ever even installing the Arduino SDK. I think the problem is they we've reversed the question here. Why on earth should it even be acceptable that websites need an app for something as basic as watching videos, reading the news or checking the weather. Youtube and Netflix have no need for a native application if the developers actually cared about performance of their website. Especially Netflix should just work, because their web app also needs to work on ancient smart TVs and therefore has strict performance requirements.
Dating apps where the most engaging thing you do is swipe in a direction and type into a basic chat screen also have no need for native code. There's a good reason Tinder works just fine as a PWA on every platform other than iOS.
Those "free for all" dating apps do exist and have always existed. If they're illegal or immoral it's not up to Apple to pass judgement, that's what the legal system is for. I, for one, do not accept the tech overlords as my government.
The Figma Electron app with a large document open can bring my less-than-a-year-old MBP to its knees. Figma and Teams at the same time? Forget it.
The same document in Sketch is fine.
The typical concern is that a phisher will use to make a page that looks like Google's sign-in page and display it in fullscreen mode. This would let them collect credentials while mirroring the input in a real form that'd be filled in the background.
The new iOS 15 safari is full screen (and you’ve always been able to add to home screen to make a website really fullscreen)…
That does not excuse Apple’s cavalier attitude towards bugs, but many of the APIs they refuse to implement deserve to die, like WebUSB or Bluetooth access, because of the privacy or security risks of weakening the browser sandbox. Has Google not learnt from the ActiveX fiasco?
For most people this stuff is unnecessary, which is why there's permission prompts to these APIs, bbut for certain use cases they're very convenient. Google made a tool that allows flashing firmware onto their Pixel devices directly from websites instead of requiring admin permissions to install some kind of one-off binary tool, for example. Then there's the ESPHome flasher which is very convenient.
ActiveX allowed for breaking out of the web sandbox and running native code, these new APIs don't. They allow more direct communication with devices, but only with permissions and even then with limitations.
If I want a website to communicate with a device, I'd prefer it if they'd stick to the web sandbox instead of requiring a native tool. These APIs help prevent an ActiveX world where everything needs an app that runs native code, with all security implications that comes with, and help people stick to the web sandbox.
Perhaps that's why Apple refuses to implement certain APIs, they make billions from the ActiveX world that has come out of the app store.
How? Because last I checked Web Workers are only active when there is an active tab. Service Workers live a little longer than that but only around 30 seconds or so last time I looked in Chrome (and that’s an implementation detail, not something in the spec), unless the user has enabled push events and you send one.
You mean Chrome was a fork from Webkit when Google decided they could no longer play nice with Apple...
Safari's WebRTC implementation is not outdated, it's just bindings over the same library that is used and developed by Chrome. At worst, it's lagging a bit by a few months.
What the post highlights is how some features are not available, like some codecs on some platforms. That's unlikely to be a decision from the browser engineers but probably closer to the lawyers who need time to approve a codec or other engineers working on HW acceleration.
Another point is also that while WebRTC was available in most contexts, getUserMedia wasn't, and that's the API used to access cameras and microphones. Without it, WebRTC functionality loses its appeal. I believe that's now fixed and webviews can now use it.
While I don't necessarily approve of those decisions for the users' sake, I still respect their choice to be able to make decisions on their own product and chose when a feature is deemed safe for release in potentially dangerous contexts. I don't know their security model, but from talking with the engineers on many occasions, they are not unreasonable people.
And while Safari is lacking some new WebRTC related APIs released in Chrome, it would be fair to say that they are not all standardized yet at the IETF or W3C level. Other browsers don't necessarily implement them either, and that's fine.
OP indicates Safari prioritizes speed and privacy. Speed and privacy are often in conflict with the proliferation of features and web APIs that you see in chrome (web MIDI fingerprinting anyone?). I'm not sure it's fair to equate this difference in focus to 'the new internet explorer'
Google is the web. Chrome is the web. It shouldn't be true, but it is.... almost.
Safari, or more specifically Apple's requirement that all web rendering on iOS be done using WebKit, is THE ONLY thing standing in the way of Chrome's market share being functionally 100%.
If you care about the web, and one would presume that web developers would care deeply about the web, Safari ought to be your best friend, regardless of which of Google's "standards" it doesn't implement.
If Apple cared as much as they say about privacy, they should install Firefox as a default not because Safari has privacy issues but because then Firefox's market share can grow, which is good for privacy.
I know Firefox will inevitably decline one day, but honestly it's still a great browser and the compat complaints are over-blown.
Apple's hardware and integration is incredible, but I don't understand why people like their software on its own.
This led me to accidentally install the LastPass desktop app, which I have much less in; I didn't see a LastPass webext despite being available on other WebKit browsers.
It doesn't follow that you should support Safari blindly, without criticism, simply because they offer some competition.
It's reasonable to want competition to Chrome, but to believe that Safari is doing so very poorly.
* for e-commerce all customers matter
I have this uneasy reliance on Chrome for supporting PWA's properly since Mozilla lost interest.
It's a life/routine manager for people with horrible memories. Chrome stands alone in supporting web push notifications :S
By relying on Chrome, the least privacy conscious web browser in existence? Not really.
Just make an app. All of the benefits, fewer privacy compromises. But, it requires more work on the developer's end, so I also understand why they might not want to. Just stop trying to paint their decisions as being privacy conscious.
The big problem from my perspective is in the user experience. On my first visit to a site, they ask me if I want notifications. It's my first visit, I know nothing about the site. Why would I say yes? Later, if I had changed my mind, I might want to, although in most cases, I'd rather just use an RSS feed and get updates when it's convenient for me rather than for them. I have yet to encounter the scenario where website notifications are better than old-school RSS.
On the privacy front? I don't see how this helps in any way with privacy. It seems like it would be more likely to be a privacy nightmare than a privacy boon.
They are not the nuisance you are making them out to be.
Here was a discussion from January: https://news.ycombinator.com/item?id=25589177
It is still possible to use Mobile Safari to add App Icon: https://github.com/wekan/wekan/wiki/PWA#ios-safari
And that app icon does open PWA app full screen.
I'm maintainer of Wekan https://wekan.github.io , Wekan also works as PWA app.
For best mobile experience, enable drag handles:
https://github.com/wekan/wekan/issues/3755
There has been fixes to HTML/CSS/JS so Wekan also works well on Safari.
Apple M1 with Safari has fastest Javascript execution.
Safari works well enough for me.
Websites can get Home Screen shortcuts; this has been a thing since the original iPhone.
In 2020, lots of universities required students to install fairly invasive stuff on their computers for remote learning, but -- thanks in large part to Apple's policies -- their phones remained pretty much untouched.
Furthermore, Proctorio and plenty of other invasive testing software has no trouble running on a Mac. Your last sentance is about as coherent as thanking Google for stopping McGraw-Hill from spying on Android users.
Because the web is mostly useless if any of those are turned off now - even easy cases like static forms commonly break with javascript off rather than degrading to just server-side validation.
Thats not to say they shouldn't support additional web functionality for everyone, just that "Add to Home Screen" is likely never going to unlock additional native hardware capabilities or exclusive background processing modes.
This is also why every browser implements web extensions via a store model. The store model allows the browser to serve as a port for auditing and revocation on abuse, because that is what the capabilities of web extensions require.
iOS Add to Home Screen is a neglected bookmarking feature, buried within a context menu few users scroll into. It's effective, but presenting it as a viable alternative to Progressive Web Apps is unrealistic.
> But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.
Funny that the author thinks that the two things are not connected. Lack of support for key web APIs (meaning WebRTC basically) is perhaps what's keeping Safari users' privacy.
Keeping up with the crazy pace of Web API evolution in a safe way and without introducing vulnerabilities is probably impossible even for the browsers pushing for all the craziness that's turning browsers into Operating Systems.
If Apple's goal isn't to stifle App Store competition, then its goal is most likely to ensure that all web developers have to own and use Apple products. In that regard, they're basically succeeding: you can't rent macOS VMs for short periods now, emulating iOS outside the simulator on Apple hardware is very limited and mostly only done by security researchers, Safari has not been available outside of Apple hardware for a long time, and Hackintosh has been beaten down for a long time. The most reasonable option, basically OSX-KVM, still won't get you GPU acceleration, and is a clear EULA violation on non-Apple hardware.
Their strategy becomes especially self-evident when you look at WebM support. Suddenly, Apple is supporting WebM in Safari... only on macOS, where they have no choice but to compete with other browser engines. I'm so fucking sick of this shit.
It's time to stop defending Apple simply because there's a perception that they're being a prick to Google. They're being pricks to us. If we needed a savior, I can tell you for sure that savior isn't Apple. Doubt it if you want, but salvation hasn't come and it is not coming. I'm not defending Google because they definitely earned their reputation, but this attitude of blind acceptance of shit Apple does because everyone wants retribution against Google is stupid. When Apple throws a shit fit over web standards (cough WGSL cough) the party that loses isn't Google, it's us. Apple is a behemoth company that has an inordinate amount of control over the web and web standards considering how much it doesn't seem to have the best interests of the web at heart.
This rant is brought to you by every single time my code written and tested in Firefox worked totally fine in Chrome and Edge, but not Safari. It feels like this is almost every single time I do anything non-trivial anymore.
I'd like to reiterate that I am not saying Safari should implement dumb crap like WebMIDI or WebBluetooth, nor am I saying that I have any problem with their privacy or security features. All of that is fine, but it's not any more heroic than Firefox which, for all its flaws, also does a lot of the same stuff.
I don’t understand why this doesn’t get more attention.
It is just infuriating if you can’t use a security feature, just because some browser doesn’t follow the specs correctly. Oh well, time repeats itself just like with IE.
And just for a moment we thought we are behind all of this.
Public example: Context menu - copy message link to clipboard - on discord doesn’t work in safari.
I created a bug for their bugzilla, turned out that bug is fixed some time ago. BUT NOONE CAN TELL ME WHEN ILL SEE IT FIXED on my device.
If I open 15-20 Freshdesk tickets in a row each in new tab, safari slows down as hell.
If I use the same page on Confluence for 30 minutes editing it without refreshing, at some point safari will start saying that THIS PAGE eats too much power it might need refreshing.
I as a user do not care.
Ah one more, safari 14 after initial release had a bug with scrolling on Mac and it took them 7 months to push this fix from nightly version to stable. SEVEN.
Here's a thought, Mozilla does a lot of political campaigning, how about campaigning for open app stores and death to no other browser engine? Why not do this which seems like a do or die situation for them?
I wouldn’t say twice a year is infrequent.
For instance, HTTP/3 support should land in iOS 15 and macOS 12 because it is being added to the operating system frameworks.
Bug fixes can arrive even in maintenance releases, but this is more often seen for security-related fixed (such as remote exploits or side channel attacks)
Safari itself is shipped outside of the read-only container on macOS so that it can be updated independently.
Android support is dreadful, but at least you can run the latest Chrome on Android 4.
Safari's current beta has support for the lab and lch functions.
What I'm saying is not that Safari isn't a hindrance in a lot of ways but there are still standards that it supports better than other browsers and I can run into them on a weekly basis.
Safari iOS: https://caniuse.com/?compare=ios_saf+14.5-14.7&compareCats=a...
Safari TP: https://caniuse.com/?compare=safari+TP&compareCats=all#:~:te...
Firefox: https://caniuse.com/?compare=firefox+92&compareCats=all#:~:t...
Chrome: https://caniuse.com/?compare=chrome+95&compareCats=all#:~:te...
Firefox shipped support in 2011, with Chrome following suite a year later.
It's mid 2021, and the Safari implementation is still critically broken.
EDIT: It looks like the bug has been patched in developer preview, so hey progress +1.
Why should I be excited about Filesystem API and the like when we can already do that on the operating system directly?
It's really easy to understand the rise of Electron in this context. I don't think Electron is the final form, however. There's nothing wrong with web technology - my favorite browser is Firefox.
I love the web but, from an effort perspective, the justification for supporting all these browsers, ESPECIALLY when some of them half ass it, is just not there. It ranges from frustrating to a complete waste of time.
Because it's easier to update to a website than it is to release a ton of binaries ({windows, Linux, macos}x{x86,x64,arm64}) and have users download them.
Not to mention it's safer and faster for the user.
Safer, maybe. Faster? LMAO.
I take the points about not supporting CSS features and some of the other web standards, and the issues around Apple's 30% cut, and I'd add that some of Apple's censorship (eg. banning Parler for a while, asking Telegram and Tumblr to not allow access to certain content) is troubling, but I don't think the way around that is letting any cowboy with a web app send notifications and access bluetooth willy nilly.
Why would adding it to Safari have a different effect? Plus iOS is improving on its notification suppression and its relatively trivial to suppress notifications that aren’t interacted with after some limit.
Most apps you use require network access but you can still interact with them on very slow/broken connection. Meanwhile you try to load a website and it’s a much different experience.
But as for offline apps, I could imagine music/podcast players (where you can save offline media), offline maps, etc.
Apps I'd like to see are Pixlr and RegExr. Any utility like that makes a good PWA candidate.
"If other browser engines were allowed in iOS, Chrome/Blink would take over the web browser market"
Pick one, folks. Either Safari is the best, in which case the WebKit monopoly is unnecessary; OR the iOS monopoly is the only thing preventing users from switching to a better browser.
It doesn't matter if you like PWAs or WebUSB. Or what you think about new web standards. The best browser is the browser regular users choose to use. Good web standards are standards that enable sites/apps that users want to use.
Right now, we don't know any of that because the lowest common denominator for the web is not what users want, but what Apple allows users to have. Claiming that those two things are the same sounds a bit weird to me.
It's surprising that people think that Chrome pushing web standards forward means that "everyone has to do what Google wants", while the only true gatekeeper between users and developers these days is Apple's iOS policies.
If you think that's not true, please answer: if a user in any configuration (device+os) WANTS to access your app and you WANT to develop for them, what set of device+os are mediated and by whom? Whose policies you MUST follow to have access to a (major) set of users?
(disclaimer: I'm a Chrome blink engineer involved in web standards)
As it turns out, not only were safari users not using our product, practically no one was. At the time I had no choice but to carry on, but now that Flutter supports desktop, I don’t see my self doing web apps, progressive or not, in the future.
I’ve been a web dev for well over a decade, but let’s face the writing on the wall—the web was never intended for apps. But HTTP will live on and that’s what matters.
Open protocols is and always was and will always be what makes the web, and I feel it’s time we as developers should be able to and focus on developing protocols once we are provided the tools to do so—but using open web standards like SPARQL and WASM to name two I have in mind—but still semantically HTTP. The best analogy I can think of was what docket did for dev ops.
I honestly feel like the web as we know it today is a lost cause. Not even Google can make sense of all the SEO collusion. It’s all so inhospitable and seedy now and just another marketing channel. But I’m confident something better is on the horizon and I bet many of us here are working on it.
We need devices where the owner decides what is allowed and what isn't, not a tech giant making $64 billion per year in App Store monopoly revenue
They prevent other browser engines and run times to yield total platform control. They shut down any attempt to gain a foothold or alternative.
Let me tell you an anecdote from history,
Microsoft attempted to control the entire web platform. They embedded their browser into Windows, rapidly introduced non-standard features, had authorship tools (FrontPage), publishing (IIS), and were trying to force ActiveX and other tendrils to gain a complete dominance.
They might not get in on every customer interaction or payment (who would have dared to dream?), but they would own 90% of the platform and exercise their control to profit massively.
But they were distracted, shut down by the DOJ, and ultimately failed. Today we celebrate this.
Apple dreamed a different dream. Instead of getting every smart phone customer, they'd enforce total commercial control of their platform and then gradually increase the size of their pie.
Apps, subscriptions, movies, music, Apple Pay, Apple login, no outside payment, no runtimes, no alternative distribution...
It worked like a charm.
Apple has an ecosystem that plays well together, services that are compelling, and people love it. Half of Americans use an iPhone, and many use it as their only device.
The unfortunate problem is that by growing their pie so big, Apple crowds out the entire computing industry that gave rise to their capabilities. Half of everything we do now has an Apple tax.
Apple was crafty and played nice just long enough to build a wall around their customers. And now you'll never reach them without being taxed. And they have so many customers...
Apple customers. The most locked in of all, and Zuckerberg is steaming with jealousy.
Apple owns computing. Half of it, anyway. And they won't dare let it out of the box.
The DOJ breaking this regime is our only hope. That, or a new tech cycle that might (but probably won't) upset the incumbents.
> But most of us know the dominant reason is because fully-capable PWAs would compete against the iOS App Store – robbing Apple of 30% cut in revenue it rakes in when an app is purchased, or an in-app purchase is executed.
The rest of us don't know this. Maybe the author can enlighten.
Honestly, my sense is that app stores have become mechanisms for delivering free content. Few pay for software anymore. I don't imagine Apple is really standing to lose much if a few apps went PWA.
> - Run full-screen (no visible browser UI)
> - OS-level notifications and alerts
> - Ability to use the app when the device is offline
> - Local data storage and retrieval
> - Install an app icon on your smartphone’s home screen
> - Access to hardware functions such as the camera, microphone, USB port, etc.
None of this functionality belongs in a web browser.
Apple is just protecting their app store revenue by not improving ios safari.
If "UX expert" haven't heard about PWAs then...
As the article itself admits in the end, Safari is a great browser. It just falls short in a few key areas that really upsets the author.
I’ve been a web developer for neigh on two decades. Safari has easily been the browser that gave me the _least_ headaches. Apple might not be the fastest to implement the newest standards, it’s pretty good at implementing them properly.
Previous HN: https://news.ycombinator.com/item?id=27019077
iPhone is like a Tesla. Most Android phones are like an old beat up Volkswagon from 1973. I love the fact that both exist.
Good or bad “Low volume high profit” is very common in the Apple ecosystem and we devs have to just live with it
Not really. There still are IE-only webapps ran by some government agencies.
Say I’m FunCorp and have two apps, FunTrack and FunRate. FunCorp doesn’t believe in native apps, or App Store at all.
Could FunCorp submit a single dummy app, FunStuff in the App Store that allow FunTrack and FunRate native functionality without the App Store?
E.g if you install FunStuff it’ll have some dumb functionality like be a calculator but also send you native notifications of FunTrack and FunRate which are web apps.
I imagine not but if so I’m surprised it’s not done more
Very hard to debug if you're not on MacOS.
If they cared about having an alternative browser or a good experience, they'd let Chrome run without being hamstrung by webkit.
ublock origin discontinued support
Build your websites with progressive enhancement in mind, and you'll never have a problem with safari again. Safari is great.
For the overwhelming majority of users, life on iOS is peachy.
I don't want PWAs. Apparently Google is their biggest promoter and Chrome has the best PWA support but the apps still stuck. I prefer to leave them open in a Chrome tab than have it pop out and pretend to be a native app. So good on Safari to not support it properly, it does not provide any benefit at all.
> Lagging support for WebRTC and other features
Again, I don't care. Just write a native app if you want to do video/audio calls, or send/receive files. The worst native app for these purposes is better than the best WebRTC implementation.
> Bug and infrequent updates
All software has bugs. When Chrome has one, webdevs are forced to hack up a workaround. When Safari has one, they complain.
Please leave safari alone. It is very good as it is. We don't need any more newfangled web "standards" which are mostly pushed by Google so that they can justify not writing native apps for any of their products. Enough is enough Google, just write apps for the platforms you want to sell on.
Google Meet and Jitsi are fantastic, in my opinion. Zoom however has had a constant parade of vulnerabilities over the last year.
Chromium is used on the web, desktop and alternative browsers. For users there is no escape, Unless you want to use a browser that is has a suboptimal browsing experience (Firefox)
> Did you know that it’s possible today to create something for your browser that works like a native app on your device?
Nope. Not at all ready yet and good luck on iOS.
> We’ll see what happens.
Nothing is going to happen, Even after the anti-trust hearings.
Apple’s lawyers always find a way.
As for the web in general, well it just switched from one giant to another.
To Downvoters: So Chromium is NOT used on the web, desktop and on alternative browsers nor it is the most used browser and it is NOT the best supported browser?
Are you sure?