The future of interface prototyping: Web Components

Over the years, websites and web applications have become increasingly complex and feature-rich. Together with this trend, there has been a shift from a particular approach to development (i.e. where each element is developed specifically and independently) to a component approach, where instead each visual element is made up of smaller, more specific ones, with minimal and well-defined tasks, and linked together by functional logic.

The web itself natively provides components, but apart from a few rare introductions over the years, these are always the same elements that have been seen since the 1990s: input fields, buttons, links, checkboxes, headers… If we need some more sophisticated entities (and we probably do), we need to develop them on our own.

One of the first steps in creating the design of an application today, therefore, is to define the “components” that will make it up, together with their roles and functions, in order to outline a homogeneous and satisfactory look & feel.

This is nothing new: it is an approach that has been known and implemented for years and never really questioned. So what need do we have to change? What pain points have emerged in recent years?

The first that comes to mind is the reusability of our components. We can create our own “libraries” of components, tailor-made for one project, but how can we include them in another to reduce development time (both code and design)?

There are many different problems that can arise:

1. how can you use only part of the library components without including the whole library?
2. how can I allow the component to be styled without its appearance and functionality being distorted?
3. what can be done if the new project uses a different technology stack?
4. how can the developer’s (DX) experience be made as user-friendly as possible?

One of the most successful component libraries in the past has been Bootstrap.
A large part of its success is undoubtedly due to its completeness for many types of components widely used at the time (such as accordion and carousel), a well-structured layout system and the use of a JavaScript library that is almost ubiquitous in every site and application such as jQuery. But since then, with the decline of jQuery as a ubiquitous tool for web application development, no component library has ever achieved the success of Bootstrap.

Since then many component libraries have been seen, but almost always specific to a framework. For example, you cannot use Ant Design in a Vue project, or Angular Material in a React project. The adoption of these specific libraries in a company leads to two possibilities:

1. you limit the company to the adoption of a single front-end framework: this may suit small to medium-sized product companies, but not consulting companies;
2. one or more libraries for each framework used.

The objective is therefore to have a library of components that:

• is agnostic to the framework used in the application;
• functions without altering the code or the compilation pipeline;
• allow stylisation of the components, without allowing them to be distorted;
• can be fully or partially integrated;
• offers a familiar development experience to frequent users of either framework.

The answer to all this comes from the Web Component standard, first advocated by Google back in the day (!) 2011, and since then it has had updates and slow but steady support across browsers and web usage. In 2021, all major browsers will support Web Components, although to varying degrees due to the various features that have been added to the standards.

The term “Web Components” is actually an “umbrella term” for a set of technologies that integrate with each other to provide components that are as close as possible to native web elements in terms of usability.

Advantages

The use of Web Components opens up a number of possibilities.

• Although it is technically possible to develop Web Components in conjunction with external services and functionalities, one is naturally inclined to create self-contained and decoupled elements that can be easily reused in other contexts.
• The result of this is that their development is also quite unaffected by the technology stacks on which they will be used, and consequently they can be used almost without conflict.
• In addition, the inherent independence of Web Components also extends to the other library components, so it is easy to include only part of them in order to eliminate unused parts.
• They are easy to include in any project: generally a single JavaScript file is sufficient, and they are immediately available throughout the page, including micro-front-ends.
• The level of stylistic customisation of the components can be determined, allowing you to create white label elements that have a basic look and feel but can be easily adapted to different projects.

New challenges

One of the “classic” disadvantages of Web Components is due to the fact that the technology for realising them, as defined by standards, is very “low level” and with a high learning curve for novices. However, these are barriers that are already overridden by the presence of numerous development frameworks and libraries (such as Lit, Stencil or even wrappers such as Angular Elements), and which do not expose you to steeper learning curves than other front-end development frameworks.

In contrast, one of the main problems is without doubt the fact that Web Components are still a developing technology. The principles of the web demand that there will never be a breaking change in this evolution, but many features will certainly be added.

One of the latest additions is the so-called Declarative Shadow DOM, which solves the age-old problem of SEO for Web Components. This allows Server-Side Rendering (SSR) of Web Components as well. A number of issues remain:

• support for Declarative Shadow DOM is currently limited to Chrome (and derivatives), although fortunately this includes Google’s crawler;
• the tooling for performing SSR with Web Components is currently scarce if not non-existent.

For a complete overview of what the future of Web Components holds, please refer to this presentation given at the Codemotion conference in November 2020 (slides here).

In conclusion

One of the basic concepts it is good to learn when talking about Web Components is that although it is technically possible to replace frameworks like Angular or React entirely, the best result is achieved when they are used within them in order to share common parts.

At Antreem, the subject of Web Components is very “hot” and a library of components of our own design is currently being developed. In addition to usability for the user, the highlights focus on the developer experience and user-friendliness for developers.

We will keep our blog updated on upcoming developments!