Maybe you think it is revolutionary but if you have worked as a FrontEnd developer in the last 15 years, I am sure you will have tried to make a component in some way.
In the past, when you started a project and, normally, when you had the designs and prototypes, it was common to think about what to reuse in an application with the idea to create independent and reusable pieces of code. We were not thinking about using these pieces outside the project; the goal was to use them easily and flexibly inside the project.
Many times, due to the client requirements (“… what if …”), developers created many combinations of the same piece of code: with title, without title, with photo, without photo, with long entry, without entry, etc. Later, people started to create style guides, component catalogues and then the idea of molecules and atoms became popular… crazy right?
Can you imagine how components would have been created in the past with the technology we have today?
But, what are Web Components? If you read the specification, they are a group of APIs who allow us (this is the most important) to create reusable custom elements, such as HTML tags.
And, because they are based in a specification, the browser’s support is updated frequently.
Web components are based on four main specifications:
- Custom elements: designing and using new types of DOM elements
- Shadow DOM: how to use encapsulated style and mark up in web components
- HTML imports: the inclusion and reuse of HTML documents in other HTML documents
- HTML Template: how to declare fragments of mark ups that go unused at page load, but can be instantiated later at runtime
But, why are they so popular now? (as well as being criticized and defended). Perhaps the rise of AngularJS and the idea of the directives opened up a new world to the developers: The idea of using custom elements in a declarative way. Of course, these elements could be only shared between Angular projects.
So, how could we do the same but between projects of different technologies? People discovered and payed attention to these specifications, which were being adopted by the browsers (albeit very slowly at the beginning).
New libraries and frameworks were born, which shared a common idea: creating components for our projects. Some of these frameworks and libraries have custom ideas on how to implement the components; others follow the specification of Web Components.
The current ecosystem between Angular, React, Vue.js, Polymer, etc. (but they have not been created to be used in the same way) creates some debates about which one is the best, which one is the worst.
Who will win? It is not about winners and losers. The best solution will be the one that fits perfectly to your project.
You cannot avoid that due to the rise of Polymer, the browsers have adopted the specifications quickly. So fast, that the next major version of Polymer, currently a release candidate, will be lighter than the previous version because unnecessary APIs and code have been removed because this ‘stuff’ is now in the browsers. In the future, Polymer should not be necessary.
But the truth is, from now, a custom solution to create components won’t be the most adequate if it does not follow the specifications.
Keep calm and #UseThePlatform