At its peak in 2004, Microsoft’s Internet Explorer (IE) accounted for an estimated 95 percent of the browser market. As Firefox and Chrome grew more popular, it became increasingly important for web developers to build websites with cross-browser compatibility in mind.
IE caused web developers a lot of pain, however, because many bugs applied exclusively to IE and because it sometimes lagged behind in implementing new features after the W3C standardized them.
IE was so popular that it maintained a persistent market share even after Microsoft themselves moved on from it with Edge. In 2016, the company ended support for all versions under 11. While Microsoft will update IE 11 for the entirety of Windows 10’s lifespan, they are aggressively pushing to get people off of IE. Microsoft services will drop support in 2021, and Windows will start to automatically launch certain websites in Edge when users try to open them in IE.
While IE is very close to becoming a relic of internet history, some people have claimed that Safari is the new IE. Let’s consider the similarities and differences between the IE and Safari situations to see how valid the comparison is as we head toward the end of 2020.
Being the next IE implies having a market share that is large enough for many developers to worry about. On desktop, Chrome is the clear leader, with about 68 percent of the market. Safari is second with about 10 percent. That’s a fairly large population on its own, but the bigger reason developers have to pay attention to Safari is because of its mobile version on iOS and iPadOS.
The vast majority of iPhone users use Safari. But it’s also important to know that Safari’s engine, WebKit, is the only browser engine allowed on iOS. Even Chrome and Firefox for iOS have to use WebKit under the hood to comply with Apple’s App Store review guidelines:
Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
So any web developer who cares about iPhone and iPad users absolutely has to care about Safari.
Nevertheless, the overall situation is much better than the past one with IE. Safari is still only about 19 percent of the total browser market. That’s nowhere near IE’s former level of monopoly-like dominance.
Unless a website has a disproportionately large iOS and iPadOS user base, any issues with Safari are unlikely to be as severe in impact as issues that were unique to IE in its heyday. “This bug affects 95 percent of our users” is simply not as alarming as “this bug affects 19 percent of our users.”
Another big issue with IE is its relationship to new Windows versions. Each version of Windows only supports up to a certain version of IE. For example, Windows XP only supports up to IE 8, and Windows Vista only supports up to IE 9.
So even if new IE versions fixed issues and implemented features, there was still the problem of users being stuck on older versions of IE because they hadn’t upgraded Windows. Safari is in a similar situation because its updates are also tied to OS updates. However, this is mitigated by a couple factors.
The first is that OS updates are free now. In the past, we had to pay for new Windows and OS X versions. Now that they’re free, there is much less friction in getting people to upgrade.
Apple is also persistent in pushing updates, such as by issuing repeated prompts to update. New iOS versions tend to reach high adoption rates soon after launch, especially when compared to adoption rates for new Android versions.
It also helps that Apple supports devices going back several years. For example, iOS 14 works on iPhones all the way back to the iPhone 6S, which is five years old at this point. As a result, it’s not a big problem in practice for Safari updates to coincide with OS updates.
Can I use provides a comparison of supported features between the latest versions of the major browsers. There aren’t many features that Safari is still missing. Developers have complained in the past about lack of support for things like WebRTC and WebP, but Safari has those now.
Safari does still have some holdouts, such as Web Bluetooth and Web USB. But these are relatively advanced, nice-to-have features rather than features that would be widely used by typical websites. Apple may not always adopt W3C standards, but the impact should not be as severe as when IE was slow to do so for more critical standards.
Mozilla’s 2020 MDN Browser Compatibility Report gives us some insight into the community’s opinions. For the survey question of “What browsers/platforms cause the most issues?”, mobile Safari and desktop Safari come right after IE.
We also have reason to believe that Safari tends to be buggier than other modern browsers because of Bootstrap’s wall of browser bugs. Safari has the most listed issues, and this is probably a good estimation of the overall situation since Bootstrap has so many generally useful components.
Relatively speaking, Safari does cause more pain than other modern browsers. But as long as there is competition, there will always be one browser that tends to be worse for development than others. The gap between Safari and the other browsers is not nearly as bad as it was for IE, and the gap is so much smaller that I don’t think it’s fair to call Safari the next IE at this point.
Safari also had its own framework for extensions. First, there was a proprietary system for .safariextz extensions. Apple finished deprecating those in 2018 in favor of Safari App Extensions. But starting with version 14, Safari supports the WebExtensions API that Chrome (and its derivatives like Edge and Opera) and Firefox use.
While there are certain incompatibilities, this is a big step forward for extension developers because at least the core API is the same across all major browsers. Making a cross-browser extension will be much easier going forward.
On the surface, the situation with Safari seems similar to our old situation with IE, but there are crucial differences that make it hard to justify referring to Safari as the next IE. Even if Safari is slower than the other browsers at fixing bugs and implementing features, at least we can expect those changes to make it to end users much faster than they did for IE users.
The pain of dealing with Safari-specific issues is not in the same realm as what web developers had to deal with in supporting IE users. There will inevitably be some degree of difficulty in maintaining cross-browser compatibility, but the challenge is much easier now, especially because resources like Can I use and MDN make incompatibilities easy to know about ahead of time.
Luckily for us, no browser is truly taking up IE’s mantle. I don’t blame any developers who complain about Safari, but there’s a categorical difference in developing for Safari now versus developing for IE in the past. I, for one, am thankful for that.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
$ 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
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.
Efficient initializing is crucial to smooth-running websites. One way to optimize that process is through lazy initialization in Rust 1.80.
3 Replies to "Is Safari the next Internet Explorer?"
No word about PWAs? Safari together with its OS is very much the limiting factor here.
I don’t think the subject was given enough attention. If you were to ask developers why Safari is such a pain, you would have known that Apple takes aaaages to implement new CSS standards, and has a policy of “do what we want to protect our users” instead of leaning towards the standardization of their tools.
There are a lot of important features which are implemented by all the other browsers soon after they are published as new standards, however it sometimes can take up to 2 years to see the support of Safari browsers, if any.
As a side note, there is about 2% of my codebases which are written only to add support to Safari – it should be 0.
Awful. Safari is just simply awful. Had to give up trying to add a nice Spectral Analyser to my MP3 player because it just won’t work with Safari 100% bug-free like the other browsers. And that is just one of the many other issues I had to face with that Chimera. Fancy background-attachment: fixed not working on IOS – that is 90’s web browsing technology! And there is more, way more ….