Calling a browser “the new Internet Explorer” is unequivocally something that all modern browser vendors want to avoid. Unfortunately for Apple, Safari has acquired that unwanted label in specific subreddits and the vitriolic Hacker News. Internet Explorer 6 prevented web developers from using many of the latest and coolest web APIs until Microsoft officially stopped supporting it in January 2016. Safari, to a much lesser degree, was doing the same thing.
Before the 15.4 release, Safari — or specifically, the WebKit engine that powers it — was well behind their competition. PWA support pre-15.4 was limited, with no support for home screen icons and notifications. Conspiracy theorists speculated that Apple was deliberately crippling WebKit to protect its App Store business. These accusations do not hold too much water, but Safari still had a passing resemblance to the infamous Internet Explorer.
Below is the moment the penny dropped for Apple Evangelist Jen Simmons:
Everyone in my mentions saying Safari is the worst, it’s the new IE… Can you point to specific bugs & missing support that frustrate you, inhibit you making websites/apps. Bonus points for links to tickets.
Specifics we can fix. Vague hate is honestly super counterproductive.
— Jen Simmons (@jensimmons) February 8, 2022
Poor Jen did seem a bit taken aback by the criticism. The tweet, from February 2022, makes it evident that Apple was not aware that the great, unwashed developer masses think the soul of IE 6 is inside Safari.
Many of us are old enough to remember the dark days of IE 6–11, when web developers embarked on a cycle of fixing bugs specifically and only for IE at the end of each development cycle.
With the advent of the auto-updating Internet Explorer Edge, and Microsoft also helping to rid the world of its old, pre-Edge browsers, Safari has found itself struggling for any popularity.
According to the Web Platform Tests dashboard, Safari jumped from 50 points to 72 on the interop 2022 dashboard with the 15.4 release. So, is there any truth in this scurrilous accusation that Safari is the new IE?
One of the main reasons for Safari’s unflattering new title is that Apple, in its wisdom, ties its browser releases to macOS releases. This makes it take weeks or months to release critical bug fixes. Many, including Rich Harris, have publicly commented on this being a primary pain point for developers:
Exactly this. If browser updates weren’t coupled to OS updates, many of the (legitimate) complaints would vanish. The reason people make ‘counterproductive’ complaints about ‘fixed’ bugs is that users still experience them, because Safari isn’t evergreen https://t.co/nTvlFPvPjV
— Rich Harris (@Rich_Harris) February 22, 2022
In comparison, Chrome has a four-week release cycle. But Safari can take months to ship a minor release:
| Minor version | iOS version | Release date |
|---|---|---|
| 15.1 | 15.1 | October 25, 2021 |
| 15.2 | 15.2 | December 13, 2021 |
| 15.3 | 15.3 | January 26, 2022 |
| 15.4 | 15.4 | March 14, 2022 |
Updates are considered opaque, with no roadmap publicly available and few signals for when new features or bug fixes are expected to arrive.
PWA support has made Safari the poorest relation of Chrome and Firefox. A lack of push notifications is a huge miss for any developer wanting to create an app-like experience in the browser. No support for lazy loading images was a huge hole that needed filling.
Apple added WebRTC support in June 2017, which is roughly four and a half years after Chrome officially added it out-of-the-box. You could argue that this delay impeded wider WebRTC adoption.
Before the 15.4 release, it would be fair to say that Apple had dropped the ball. They at least needed to spit and polish the ailing Safari. Did they succeed?
Apple has added 70 new features in release 15.4. Seventy new features is a significant release that flies in the face of the modern continuous delivery practice of releasing small and often. In comparison, Chrome 99 had 28 security fixes.
One of these is — finally — the ability to lazy-load images, an absolute must for bundle size-conscious and latency-aware developers. Let’s not forget, though, that his has been a feature in Chrome since version 77, released in 2019, and Firefox since version 75, released in 2020.
Safari’s PWA support has improved with this release, and declaring icons in the web app manifest is finally supported. The service worker navigationPreload is a welcome addition that can decrease startup time by allowing network requests to happen in parallel with serviceworker startup. Unfortunately, there is still only experimental support for push notifications.
Any web developer worth their salt has fought many scrolling bugs on both desktop and mobile Safari. The 15.4 release introduces smooth-scrolling, giving developers the ability to instantly jump from position to position and smoothly animate the scroll operation.
Another notable addition is perfect WebRTC negotiation that finally aligns Safari with the WebRTC 1.0 specification. To put this in context, Chrome started adding WebRTC support in Chrome 47, released in 2015, and Firefox started adding support in Firefox 20 released in 2013. Safari was very late to the party and started adding WebRTC support in Safari 13.5, released in 2020!
No push notifications is a glaring omission from this release that has brought the ire of many PWA developers. Web apps or PWAs cannot provide experiences in Safari that are comparable to those in Chrome or Firefox until this feature is added in a non-experimental way on both desktop and mobile. It is a pity this is still experimental because this is still a gaping hole that needs filling for genuine PWA support.
Another feature that keeps me tied to Chrome is profiles. As a freelance software developer, I might have multiple accounts on the go during a working day, and being able to tie these together in Chrome profiles is a productivity boon that others should be innovating on.
Apple deserves a lot of credit for the 15.4 release, and I hope subsequent minor and major releases continue to move the needle in such giant leaps. Apple does, at least now, seem aware of developers’ current perception of Safari, and significant resources do appear to be working to improve Safari.
On mobile devices, Safari is still a clear second place in global market share, and Apple needs at the very least to cement this position to stay in the game, and then push for number one.
At publication time, Chrome is just too dominant. It has north of 60 percent of market share on both desktop and mobile devices globally.
Source: StatCounter Global Stats – Browser Market Share
A consequence of this dominance is that Google developers get too much say in important conversations, such as TC39 meetings. They bring too many proposals that fit their own needs, such as protobuf and Brotli, that end up taking away from other ideas non-Google developers propose. For one, they completely shut down Promise cancellation in one sad GitHub issue that will always stick out in my mind.
The non-Chrome browsers draw comparisons with the search engine DuckDuckGo, a competitor to Google Search that I want to succeed, but I still use Google as the results are better.
Competition breeds innovation, and we need viable alternatives to push the technology forward. Unfortunately, developing against Chrome is the most suitable place for me where I get stuff done fast at this time of writing. I can’t afford to make a stand that does not make ergonomic sense, but
Apple has both the money and development resources to at least level the playing field, if not make Safari a true competitor. But it seems, at least pre-15.4, that they’ve either deliberately chosen not to or were unaware of the need.
The next step for Safari is a clear roadmap and a better update story. I am unaware of the Chrome version number as updates just happen, but I am all too aware of both Safari (and Internet Explorer) versions now. Version numbers should be irrelevant, not infamous.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Handle frontend data discrepancies with eventual consistency using WebSockets, Docker Compose, and practical code examples.
2 Replies to "When will Safari finally get it together?"
Safari might be a safe and fast browser yet it is not a user friendly. PDF documents are not displayed in a readable format. Due to which I had to install a different browser to access my documents. Hoping that it may come to the normal working form very soon.
I do agree but I think the last release does now actually show that time and effort is needed for safari.