Can web components replace the well established frontend frameworks?
The status quo of the web development technologies is, in a sense, scattered in many directions and different frameworks. Each presenting their own set of advantages and disadvantages.
First, we have the well established frameworks, React, Angular, Vuejs, and the like. Each have their own methodologies, rendering techniques, lifecycle processes, etc. They’re definitely powerful and reliable, but all that power comes at a cost.
First of all, think of the size. While the React core alone weights almost 7 kB minified, you’d hardly build a complete React application with just the core. You’ll probably need the react-dom package to manipulate the website’s content, that’s another 121 kB minified. All this without counting on the other modules needed for an app to make the bare minimum. You’d probably need to fetch information from a server, or use a router to simulate the navigation in a SPA, among other functionality that you might include in an app.
Second, the size of the framework comes with the cost of time. Since the app is gonna be running on the client’s side, long loading times can have an impact in the user experience. Also, thinking on all the functionality implemented in a framework, it may suppose an extra workload for the client.
Here comes a new challenger…
Web components are a fairly new technology that extends over technology we have always had, but until recently came to exploit its full potential: the native DOM.
As stated by Kevin Schaaf in the Polymer summit 2015, Polymer (a web component based library) was built all around “leveraging the DOM and using it as its framework”. But what in the heck does this mean?
The fact is the DOM has all kind of framework-type concepts built into it. And rather than invent a whole concept on top of the platform, why not use all these framework-type parts of the DOM. What are those parts?
- DOM comes with its own component model. A good example of this would be the video tag:
<video src="polycast.mp4" controls>This tag alone hides a lot of complexity behind a really simple user interface. This is the component model concept (a whole application sitting behind one tag). - Data flow. We have attributes and properties and the elements can tell us when to send data through events.
- Declarative syntax. The same HTML allows to encode a whole tree of pre-configured elements in a human readable format, send it through a high performance parser and add functionality to it. All of this without us having to write a single line of script.
All this functionality is just sitting there in the browser. And while these functionality is very powerful, until recently it wasn’t extensible. Which means that we couldn't take advantage of all this functionality. This was until they invented custom elements.
Which comes with its own set of advantages.
For example, there’s fewer concepts to learn. There’s not a single front end developer that doesn’t know how to write HTML syntax (setting tags, properties and attributes and events). So these concepts are already familiar for developers, which becomes an advantage over having to learn a whole framework like React or Angular and all of its concepts from scratch.
Other advantage is its interoperability and their re usability. The web components we define with native HTML and JS are naturally gonna be compatible with a lot of other technologies and projects.
No lock-in with the “frameworky” way of making components, since it is an interoperable standard and not locked into a single technology tree.
And so, technologies like Polymer or Lit Element add elegance and simplicity to the building of custom elements, all while avoiding the repetitiveness of having to build custom elements from scratch, and having a lot of boiler plate code to build simple things.
That’s about building custom elements for their own sake, but what about building entire applications? Well, they where created with the single idea: ‘what if custom elements where all that we needed for building applications?’
The app building process using web components can be resumed using three concepts:
- Thinking locally: After all, when thinking about building an app, you wouldn't dare to even think about holding the whole complexity of the app in your head. Instead, you wanna focus on small pieces at a time. Each one focuses on one task, and do that task really well, because of a well defined interface.
- Leveraging composition: We already talk about focusing on one single element at a time while leaving others details aside. But now, inside of a single element, we can actually leverage other elements to get the job of the element done. Using composition of even smaller elements, even ones not made by us, to our advantage.
- Finally, using the mediator pattern: Define an object that encapsulates how a set of other objects interact, so objects no longer communicate directly with each other, but through the mediator. So, for example an element with a defined set of children will need to receive communication from them and to decide what to do next. It may want to pass information from one children to the other, or make some computations based on the children’s data. Another thing a parent element may want to do is expose an interface so it can interact with the outside world. In short, hiding implementation details and providing an API for it.
So these are the 1, 2, 3 steps of building an component based application. If followed in an iterative manner, we can have an app that is modular in self contained and reusable components that interact with each other. This makes every application easy to conceptualize, build and maintain. And since its based on native technology, it’s also lightweight and fast.
