Looking back: Microsoft Edge for developers in 2015
2015 was a historic year for the web on Windows. Just a couple of weeks before the 20th anniversary of Internet Explorer 1.0, we broke from the past with our brand new browser for Windows 10, Microsoft Edge. Just five months later, there are over 200 million devices with browsers and apps powered by EdgeHTML across PCs, tablets, phones, and Xbox One. Today, we’d like to reflect on our progress in 2015 towards delivering a great rendering engine for web developers in Microsoft Edge, and share some of the metrics we track to evaluate how we’re doing against that goal.
2015: Building on a new foundation
In 2014, we articulated our ambitions for what would become the new engine for Microsoft Edge when we shared our web platform priorities for Windows 10: getting users current, improving security, and delivering on both modern web interoperability and reliable backwards compatibility. Later that year, we took the first concrete steps when we shipped the first preview of our new evergreen engine (EdgeHTML). This new engine was a break from the past: including a new user-agent string, ending support for legacy document modes and other Internet Explorer-specific technologies like ActiveX, and aiming instead to focus on the “interoperable intersection” of APIs supported by modern browsers and sites across the web.
In early 2015, we announced that Windows 10 would be a free upgrade with a brand new browser, Microsoft Edge. Microsoft Edge is kept up-to-date “as a service,” helping us to deliver on our promise to keep users current. Internet Explorer 11 would ship largely unchanged in Windows 10 for enterprises and other customers who depend on backwards compatibility.
For the rest of 2015, we focused on building on our new foundation in time for Windows 10’s launch in July and the subsequent November update. We delivered: EdgeHTML diverged rapidly from Trident over the course of 2015, with nearly 1200 APIs added, nearly 1000 APIs removed, and over 5,000 interoperability fixes.
So, how did we do?
That sounds great, but doesn’t prove that we delivered the right set of platform improvements for our developers and end-users. There is no perfect measure for this, but numbers speak louder than words, so we’d like to share some of the metrics that we use to validate our progress.
Are we making developer’s lives easier?
All browsers expose overlapping API surfaces, many of which are described in web standard specifications. We gather data on the overlap between them using public interface API definitions. When we studied the data, two things became obvious:
- There were significant differences between all browsers and web standards specifications
- There was an opportunity to increase the overlapping API surface (the “interoperable intersection”) between browsers to make web developer’s lives easier.
This animation shows how Microsoft Edge improved real-world interoperability in 2015, increasing the number of common APIs it shares with Safari and Chrome.
Animation based on analysis of browser API coverage, demonstrating our shift in focus towards the “interoperable intersection” of standards across browsers.
| Google Chrome 48 | Apple Safari 9 | |
| Internet Explorer 11 | 4076 shared APIs | 3769 shared APIs |
| EdgeHTML 13 | 4724 shared APIs (+16%) | 4157 shared APIs (+10%) |
Do websites “just work” in Microsoft Edge?
We knew that we were taking a short-term risk by dramatically updating the user-agent string to ensure that we get content intended for other modern browsers and removing a broad swath of Internet-Explorer specific technologies. In 2014, our interoperability lead Frank Olivier drew a whiteboard graph predicting that after forking EdgeHTML, our initial web compatibility rate would fall well below that of IE11, get even worse as we finished removing IE-specific technologies, before climbing as we fixed interoperability bugs and added new interoperable features.
To validate our decision, we ran a rolling test pass against top sites throughout 2015 to get a sense of how Microsoft Edge compatibility was doing. The result exactly matches the trajectory that Frank predicted: It shows that although we initially had a lot of work to do to handle the same content as other modern browsers, EdgeHTML 12 was roughly at parity with IE11 by launch in July and grew to be significantly more compatible when we released EdgeHTML 13 in November. Best of all, these compatibility improvements are “durable” and scale to the tail of the web, since they are not dependent on the CV list, which was previously used to force IE11 into older emulation modes in order to make many top sites work.
Chart showing pass rates for internal compatibility testing on top sites.
Are we delivering new platform features quickly and predictably?
In addition to making existing sites work, we also needed to deliver the next set of features that web developers are using to build the next generation of the web. With Windows shipping continuously and public early access via the Windows Insider Program, we’re now able to preview and deploy improvements to our platform faster than ever before, all without fragmenting the Windows customer base. As evidence, our first major update came only a few months after the initial release, with support for dozens of major new platform features like <picture>, ObjectRTC, and asm.js.
Since we started tracking our roadmap in the open in April 2014, we can also use that data to track our progress of moving features through the stages of In Development -> In Preview -> Shipped. Here’s how we did in 2015:
Another popular public metric used to track web standards feature support is HTML5test.com. While we don’t think it necessarily reflects what features should be prioritized next, it can be a useful indicator of overall progress. Here is how Edge arrived on the HTML5test.com charts in 2015:
Chart showing HTML5Test.com scores for various browsers over time. HTML5Test measures declared support for web standards, standards proposals, and experimental APIs.
A similar third-party benchmark measuring support of ES6 features shows rapid improvement from IE11 to Microsoft Edge, which now has the highest number of ES6 features implemented of any stable browser:
EdgeHTML 13 has the most complete implementation of ES6 in any stable browser according to the Kangax ECMAScript 6 compatibility table.
We also made great progress on the priority of improving security with powerful new features like module code integrity and app container sandboxing protect the user from potential threats both on the web and in unwanted or potentially malicious software.
Although this post is focused on web developer-facing progress, we’d be remiss to not mention that we also delivered a new user interface for Microsoft Edge, built from the ground up for the Universal App Platform in Windows 10. This fresh start gave us the opportunity to make major innovations in performance, security, and user experience, including innovative end-user features like Web Notes, Cortana, and Continuum.
Building Microsoft Edge in the open
Another theme we emphasized in 2014 was the desire to bring more openness to the EdgeHTML development process, which manifested with initiatives like Platform Status and UserVoice. In 2015, we’ve made great progress opening up even more.
Communicating what we’re up to
We published over 70 blog posts here (and previously on the IE Blog) throughout 2015, covering everything from a guide to responsive images to an overview of the present and future of Web Components. We also introduced our new Microsoft Edge Dev site in May, including an all-new changelog (updated every Insider build), and a brand new “roadmap priority” measure on our Platform Status page.
Participating in a 2-way conversation with web developers
We hosted the Microsoft Edge Developer Workshop preview event, followed by our first annual Microsoft Edge Web Summit, which will be returning in 2016. Developers from around the world and from over 100 organizations joined us, along with thousands of livestream viewers, to hear the latest EdgeHTML plans directly from the engineering team and provide feedback directly to us. Our team also attended and spoke at dozens of web developer conferences around the world throughout 2015. For those that couldn’t make these events, we took feedback and questions via @MSEdgeDev which more than doubled its followers in 2015, and ran our busiest-ever tweet chats regularly.
Web Standards
We’re more involved than ever in web standards bodies, including spearheading the new Web Incubator Community Group, and lending our very own Adrian Bateman and Brian Terlson as chair of the new Web Platform Working Group at W3C and the new editor of the ECMAScript specification at TC39 (the standards body responsible for the evolution of JavaScript), respectively.
Open Source
We’ve dramatically expanded our open-source initiatives in 2015, including making all our Test Drive demos open-source on GitHub, new open-source tools like JS and developer documentation, and last but not least open-sourcing Chakra, our JavaScript engine. We’re grateful for the opportunity to learn from and give back to the open-source community.
What’s next
We are proud of what we delivered against our priorities in 2015: a new evergreen rendering engine, over 50 new or expanded platform features in stable releases, and a brand new browser—all while providing a new level of visibility into the team’s activities. Though the progress is very encouraging, we know there is plenty more to do. We have been listening to your feedback, meeting with customers and poring over data and telemetry to form an updated set of priorities for 2016. Check back soon for a follow up post with more details on what we have planned for the year ahead!
― Charles Morris, Principal Program Manager Lead, Microsoft Edge
Updated February 11, 2016 1:50 pm
I don’t know if you honestly believe what you are writing. The end-user story of Edge is totally sad. It crashes and freezes far more than IE11 when you have 10+ tabs, it has far worse UI on touch devices, it lacks features like taskbar tab preview (multiple tabs that you can close and select not just the current tab) and tracking protection lists. Let alone that your new features are less useful than old ones like accelerators and web slices (I know they weren’t popular but still better than the notes thing), no built in RSS reader, no way to start in private browsing from the taskbar, my icon on the desktop just went white, switching tabs while a heavy page is loading doesn’t work except for the first one you click… Please fix the end user story.
One major step backwards in communicating last year was closing the end user features focused uservoice site in favour of the horrible Windows Feedback app, which is a mess and lacks most useful features of uservoice. We need to be able to comment and discuss the ideas and see responses from the team beyond the generic ‘We got this feedback’ message, as well as the ability to track the ideas you voted. The feedback app also has no ability to have a separate title and description, which makes more complicated ideas difficult to read as everything is shown in one big font. Uservoice also has a better voting system to help see which ideas are really important to the users from their limited number of votes. Oh an for suggestions about a browser, having a website seems much better than having to use another app!
Unless Windows Feedback is going to get some major improvements soon I really hope you bring back the uservoice.
The number one reason Edge is not my primary browser is missing RSS-support. Manually having to visit 20-30 sites manually til spot possible updates give no meaning in 2016…
Thanks for that analysis.
Hopefully you’ll soon be past the suffocating impact of matching the imposed standards and enable those that want to break free and take charge of their own environments. I’m particularly interested in programming the browser to do what I want. I’d like API’s that I can latch on to from my own code, not sandboxed, not limited to languages that somebody else chooses. Ideally those API’s will let me program against what’s going on in the browser, requests and responses at least.
In my case I’d want to do this with .NET code and PowerShell, to start with.
Looking at the graph I guess you might break through the “be like the others” barrier by July 2016, then (?) offer us API’s. If so I look forward to seeing what programmability you offer.
1. Regardless standards support, the reality is that many websites, even common ones in use by many, are “broken” under the latest versions of Edge.
2. No Flash on WP under Edge. Many sites simply don’t work without Flash. If the underlying Windows platform across desktop to phone is really so “universal”, then why can’t I get Flash on Wp10, but can on win10?
Even Androids can run Flash.
3. Numerous missing features, even a simply forward button on Edge wp10.
4. Just license/port Firefox already. Has the features, power, and addons I need to browse the web safely. EDGE doesn’t.
eg. Adblock plus, with prefbar, allows me to set a different user agent than it actually is, turn off javascript, cookies, referral, so I can browse even the most toxic sites without worry of infection or endless popup loops.
EDGE? Can’t even block toxic ads or popups, can’t turn off malware loving javascript.
5. Slower to use.
eg doesn’t have mouse gestures pf firefox/opera, so takes far longer to navi/close/open sites and tabs.
Fewer features and no addons does not lead to a better user experience at all.
Nice article. Unfortunately implementing standard APIs and implementing them correctly are two different things:
When we first tested Edge with our graph drawing library we were excited. The first publicly available version showed some great improvements over Internet Explorer. Of course there were a lot of bugs and crashes, but performance was looking good and we reported feedback early on in the process. Microsofts “new openness” was really promising and we were hoping that with many months to the final GA release they will probably fix the last few show stoppers and we will end up with a browser that we can recommend to our customers and that can really compete or even beat other existing implementations.
The first release came and the bugs were still there – those bugs are so severe that we need to tell our customers to please not use Edge, because there are showstoppers that cannot be worked around. The Edge team *did* work on Edge – after the installation of some unrelated KB article updates some of the behaviors “improved” or at least changed (without the version of Edge or the HTML changing reflecting that change) and with the Threshold update another set of changes came and now the bugs are … different. The ones we reported are still there, some behave differently, some are regressions to the previous release, and some are still just sitting there with the connect team “looking at them” for months and months. Today we still need to tell our customers to switch to a working browser (yes, IE11 is one option, however others are even better).
Unless they really start working on the most critical bugs that have been reported many months ago, I don’t see Edge will ever become an option that we can recommend. The same probably holds true for other vendors that are offering sophisticated Javascript components that depend on SVG – the standard that you claim to support, but which is actually far better supported in IE11 than it is in Edge:
https://connect.microsoft.com/IE/Feedback/Details/1567173
https://connect.microsoft.com/IE/Feedback/Details/2023492
https://connect.microsoft.com/IE/Feedback/Details/1571965
Thanks for reading! I hope that you can help making Edge a viable alternative to other browsers, which it surely isn’t until SVG is properly supported and text in SVG is actually rendered flawlessly.
Two critical things wrong with Edge.
First, it randomly truncates paragraphs. I’ve reported this error several times, but still (after many fixes and being on Windows insider updates) seeing no fix. When the truncation appears it’s purely a rendering issue as examining the source shows the text is there. A refresh usually removes the issue. But sometimes, it truncation would leave a person unaware and perhaps assume the website was defective when the bug is squarely in Edge’s corner.
Second, table performance. When displaying large quantities of data (reports) in tables, Edge’s performance is about the same as IE — very poor. I have no choice but to recommend clients use Chrome for viewing online reports. Again, this is largely a render speed issue.
You’re doing great, but don’t let the basics get away from you.
I was going to write a decent length response, but really it boils down to this is meaningless if IE11 is left to stagnate, as there’s things polyfills can’t replace. Despite MS’s admirable effort to deprecate all the old operating system versions, it’ll still be another 5 years before even most users are onto windows 10+, if ever.