Editor’s note: This is part two of a two-part series on Web Components by Microsoft Edge engineers Travis Leithead and Arron Eicholz. To read more about our viewpoint and background on web components, please see part one, “Bringing componentization to the web: An overview of Web Components.“Yesterday, we shared our thoughts on the promise of Web Components. In this post, we’ll answer a couple of recurring questions we get about the technology, including our implementation roadmap and how we currently think about its priority in regards to other related platform work. We’re excited about the potential of these technologies, and today
we’re excited to announce that we’rebeginning development on the HTML Template element, one of the core Web Components technologies and the #3 UserVoice requestfrom developers.
What does Microsoft think about Web Components?Many people ask us: “What does Microsoft think about Web Components?” Web components have a lot to offer the community. We’re excited about the potential for the technology to dramatically simplify large-scale web development while simultaneously reinforcing good declarative patterns that are already familiar in HTML. In our standards involvement, we also see it as a great way to foster community experimentation and help guide the direction of future standards.
We are happy with the direction that current discussions around specific web components technical issues are trending. The right questions and difficult problems are being raised and discussed by browser vendors and other participants. Wilson Page over at Mozilla has an excellent overview of some of the technical issues that we have discussed recently in meetings with other vendors. A subset of these issues (related to Custom Elements) are scheduled for discussion–and hopefully resolution–at an upcoming meeting later this month. Since initial specs were first drawn-up, it has been a long road for Web Components. It looks like cross-browser consensus is now happening with cross-browser interop to follow.
Why hasn’t Microsoft implemented Web Components yet?The second question we hear most often is: “Why haven’t you implemented Web Components yet?”
Often we need to clarify that Web Components are not a single feature. The “family of Web Components” may be a more apt name–they include many separate technologies working together—and this is the secret to their potential (more on that in yesterday’s post, “Bringing componentization to the web: An overview of Web Components.”) In the family are technologies like Shadow DOM, Custom Elements, Templates, and Imports, but CSS Custom Properties may also be considered part of that family. As we learn about the scope and reach of the CSS Houdini effort, we can see how that might play a relevant part in developing component styling that is independent of a particular custom-element tag name. There is a lot to consider, prioritize, and resolve as the specs are not finalized and the current implementation in Google Chrome is already incompatible with recent changes to the specs. As mentioned above, we continue to actively participate in the standardization process collaboratively with implementers Google, Apple, and Mozilla as well as several invested JavaScript libraries.
The second-half of the answer is related to where we are concentrating our engineering resources. As part of the EdgeHTML engine split (and even a little before that) we knew it was time for our 20 year-old DOM implementation to get an upgrade. Building core features like Shadow DOM on top of IE’s legacy internal data structures would have been slow, buggy, and cost at least twice as much to implement. Our engineering investments in Web Components really started with our prodigious effort to upgrade the DOM. Not only will the DOM upgrade enable better internal extensibility for future web components technologies, but it will provide a baseline for next generation performance in the DOM of Microsoft Edge.
We’re now very far along in overhauling our DOM architecture. We expect this work to continue past the launch of Microsoft Edge this month. We’ll share more details about this effort at that time and provide an update on our Web Components roadmap as well.
When can we expect to see Web Components in Microsoft Edge?As we draw closer to the finish line for an upgraded DOM, we are looking at what we can enable now to help fill the gap for web developers. Given feedback from our customers and partners, we know the hardest part of Web Components to polyfill in unsupported browsers is the behavior of the Template element. The Template element allows content cloning and replacement to be done efficiently while keeping the template content out of the DOM tree itself.
We are happy to announce that we are starting development to add HTML Template element support to Microsoft Edge today! This is just the beginning of our Web Components journey.
Following template support, and after completing the DOM rewrite, the next goal is to implement Shadow DOM, the second-hardest feature to polyfill, followed by Custom Elements. We plan to evaluate the rest of the first generation of Web Component specs after that. Naturally, as the specs continue to evolve and additional web component-related technologies rise in importance we may shuffle priorities along the way. As always, keep an eye on our status page for the latest.
We appreciate your continued support and interest in Web Components. Keep the feedback coming @MSEdgeDev. Thanks!
– Travis Leithead, Program Manager, Microsoft Edge
– Arron Eicholz, Program Manager, Microsoft Edge
Updated July 15, 2015 10:09 am
