Smashing Podcast Episode 8 With Stephanie Stimac And Aaron Gustafson: What’s New In Microsoft Edge? — Smashing Magazine

A New Engine Under Edge

When Microsoft announced it was rebuilding Edge on Chromium, it marked the end of a long era of proprietary browser engines and the beginning of a new kind of relationship between the browser vendor and the web standards community. In this episode of the Smashing Podcast, Drew McLellan speaks with Aaron Gustafson and Stephanie Stimac of Microsoft about what the shift means for developers, and for the web as a whole.

The End of a Proprietary Era

The move to Chromium means that Microsoft's own rendering engine is no longer part of the browsing landscape. For developers, that removes a significant source of cross-browser quirks that had persisted for years. But, as Gustafson and Stimac point out, the change is more than just an engineering decision; it affects how web standards evolve, and how much of the web's future can be shaped by a single engine's dominance.

Because Edge is now built on the same foundations as Chrome, some developers might assume that "browser support" is a settled issue for the majority of the web. The reality is more nuanced. Edge no longer has to be tested as a separate engine, which is a relief, but Chromium's spread does raise questions about the health of a web where everyone shares one rendering core. The hope, the guests suggest, is that with Microsoft and other contributors participating actively in Chromium, unique bugs and feature gaps will become less frequent — and the risk of a single failure point is offset by the collective investment in a shared platform.

Bringing Developer Voices to the Standards Table

A major part of Microsoft's outreach is The Web We Want, an initiative that gathers feedback directly from developers about the problems they face and the features they request. The goal is to ensure that the conversations which shape browser internals are not happening only among browser engineers, but include the people who build the web every day. By reducing friction between what developers need browsers to do, and what those browsers actually deliver, the project aims to push forward a more responsive web platform.

Getting feedback from developers at scaledoesn't have to involve lengthy spec documents or advisory committees. Through The Web We Want, anyone can submit an idea or pain point. That data then heads to the appropriate browser teams and standards groups, with the aim of surfacing real-world needs that might otherwise go unrepresented. According to the guests, this process has already helped move new capabilities forward, and continues to inform Microsoft's own priorities when it comes to advocating for the web within Chromium and beyond.

The new Edge itself is also designed to help developers gather usable insights more easily. Built-in tooling and a clearer view into the browser's behavior aim to remove some of the guesswork that comes along with developing for a shifting platform.

For anyone working in web development, the takeaway is a reminder that browsers are no longer isolated silos built to different blueprints. The march towards Chromium has brought the technology together, but it has also introduced a new interplay between use and development: with one shared core, the user experience and the developer experience are more tightly bound than ever — and the people who make the web have a direct channel to those who make the browser.

Edge Drops Its Last Ties to Internet Explorer

Microsoft’s new Edge browser, which reached general availability on January 15, 2020, represents a complete break with the company’s browser history. The old Edge, known as EdgeHTML, was a heavily refactored continuation of Internet Explorer’s Trident engine. The team had stripped out proprietary baggage such as ActiveX and legacy browser helper objects, but the underlying lineage remained. The new Edge shares none of that lineage. It is built on the open source Chromium project — the same foundation used by Chrome, Brave, and Opera.

Adopting Chromium means Edge now uses the Blink rendering engine and the V8 JavaScript engine. The change is not cosmetic: “Basically none of the underpinnings of old Edge are there,” says Aaron Gustafson, a web standards advocate at Microsoft. The Chromium project includes the rendering engine, the JavaScript engine, the UI, and even the build process. Microsoft’s work has been to take that base and make it look and behave like Edge — adding Microsoft account synchronization, for example.

The move mirrors what Apple did when it built Safari on KHTML, the engine behind Konqueror. Chromium itself traces back to WebKit, which traces back to KHTML. So new Edge sits on a completely different family tree from its predecessor.

What’s Unique in Edge

In the first stable release, most Edge-exclusive features target consumers and enterprise users rather than developers. Collections, for instance, lets users gather web content into named groups in a side pane and export that data to Word or Excel. On Windows only, IE mode renders legacy Internet Explorer pages inside an Edge tab for enterprise customers who still depend on old technology.

Developer tooling, by contrast, is currently identical to what you’d find in Chrome. That is intentional: since Edge is built on Chromium, it inherits the same DevTools. Microsoft’s own contributions are coming later, including a 3D DOM viewer that the team is iterating on. The company is also investing in accessibility improvements, internationalization, and new tools — and much of that work is being upstreamed into Chromium.

