September 8, 2018 at 14:31Once again about web components ...
Each time, when a group of Web Components standards is mentioned in an article or in comments, almost the same thing happens: people who, often, have very little idea of what is at stake, begin to share “expert” opinions. Each time, discussions slip into one and the same scenario, the name of which rhymes with the word "rook". And I would very much like a positive, constructive and transition to questions of practical application. In this article, I will try to answer at once the vast majority of typical questions and refute the maximum of common misconceptions. Subsequently, in a difficult situation, it will be possible to beat off with one link. So let's go.
The basics
Web components is a set of modern specifications, consisting of the following basic elements:
Custom Elements - a native ability to create your own HTML tags, with the specified behavior, appearance and own internal markup.
Shadow DOM - separation of the internal structure of the component with encapsulation of the internal styles and the rest of the body of the document.
Template - a special tag that allows you to store pieces of markup, apply them and reuse them if necessary.
HTML Imports - the ability to import HTML blocks stored in other HTML files
The dish of all of the above can be seasoned with native CSS variables, native ES modules and server push HTTP / 2. There are also slots, custom attributes, custom events and other details. About them a little later, when we move on to practice.
Yes, your web components aren’t supported anywhere.
Dry numbers are the best friends of an engineer. Let's take a 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. HTML imports spoil the picture a bit, but we are not obliged to use the full set (I prefer native ES-modules to break everything into convenient blocks), even individually, you can find a lot of “tasty” ones on 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 DOMgot full support in Firefox starting from version 63 . When the bulk of fox users will upgrade to this version, and this moment is just around the corner, the overall numbers will become even more attractive. Also, you might have noticed the “incomplete support” of Custom Elements and Shadow DOM in Safari. An apple browser will not let you inherit your component from a built-in native browser element, such as a button, select, and the like. Safari also has some nuances in CSS selectors when using the Shadow DOM. In practice, it is quite possible to live with it and not to grieve. Apparently, by tradition, Microsoft Edge is an outsider among modern browsers. The developers claim that support is being implemented. We wait.
Well, what to do with the rest ~ 20% of users?
Polyphiles can be used to support these guys . Yes, it will work a little slower with polyphiles, but this is not noticeable to the naked eye. But for everyone else - it will be faster.
We tried five years ago to do a project on Polymer. Everything was terribly slow.
In those “distant” times, the draft of the standard (v0) was raging, the support of which was implemented only in Chrome. Since then, much has changed: a new version of the standard, v1, has been adopted, native support has been implemented in various browsers, polyfiles have been rewritten, and good practices have gone a long way. Polymer itself has evolved from a technological preview into a completely working solution, which is nice to deal with.
Some polymers ... What is it all about?
Polymer is a library for creating web components. It implements support for all the “sugar” that we are so used to when working with popular front-end frameworks: dynamic data bindings, repeaters for working with arrays, etc. At the moment, the 3rd stable version has already been released this library. Development is carried out with the active participation of Chrome developers. The ecosystem is maintained by Google.
When to use web components?
If you need a universal shared library of UI components. A case in life: a project in which the main application is written in React and the back office in Angular. And I want the sameness and all kinds of reuse of the code base. And web components feel great in different ecosystems .
If you are close to the design in browser approach . You can create without constant rebuilding the application and without unnecessary dependencies. This makes prototyping a very enjoyable task 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 the HTML element, implement the desired chips and buns in it, and then inherit classes from it for specialized components. And so you got your own microframework. Beauty!
If you hate BEM : Shadow DOM isolates component styles. There is no need for multi-story monstrous naming, nor for providing navigation to declarations in a common CSS heap. Everything is compactly packed in a component: styles, layout, logic.
If you are developing applications based on Electron. The current version of Chromium in Electron already supports everything you need. Despite the general lag in the versions.
If you want to write your 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 template engine, they can be just part of the general markup and work out your purpose at the right time. You can maintain a delicate balance of what is rendered on the server and what works on the client.
If your users use modern browsers. By itself.
If you are developing PWA : the main mobile platforms support everything out of the box. For a quick start, there is a pwa-starter-kit .
If you are interested in increased application security and a detailed dependency audit is prohibitively expensive for you. Everything is simple here: fewer dependencies - fewer uncontrolled holes.
If you are a maniac optimizer and like to work 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 the 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 be envied in general. 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 are dealing primarily with a 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, enough for me ...
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 very dependence on dependencies. For the sake of good.