There has been much documented in the various technology outlets about Microsoft’s attempt to regain browser market share with the launch of Microsoft Edge which coincided with the launch of Windows 10 – a fresh start with a new operating system. The idea was simple, take MSHTML and strip it of all backwards compatibility then label this new ‘legacy free’ core as EdgeHTML. Sounds simple – small problem though, even though it worked great on benchmarks the problem was when it hit the real world the benchmarks didn’t translate to a good internet experience as as noted in a recent Arstechnica article (link)
Microsoft’s own telemetry showed that many users did give Edge a chance, but as soon as a problem was encountered—a crash, a hang, or perhaps a page that didn’t work right—they’d switch to Chrome and never really look back.
So it wasn’t as though consumers weren’t giving Edge a chance but when end users found that the websites they visited didn’t work, never mind the performance slow downs (see second linked quote further down this post) consumers throw their hands up in the air and take the path of least resistance – they embrace Chrome because they know that it’ll ‘just work’ (link)
“For example, they may start integrating technologies for which they have exclusive, or at least ‘special’ access. Can you imagine if all of a sudden Google apps start performing better than anyone else’s?”
This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn’t keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome’s dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.
Now while I’m not sure I’m convinced that YouTube was changed intentionally to slow Edge, many of my co-workers are quite convinced – and they’re the ones who looked into it personally. To add to this all, when we asked, YouTube turned down our request to remove the hidden empty div and did not elaborate further.
And this is only one case.
What Google did regarding the hidden empty div was scummy but it doesn’t change the fact that it was a choice by Microsoft not to implement Shadow DOM v0 and v1 even though Webkit and Blink both had at least a draft implementation (Microsoft didn’t even have a draft technology preview implementation so earlier adopters could test their code against). This is a common theme with Microsoft where they’re just not adding to EdgeHTML the technologies that developers are taking advantage of so you either end up with a horrible experience (as with the case of YouTube) or parts/whole website fails to actually work. To make matters worse you then have 6 month cycle release which results in long lead times between an emerging technology that competitors already support and EdgeHTML not being there to ready to support it.
My possible solution? Have two separate builds of EdgeHTML, EdgeHTML-SystemStable that resides within the system itself that third parties rely on and then have an EdgeHTML-FastRelease that resides within the Edge appx itself – you don’t need to maintain two separate bases but compile two versions. When developing you add the latest features to EdgeHTML-FastRelease and then when it has matured that you feel confident enough that it is stable for third parties to use then you migrate those changes back into EdgeHTML-SystemStable thus getting the best of both worlds – developers get a stable piece of technology and consumers can receive regularly updates resulting in the platform always moving forward instead of big six month lead times along with being able to get feedback quicker on the features being added so then there is faster turn around to address short comings.
With that being said, I think the bigger issue were the number of websites that fail to work with Edge or more correctly, websites that are horribly broken and the expectation by many web developers for the browser to deal with their crappy code rather than doing what the browser should be doing, and that is, the browser giving the web developer a slap and telling him or her to fix their code. Of course, that would be an ideal world which unfortunately we don’t inhabit and I doubt we’ll get there in my life time so alas we have to deal with the world as it exists rather than how we would like it. When you think of the number of websites that are tested against a limited number of browsers then add to that the number of developers who conclude, “well, if it works for Chrome and it does’t work for Edge then that is a fault with Edge and nothing to do with me” with the net result being a Sisyphean task for EdgeHTML developers even if they were to go ‘balls to the wall’ with a quick release cycle and a split distribution model the same problem would remain.
I also think another part of the equation that has been left unaddressed by the technology commentators and that is Microsoft’s long term vision of moving to from being a software company to primarily a service company. Google start out as a services company but then became a software company with the development of Android, Android TV, wearOS, Chrome, Chrome OS where as Microsoft it is going in the other direction where they stated off with software and expanding into the services area. With that migration into services comes the migration from locally run applications to running ‘applications’ in a web browser (effectively the browser becomes a run time framework) which begs to question what the long term strategy is for Windows and Microsoft.
The other part of the announcement was Edge making its way to macOS which also opens up questions regarding other platforms beyond Windows and macOS – maybe a Microsoft branded ChromeOS that points customers to Microsoft’s cloud computing in the future? What excites me about a Microsoft Edge browser coming to macOS is the ability to synchronise passwords and bookmarks along with auto fill information etc. back to the Microsoft cloud service. The other part of the announcement was in the comment section where although it won’t be part of the Windows framework initially that in the long term that it will be become of the Windows framework which opens up big questions regarding PWAs in the future so it’ll be interesting to see how things transpire.