Once again about web components ...

Each time, when a group of Web Components standards is mentioned in any article or in the comments, almost the same thing happens: people who often have little idea what they are talking about begin to share “expert” opinions. Each time the discussion rolls over to the same well-rolled out scenario, the name of which rhymes with the word “rook”. And I would very much like a positive, constructive and a transition to questions of practical application. In this article, I will try to immediately answer the vast majority of typical questions and refute the maximum of common misconceptions. Subsequently, in a difficult situation, it will be possible to fight off one link. So let's go.

The basics

Web components are a set of modern specifications consisting of the following basic elements:

Custom Elements is the native ability to create your own HTML tags, with a given behavior, appearance, and your own internal markup.
')
Shadow DOM - separation of the internal structure of the component with encapsulation of internal styles and the rest of the document body.

Template is a special tag that allows you to store chunks of markup, apply them and reuse them if necessary.

HTML Imports - the ability to import HTML blocks stored in other HTML files

A dish from all of the above can be seasoned with native CSS variables, native ES modules and HTTP / 2 server push. There are also slots, custom attributes, custom events and other details. About them a little later, when we proceed to practice.

Yes, these web components of yours are almost not supported anywhere.

Dry numbers are engineer’s best friends. Let's look at “almost nowhere” from this angle:

Custom Elements - 78.71%
Shadow DOM - 79.12%
Template - 89.61%
HTML Imports - 69.16%

As we can see, the above technologies work in browsers for the vast majority of users. The picture is spoiled a bit by HTML imports, but we don’t have to use the full set (I prefer the native ES modules to break everything up into convenient blocks), even separately you can find a lot of “tasty” in this list.

I highly recommend not to trust me blindly, but to follow the links provided. There, for example, you can see the current status for these specifications and the fact that Custom Elements and Shadow DOM have received full support in Firefox since version 63 . When the bulk of fox users upgrade to this version, and this moment is not far off, the overall numbers will become even more attractive. Also, you might have noticed the “incomplete support” of Custom Elements and Shadow DOM in Safari. Apple browser will not allow you to inherit your component from the built-in native browser element, such as buttons, selects and the like. Even in Safari, there are small nuances in CSS selectors when using the Shadow DOM. In practice, it is quite possible to live with it and not to grieve. Apparently, according to tradition, the outsider among modern browsers is Microsoft Edge. The developers claim that support is being implemented. We wait.

Well, what to do with the rest ~ 20% of users?

To support these guys you can use polifila . Yes, it will work a bit slower with polyfiles, but this is not noticeable to the naked eye. But for everyone else - will be faster.

We tried to do a project on Polymer five years ago. Everything was terribly slow.

In those "distant" times, the draft standard (v0) raged, the support of which was implemented only in Chrome. Since then, much has changed: a new version of the standard has been adopted - v1, native support has been implemented in various browsers, polyfiles have been rewritten, good practices have gone the way of fixing. Polymer itself turned from a technological preview into a completely working solution, which is a pleasure to deal with.

Some polymers ... What is it at all?

Polymer is a library for creating web components. It implements support for all the “sugar” to which we are so used to working with popular front-end frameworks: dynamic data bindings (bindings), repeaters for working with arrays, etc. At this point, the 3rd stable version has been released this library. Development is conducted with the active participation of Chrome developers. The ecosystem is supported by Google. The total length of the beards of developers is ...

When should I use web components?

If you need a universal shared library of UI components. The case of life: a project in which the main application is written in React, and back office - in Angular. And you want the sameness and every reuse of the code base. And web components feel great in different ecosystems .

If you are close approach "design in the browser . " You can create without constant rebuilding of the application and without unnecessary dependencies. This makes prototyping a very enjoyable experience and allows your application to smoothly evolve from prototype state to production-version state. I love that.

If you like the good old OOP : create a class by inheriting from an HTML element, implement the desired chips and general buns, and then inherit classes for specialized components from it. And now you’ve got your own microframe. Beauty!

If you hate BEM : Shadow DOM isolates component styles. There is no need for multi-story monstrous naming, nor for providing navigation to the declarations in the general CSS pile. Everything is compactly packaged in a component: styles, layout, logic.

If you are developing an application based on Electron. The current version of Chromium in Electron already supports everything you need. Despite the total lag in the versions.

If you want to write your own framework / library. Web components are an excellent compositional basis for such experiments.

If you need a hybrid approach: you implement classic web pages with SPA elements : custom tags can be used with any server templating engine, they can be just part of the overall markup and work out your assignment at the right time. You can keep a delicate balance between what is being rendered on the server and what is working on the client.

If your users use modern browsers. By itself.

If you're developing PWA : mainstream mobile platforms support everything out of the box. For a quick start, there is a pwa-starter-kit .

If you are interested in enhanced application security and detailed dependency auditing for you is prohibitively expensive. Everything is simple: less dependencies - less uncontrollable holes.

If you are an optimizer maniac and enjoy working with the DOM API : web components are part of the DOM API, with all the standard features of ordinary DOM elements.

If you burned about breaking the backward compatibility of library versions : when everything is based on a hardcore standard, it is somehow more reliable.

When you should NOT use web components

When the requirements for your project there is a need to support old and exotic browsers. In this case, you will not envy as a whole. My condolences.

When you develop simple products with a short life cycle and you do not need to develop a single code base.

When you deal mainly with legacy code.

When you and your colleagues use only something fashionable and do not want to know anything else.

Why do I need all this? I have React / Vue / Angular / etc, I have enough ...

Then, that a significant part of what JavaScript does in popular libraries and frameworks, can be shifted to a lower-level browser implementation. For the sake of speed, reducing the exorbitant amount of dependencies, reducing the dependency itself. For the sake of good.