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.
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.
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.
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.
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.
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.
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?
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)
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 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.
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.
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.
In practice this means Chrome implements an idea and the idea "wins out" because Chrome does it, until Chrome does a new idea.
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.
PWAs are here to stay.
I should have specified B2B in my original comment though, B2C I have no experience in.
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.)
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.
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.
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.
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.
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.
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.
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.
Name a place where safari is being innovative on the web.
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.
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.
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.
With a bit of effort you can embedded chromium in Emacs so it's basically true.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Element/scr...
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.
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...