We write code not only for computers to understand and execute, but for other humans. This is a mindset that hasn’t resonated with popular sites such as Ebay, Facebook, Google.
This is partially the fault of developers who aren’t using semantic elements. But fault can also be attributed to HTML itself, which hasn’t kept up with the demand for the ability to build complex web applications.
One example of developers misusing HTML is Gmail which has approximately 47 layers of divs.
But unfortunately this is how developers have been using HTML in their web applications. Although the applications may look good from the user’s perspective, the code is completely illegible and not well written from a modern development perspective.
Developers need to place more emphasis on writing cleaner, more semantic markup for several reasons: better performance, increased accessibility, and easier maintainability.
Let’s take a look at a revamped version of Gmail’s HTML code.
Native Web Components provide a lot benefits:
- Declaration: You can easily declare components on your page that are ready to go
- Composability: You can compose applications using smaller chunks of code, with the Shadow DOM
- Reusability: You can import, use and reuse elements in applications
- Maintainability: Compartmentalized, reusable code is the best way to maintain code readability; it reduces overall application size, and simplifies debugging
- Extensibility: Browser elements or custom web components can be extended with the custom elements API
- Scoping: Shadow DOM provides DOM and CSS scoping where styles don’t leak out and component DOM is all local. You define the element api inside your component and it doesn’t leak into the global scope
- Interoperability: Native web components are interoperable at the browsers lowest level which is DOM
- Productivity: Using already built components and iterating on top of them lets us develop faster and more productive
- Accessibility: By using and extending existing browser elements, the default browser accessibility comes with it
Having your front-end application code split up into component libraries or even design systems can ensure brand consistency through the company. It also provides an additional benefit of the ability to be used by all teams, regardless of tech stack.
This is true for both large companies as well as as companies who grow quickly. Web components are also extremely useful for teams who are working on many different projects.
The advantage of DRY (Don’t Repeat Yourself) in programming is crucial, especially when writing applications for the web. Web components can be used to ensure a consistent look and feel without having to recreate everything from scratch again and again when starting a new project.
If you are a development manager or executive, native web components save you money. Developers will have the ability to focus solely on making native reusable components, similar to legos, and use these blocks in other applications across teams. Your teams will be able to build and deploy applications much more quickly. This leads to less time devoted to developing new features.
From a developer’s perspective, native web components help to manage the project more efficiently. The code will be more consumable. Code can be shared between teams more easily. And as a by-product, code quality will be improved, as developers can re-use existing components. Finally, applications that are using native web components reap the benefits,: when you add a fix or add a new feature, these changes get propagated down to each instance.
Web components is a standard that was added by the “World Wide Web Consortium” or W3C. The W3C sets or defines the standard of features that browsers can implement.
Web components enable developers to write applications in a more modular way by breaking the applications down into smaller logical chunks with reusable functionality.
A couple of years ago, all browser vendors got together and agreed on a new set of web standards for defining web components.
Core Elements of Web Components
There are four core elements of web components. All browser vendors have agreed to comply on at least three out of four of these elements listed below.
1. Custom Elements
The Custom Element API lets you create custom declarative elements, or extended elements, that the browser comes with out-of-the-box.
The process of creating a new element is as follows:
- Creating a new element class that extends from one of the existing HTMLElement classes
- Associate the new element with an HTML template
- Register this element with a new name
By creating custom components, the browser will recognize the new element and will render it accordingly.
2. HTML Templates
With HTML templates it is possible to group of client-side content which is not rendered at load time. HTML Templates are rendered at runtime by JavaScript.
The elements <template> and <slot> allow you to create reusable markup for custom elements.
<template id="todo-item">
<li>
...
</li>
</template>3. Shadow DOM
With Shadow DOM we can create scoped sub-trees of within the DOM that is completely hidden from the outside. This provides several benefits among which is encapsulation of the styling of the DOM sub-tree.
Shadow DOM ensures that web components are interoperable and can run in any environment. Additionally, shadow DOM allows us hide presentational elements from end users; you can effectively create a private and a public API. There is no requirement to use shadow DOM and custom elements together, as each specification was designed to work as a stand-alone.
const shadowRoot = this.attachShadow({mode: 'open'})4. HTML Imports
HTML Imports is a proposal for including web components as HTML documents within another HTML document. The HTML Imports specification is the most contended element of the Web Components specifications, however it is only supported by Chrome and Opera.
<link rel="import" href="my-todos.html">Browser support
An important consideration when using the Web Components spec today is browser support. All modern browsers have been moving toward implementing Custom Elements v1.
Using Custom Elements v1 you can rely on a polyfill which gives you support for most of the features in all modern browsers (IE 10+). I’ve been using a client-side loader (webcomponents-loader.js), which dynamically loads the minimum polyfill bundle, using feature detection.
There is also a stand-alone working lightweight version of the W3C Custom Elements specification which is already used in production by the Google AMP project. The polyfill claims to have experimental support down to IE8, (you can see the full list here). Unfortunately some features, like full style encapsulation, cannot be polyfilled.
If you want to support for Mutation Observers in IE10, there is an additional shim you will need to include.
Having best practices is always a good idea to define your development style within and across teams. Native web components should work everywhere. They are based on web standards and they are the future of the platform. Here are some best practices and guidelines for web components I have found.
Many developers have a hard time getting their heads around what Custom Elements offer as a stand-alone technology. This isn’t made any easier by the fact that the term “Web Components” is often used interchangeably with Custom Elements. In particular, developers often conflate Custom Elements and Shadow DOM, despite the two being totally separate.
Without a doubt, the Web Components specification is going to play a large role in the evolution of front-end web applications in the future. Certainly, native web components won’t replace the component engines provided by JavaScript frameworks, but there is a huge opportunity for these two paradigms to work together.
We are moving towards a more agnostic kind of solution where we can write these components and use them throughout different kind of solutions and with various JavaScript frameworks.
Native web components with custom elements are such a flexible primitive, that once you start to see all of the possibilities, the opportunities are endless.
We can consider web components as a tool to extend HTML, not to replace it.
I’m excited to see what the next few years will hold as more teams begin rolling out their own element suites and we move to an era of high quality, interoperable, UI components.
Book recommendations
References
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
