The Front End Is Expanding (Fluent 2015: 2 of 5)

Pin on PinterestShare on LinkedInShare on Google+Tweet about this on TwitterShare on FacebookEmail this to someoneShare on StumbleUpon


This is the second post in a five-post series about O’Reilly’s Fluent Conference.

What used to be limited to HTML and CSS has grown into an entire ecosystem of libraries, frameworks, and technologies which enable client-side functionality unavailable just a few years ago. Frameworks, web components, web sockets, platforms, and JavaScript tools are fueling big steps forward on the web platform.

Of these, one of the most exciting and nascent technologies is Web Components. Matt Parke, our Senior Front End Developer (@matt_parke), brings us the lowdown of Web Components and the major takeaways from Fluent:

Web Components, Ready or Not?

There are four separate technologies encapsulated widgets for the web are built from, and these technologies are collectively called Web Components. Browser support for Web Components is continuing to get better, but they still haven’t quite reached a widespread adoption.

So, when should we use Web Components? Considering cross-browser support is still in the works, if you’re writing an internal app that only needs to run on Chrome, for example, I’d say go for it! At the very least, be sure to keep an eye on how Web Components progress in the near future.

Let’s break down the four technologies of Web Components: Custom Elements, HTML Templates, the Shadow DOM, and HTML Imports. In his talk, Web Components, What’s the Catch?, TJ VanToll of Telerik and jQuery discussed which of these technologies are ready for production and which still need work. He went through use cases for each (along with some workarounds), but ultimately warned that only Custom Elements are ready for production, and only with a polyfill.

Custom Elements are custom HTML tags with their own behavior and styling. The primary benefits of custom elements are the implementation of the HTML Element interface and lifecycle callbacks. Lifecycle callbacks give controls to the element’s lifecycle (for example, when it gets added or removed from the DOM). A custom element could, say, be a specific button implementation tagged <my-button></my-button>.

“While HTML Templates do have relatively wide support, they’re still far from game-changing.”

HTML Templates define client-side templates with a <template> tag that won’t render on page load. The <template> tag is comparable to using a <script> tag with an unrecognized type, like <script type=“text/x-handlebars-template”>, for example. While HTML Templates do have relatively wide support, they’re still far from game-changing—It’s easy to write universally-runnable code without them to the same effect. For that reason, TJ recommends holding out for universal adoption before using HTML Templates.

The Shadow DOM is an encapsulation of JS, CSS, and HTML elements through a shadow root which keeps the root element and child elements separate from the rest of the DOM. The shadow DOM can work on existing elements, elements created via script, and custom elements. TJ notes theres a lot of value in the Shadow DOM and that it has good support in Chrome, so it may be a good candidate for internal tools and widgets.

HTML Imports are intended to be the packaging mechanism for the other Web Components technologies. An import is defined through the rel attribute on a <link> tag (for example, <link rel=“import” href=“component.html”>). Because the polyfill for HTML Imports is quite large, TJ recommends holding out for wider support.

Check out for links to specifications, browser support, polyfills, and libraries built using Web Components.