EdgeHTML to Blink/V8: The future direction of Microsoft

Microsoft recently announced that having tried (and failed) to make Edge a success (link) that they’re going to dump the EdgeHTML rendering engine (along with the Chakra javascript engine) in favour of Chromium which is made up of the Blink rendering engine and V8 javascript engine – both of which Google use to form the basis of Chrome. Having read many articles, what I thought would be best would be to have a look at how we got here – how did we go from an optimistic Microsoft that believed if they just knuckle down and created a great browser that conformed to open standards that everything would fall into place. Unfortunately what they ended up finding was something Sun Microsystems found out years ago (anyone remember when Scott McNealy talked about Solaris on x86-64?), the best engineered technology doesn’t always win in the end.

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.

When it comes to Microsoft’s relationship with Windows, are we going to see Microsoft strip Windows 10 of all but the bare essential win32, everything else is UWP/XAML based and essentially it becomes ChromeOS-like aka EdgeOS. With that all being said, Peter Bright over at Arstechnica wrote an interesting piece (link) on this matter but ultimately this is the new reality for Microsoft (I personally would have preferred they went with Webkit due to it being more efficient light weight) and I think it is time that Microsoft also starts to have a look beyond this – their compilers and whether it makes sense developing their own when they could be better off building a top notch IDE on top of LLVM/Clang, whether it makes sense to develop its own C++ and C library etc. Basically rationalise in the same way that Apple reduced their product line up – it makes sense to develop DirectX because it gives you a competitive edge but does it make sense to develop your own HTML and Javascript engine when it has become a commodity (given the amount of resources expended on EdgeHTML, whether those resources were well spent).

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.

One thought on “EdgeHTML to Blink/V8: The future direction of Microsoft

  1. I feel Microsoft had no choice but to adopt Chromium in order to adopt Edge to more platforms. I think Microsoft made a big mistake not creating a Edge for Windows 7 in order to keep users involved in using a modern Microsoft browser. Most Win 7 users were adopting Chrome for no other choice then not wanting to use Internet Explorer. It was a huge blunder on Microsoft’s part to ignore Win 7 users. I never fully liked Edge, although I did find it got better with time. Sadly that time was too long and it soured many users on it before it got better.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s