Learn about the Web Components Javascript standard, what its 4 specifications are and how they allow us to extend HTML to create reusable components. Why it is a revolution in frontend development.
In this article we are going to make a theoretical introduction to what Web Components are, a revolution in the world of web development that is already a reality, to the extent that all browsers currently support the standard.
We will see it in detail in this article, but Web Components is a Javascript standard, so it is not necessary to use libraries to create our own components. Even so, there are libraries that still allow you to add functionality on top of the standard, with weights close to 5KB of code. They are an excellent option to develop reusable components and they are giving a lot of talk lately.
Other libraries such as Angular or React also allow you to develop components but they are not based on the Web Components standard. If you know them, you can get an idea of what components are and how they allow you to organize and reuse your code. Although to be exact the standard is much more important than a particular technology, whose life depends on the development team and the time it manages to remain “in fashion”.
We are going to start by explaining the objective that Web Components come to cover and then we will deal with the 4 specifications that we can find in this technology. In addition, in this article we are going to clarify some interesting points about technology and its evolution, throughout its various versions and browser support.
Why Web Components
Web Components offer us a standard that is focused on the creation of all kinds of usable components on a web page, to create user interfaces and elements that allow us to present information (that is, they are technologies that are developed on the client side). ). The developers themselves will be the ones who can, based on the tools that Web Components includes, create these new elements and publish them so that other people can also use them.
In summary, this new standard comes to facilitate the creation of new elements that enrich the web. But also, it is designed so that they can be reused in a simple way and also extended, so that we are able to create some components based on others.
As we will see, when designing the standards for Web Components, efforts have also been made to work with the components in isolation, allowing the new pieces to be used in the context of a website without affecting existing ones. At the same time, it has been tried that the process of loading a new component in a page can be done atomically (a single block) instead of what is usually done with many current libraries and plugins that require writing the styles on the one hand and the javascript for another.
Note: The W3C is in charge of maintaining the standards, but the truth is that their procedures to allow the evolution of the web are a bit heavy. We mean that developers usually detect needs long before the W3C makes a standard to cover them. In fact, it can take years from when something begins to be used in the world of the web until the standard is presented. In short, the world of the web is moving much faster than the definition of standards.
Classic examples of Web Components
The most typical example that we will see out there is a Google map. Today, if we don’t use web components, when we want to display a map on a web page, we have to create code in three blocks.
- An HTML with the element where the map will be rendered
- A CSS to define some style on the map, for example its dimensions
- Most importantly, a Javascript so you can generate the map, indicating the coordinates you want to display (to center the initial view) and many other configuration details that your map needs.
Another example would be a calendar, which you need again basically three parts:
- HTML to create the element where the calendar will be displayed
- CSS to indicate the dimensions of that calendar, colors, etc.
- Javascript to say which month, day or year to display.
They are three different languages, which are specified in separate code blocks and usually in separate files. Without Web Components, to have all the blocks grouped together and have a unique code to embed an element, the IFRAME tag was generally used, which allows HTML, CSS and Javascript to be loaded and its scope reduced to a small space on the page. This technique is still used, but in the future it will be replaced thanks to the benefits of Web Components.
From now on we will be able to express a Google map with a proprietary tag, which does not belong to the HTML standard, which simplifies the task and delimits it to a small independent block.
To include a calendar that indicates the days that we are free or busy, we can use a proprietary label in which we indicate the characteristics of that calendar.
These are two examples taken directly from real Web Components, created by the Google team. They are intended to reflect:
- It’s like we’re inventing new labels. That is one of the capabilities of the Web Components, but not the only one.
- The proprietary tags we are making up are “google-map” and “google-calendar-busy-now”
- We don’t have HTML on the one hand, CSS and Javascript on the other. It’s just the new tag and it’s already capable of launching the behavior.
- Obviously, somewhere there will be a Javascript that will take care of processing that label, but it will be generic for any type of map and reusable. What should also be seen is that in the HTML you are placing information that would previously be in the Javascript. For example, in the case of the google map, the attributes latitude=”12.678″ longitude=”-67.211″ used to be data that was written in Javascript. Now they are declared in the HTML. The Javascript is therefore generic and we will not have to program it ourselves, but it will be given to us by Google or by the creator of the web component on duty.
Versions of the Web Components V0 and V1 standard
Updated September 2018: Although this is a relatively new technology, there have already been several changes to the standard that are important to explain. It is about the versions of Web Components V0 and V1 and their implications.
This standard has been promoted mainly by Google, the company where they began the design of Web Components, according to how they themselves considered it should be. However, for the creation of open standards, such as HTML, CSS, etc. not only one company thinks, but a group of companies and professionals well positioned in the sector. That is why, while Web Components went from being a private project to an open standard, modifications were introduced.
The initial version of Web Components, created almost exclusively by Google, was called “Web Components V0”. In their own words, it was an experiment to see how things would turn out and where the goals of bringing the world of components to the web would take them.
The version of the standard that we know today is called “, when Google “Web Components V1”. This version can now be definitively considered an open standard, given that a whole group of companies and professionals from different areas of knowledge have participated in the process of its creation. computing.
Web Components V1 brought with it a main novelty compared to version V0, the replacement of HTML Imports by ES6 Module Imports. We will talk about it in more detail soon.
Specifications in Web Components
Now that we have understood something about what web components are, the concept itself, we are going to be a bit more formal and describe the different specifications that we can find in Web Components.
Custom Elements:
This specification describes the method that will allow us to create new custom, proprietary tags. We can devise these labels to respond to any need we may have. These are the basic cases that we have seen in the previous points of this article.
HTML Templates:
It incorporates a templating system in the browser. Templates can contain both HTML and CSS that will not initially display on the page. The objective is that with Javascript the code that is inside the template is accessed, it is manipulated if necessary and later it is included, as many times as necessary, in another place on the page.
HTML Imports:
Allows you to import a piece of code that you can use somewhere on your page. That code may have HTML, CSS and Javascript. The HTML won’t be displayed directly on the page, but you could access it with Javascript and inject it somewhere. But although it is specifically called “HTML Imports”, it really serves to load both HTML and CSS as well as Javascript in a unique way. You can also have an “HTML Template” inside, with the advantages that they provide. Through Javascript code we will also be able to register personalized components “Custom Elements” or carry out other types of actions on the content of the page that are necessary.
Shadow SUN:
This system allows to have a part of the DOM hidden from other blocks of the page. It is commonly said that we are encapsulating part of the DOM so that it does not interfere with other elements on the page.
Basically it helps you to solve a common case that occurs when including a third-party plugin. Sometimes they use classes or identifiers to apply styles that affect other elements on the page, throwing things out of position or altering their appearance. Well, with the Shadow DOM we can make the components have parts that would not be visible from the outside, being able to place styles that only affect the Shadow DOM of a web component and preventing page styles from being able to affect the Shadow DOM.
Note: These 4 specifications, although we have them separately, are intended to work together for the same purpose: to be able to make your own components for the web. We will see them later in detail.
Situation of HTML Imports and its evolution to the definitive ES6 Imports
HTML Imports was the part of Web Components that received the least support from the community during the standardization process. So much so that many browsers have never come to support them.
The problem with HTML Imports was that they covered the same objective as another tool used to request code, ES6 Modules. While HTML Imports were set up to require files…
Facebook Comments
Disqus