“Anything that is not UI specific to Edge or that involves our sync platform, all of that is being up streamed into Chromium,” Gustafson says. That means fixes Microsoft makes for accessibility or DevTools also improve Chrome, Brave, Opera, and Electron. Microsoft is also collaborating with the Chrome team on progressive web apps, particularly around what PWAs should look like in desktop environments, and with the VS Code team so that browser DevTools and the editor work together. In practice, that could mean clicking a style rule in Edge DevTools opens the corresponding line in your stylesheet inside VS Code.

The Cost of a Shared Engine

Widespread adoption of a single rendering engine raises a familiar concern: does the web lose the healthy competition that comes from multiple independent implementations? Gustafson, who has worked in web standards for years, says the business case for Microsoft made sense, and for front-end developers it is convenient not to cater to several engines. But the loss of another independent engine is real — he felt the same pain when Opera moved to Chromium.

The situation is different from the original browser wars, he argues. Back then, proprietary engines competed through one-upmanship on features, with companies reverse-engineering each other’s JavaScript. Today, browser vendors can collaborate inside open source projects. “We have the ability to actually work together in open source projects and still have the dialogue,” he says, including serious discussions about the impact of different approaches.

He is heartened by Microsoft’s commitment to participating meaningfully in Chromium rather than passively accepting whatever comes downstream. Still, the consolidation raises open questions for standards bodies. If a browser vendor decides not to implement a feature, it can effectively block that feature from becoming a standard — even if developers universally want it. The objection might not be philosophical; a vendor could simply lack the staff to build the feature.

What If the Web Were a Monoculture

If Mozilla were to abandon Gecko and adopt Chromium, that would be a problem, says Stephanie Stimac, program manager on the Edge Developer Experiences Team. “Then we’re in this browser monoculture,” she says. She values Firefox’s independent tooling and its role fighting for the open web. “It’s kind of nice to have sort of an independent browser out there still fighting for the open web.”

Gustafson wonders whether a standards body could ever control the rendering and JavaScript engines, with all browser makers contributing to their ongoing development. Would that be good or bad? He doesn’t have an answer, but notes that browsers — and especially rendering engines — are enormously expensive to build. Because so many companies have shifted focus to services, few are likely to fund new engines from scratch. “I don’t know that there’s going to be a whole lot of interest in building out a new rendering engine and a new JavaScript engine to challenge the ones that are there,” he says.

A future where more stakeholders actively participate in one engine’s development — including having the difficult conversations about where the platform is going — could be a good thing, or not. It remains a thought experiment.

New Edge has been in public testing since roughly May 2019, when Canary builds were first shared at Microsoft’s Build conference. The stable release followed in January 2020.

Gathering Developer Feedback

Both Stimac and Gustafson are primary organizers of The Web We Want, a cross-browser initiative that gathers feedback from developers about problems they face on the web. The idea is that browser teams tend to focus on shiny new features, while developers struggle with fundamentals that should have been solved years ago. The initiative has two components: an online form at webwewant.fyi and live events hosted at conferences and meetups.

At these events, developers present problems to a panel of industry experts. The panel discusses whether each problem is worth browser vendors pursuing, and both the judges and the audience vote on the most pressing one. The results are then taken back to the various browser teams. Participants have come from Mozilla, Google, and Igalia — the company that did much of the CSS Grid implementation work and is currently implementing things like container queries in WebKit.

Several recurring themes have surfaced. HTML form controls keep coming up; developers want to be able to style and extend them. Accessibility submissions have been steady, including proposals for surfacing accessibility errors directly in the browser console — for example, flagging images missing alt text, tiny fonts, or low contrast where developers are most likely to notice them. Another idea involved a source order viewer in DevTools that shows how content flows through the DOM. One particularly well-received proposal suggested browsers automatically fix certain accessibility issues, though it raised a question: if the browser fixes problems for you, will developers stop writing correct code in the first place?

The winners from each event last year were grouped into categories and are now being reviewed. On the Edge side, the team is using Twitter surveys to validate that these problem spaces are worth pursuing. Progress is slow, but the hope is that work will begin this year.

The Web We Want has events scheduled at Open Source Festival in Lagos, Nigeria (run independently), at SF HTML5 in San Francisco in late March, and at SmashingConf San Francisco in April. Conference and meetup organizers can also request a session for their own events.

The Net Result

The new Edge is a fundamentally different browser — not just from Internet Explorer, but from the Edge of two years ago. The developer experience is now shared with Chrome, and Microsoft’s fixes flow back into the open source project that powers several browsers. That convergence solves real compatibility pain, even as it leaves the future of independent engines uncertain.

For those with ideas about how to improve the web, the Web We Want submission process is intentionally low-friction. Gustafson says the team works with authors to refine rough ideas, points out when a suggested feature already exists, and passes suggestions along to the right people. “We want to know what is it that you’re doing, where you’re running into problems,” he says. Submissions can be made at webwewant.fyi.