Web Components - a Big Step Forward

Introduction to Web Components

Web components are nothing but a new set of web standards around HTML and DOM specs, which let the developers to extend HTML elements as new Custom Elements. This encapsulated custom element can be a simple ”button” or it can be a complete Web Page and it is really depends on the requirement. Web component standards are supported in all modern browsers and polyfills are available for most of the old browsers. To explain conceptually, we all traditionally worked with server-side pages and built hundreds of Web Controls (e.g. Custom Controls in ASP.NET) which intern contributes to a huge spread of component library owned by an organization. If you toggle the same concept to HTML and client-side programming then that is nothing but a web component and component library. We will not go into the technical details of web components and for more read please follow this link.

But on the other side, we will also talk about the major frameworks like Angular and React, with more focus on Web Components. Today, the growing demands on organizations to support multiple devices, requires lots of investments on resources, frameworks and technologies. As the given modern browsers and growing demand on code re-usability, it is time to shift the focus towards web components which is completely framework agnostic and purely on HTML standards. The objective of this blog is to share more insights to web components and also to highlight few organizational opportunities

Why Web Components

The key challenges for an organizations is building UI components with high re-usability, which also ensures brand consistency and avoid redundancy between teams. There will be number of teams in an organization which runs with different frameworks and technologies and it is naturally unavoidable. But if you can manage to avoid rebuilding similar components at a certain level, then it is a big achievement for any organization. The same can be achieved by introducing distributed web component libraries at organization level. We will cover more on organizational opportunities in below sections, but lets start with few key benefits,

Browser Standards: Web components is a standard that was added by the “World Wide Web Consortium” or W3C. The W3C sets or defines the standard of features that browsers can implement. Saying that, we do not need any complex framework to facilitate creation or rendering of components. The core elements of Web Components are Custom Element, Shadow DOM and HTML Templates

Modularized Code: Web components enable developers to write applications in a more modular way by breaking the applications down into smaller logical chunks with reusable functionality

Brand Consistency: Having your front-end application code split up into component libraries or even design systems can ensure brand consistency across the company. It also provides an additional benefit of the ability to be used by all teams, regardless of tech stack. Web components are also extremely useful for teams who are working on many different projects

Browser Support: As mentioned, all the modern browsers do support web components other than IE Edge. But we do have polyfills available to support the same. On the other side, we also hear initiatives from Microsoft to build IE with Chromium, which means that IE will naturally support all what Chrome as a browser supports. Also if your application is currently running with AngularJS or React like most of the teams today then you can easily integrate web components, you can find more details of the same here (link)

Serve Side Rendering: As we build native elements, the complex html for an business requirement with data can be built in the server and rendered in the client rather building the HTML in the client. In certain business cases, this will give a high performance benefits e.g. content management systems.

Web Components and Architectural benefits

Building an enterprise level architecture around web components is definitely a big opportunity for organizations. Often the modern single page applications (SPA) is large frontend monolith and uses the microservice architecture excluding frontend. The monolithic frontend application will grow over time, developed by a separate team and gets more difficult to maintain. All these are signs to divide the large frontend application to multiple micro frontend applications. So that each micro frontend application can be developed by separate team and they all integrate in the frontend for users

Today most of the enterprise applications are built as microservices, but the applications which are built as microservices to break away from the monolith model are still sticks to a frontend monolith in most of the cases. In general to break away from frontend monolith, a shell or container framework will be built and all the child applications will be delivered using that container. At the same time, one of the below options will be considered to wire-up the shell and child applications

Multiple SPAs and hyperlink between SPAs
Iframe multiple SPAs as a Single Application
Web Components and just one Application

Among above options, web components are the most efficient way in modern development which helps you to build each micro apps as web components. As each micro app is a web component they can naturally used as an single application without an Iframe or a shell container. Assume you are developing an application like Office365 online or Google Apps, where each components are like Outlook, Excel or Maps can be developed as separate web component and can be stitched with a shell. Though they are not done in that way today, for example Google Apps takes the option one, which is Multiple SPAs and hyperlinks. So it is completely depends on the requirements and application needs whether we choose to have web components are not

User Interface as a Service

Once you have the re-usable UI components, how we can distribute the components between teams is an important thing. Choosing the right distribution method is actually off from this topic of web components, but it is still worth to write about it for a completeness. In general, sharing of UI components happens with in an organization will happen through internal repositories as component libraries. As we have growing version dependencies and backward compatibility support expectations. Having an internal NPM repository of web components, is a best thing we can do and which comes along with versioning. The users can directly pull re-usable components from this repository than re-writing them in their own project repo. Nexus or the latest versions of TFS does support delivering NPM packages from the repositories directly. Other side, we can have a internal CDN deliver the component dependencies too.

Here “User Interface as a Service” is a coined term based on the modern trends. But the opportunity here is to build a web component library and host the same in an internal CDN, to deliver across teams. Saying that, I have also pictured how the components can developed using different tools and technologies, and distributed between teams for re-usability and consistency

The shared components through a library, can further be used to compose products, pages or a section in a products’s web page. This is completely based on the requirement and as mentioned earlier, it is a progressive application development model. Day one, we will not have all the required components to build a product. Also the other side all the existing products will not have any business case to replace all its pages as web components. So a partial replacement or a progressive addition of web components and encouraging teams with build once model will help organizations to achieve their long time goals. An example of partial replacement is, I assume almost all the products has an requirement to display set of news headlines and detail story of the selected headline and call it as a “NEWS COMPONENT”. This news component can be just built once, with required inputs are parameterised like news source (API) and filters etc. Then we can use the same news component across all products, which will gives us high re-usability and consistent branding with look and feel by nature.

On the other side, if we have a full spread of components in our component library after some time, then we can also build a whole product with this library. Please refer to the image below which explains how a web page will be constructed from a shared library of components. The components are served through an internal CDN and each components are developed with different business purpose and scoped along with version support (e.g. a Navigation bar can be created at organization level and shared across to maintain high brand consistency)

Javascript Frameworks and Web Components support

Also one of other key challenge that organizations has is to support diverse technologies used across teams and the growing demand on adoption to new technologies. After you end up in a diverse technology spread across teams, the re-usability of code and components with in the organization is no more an option. The good news is that, you can still allow your teams to work on different technologies and framework of their choice and still achieve high degree of re-usability by building Web Components with preferred technology. For example if your team it running on Angular, the new feature Angular Elements (nothing but Custom Elements) can work seamlessly within your Angular application and also the same can be shared as Web Components with other teams which are running with different frameworks

Lets talk little bit more about it, yes we can develop native web components with Javascript. But it will be a tedious task, knowing the complexity of implementing all the required interfaces. Given a chance, we always prefer to use a high level language than writing in machine language though it is more powerful. Here it comes the modern frameworks which supports you to write sophisticated Web Components with ease. A mentioned above, Angular Elements is one of its kind which provides a compiler to translate Angular code to Javascript (to ES5 or ES6 native Web Component)

Angular, Dojo2 and Stencil (Ionic compiler) are some of those which provide tools to develop web components. The delivered web components then can be used in any framework or in VanillaJS depends on your needs. These tools are little different from PolymerJS, where Polymer traditionally build and deliver components based on web component Spec and the same can work with one of your existing web pages along with polymer.js. Saying that, it is a kind off runtime integration. But on the other side like Stencil are, just development tools which can output a native web component and it is just a development time dependency

Developing Web Components using VanillaJS is also an option, but as mentioned above it is not much productive. Not just that, what about the rich features which comes by default from most of the frameworks we have today. For e.g. Dependency Injection, Data binding, Async Rendering, State management and etc. Also the rich developer experience with Typescript and various bundling tools. We don’t want to re-build all these features by choosing to work with native components rather pick one of your favorite tool like Angular Elements and Stencil and I listed little more details around the same below,

Angular Elements - As mentioned by Rob Wormald, Angular Team, “Elements are, Angular Component on the inside, Standards on the outside”. Angular Elements is a library along with Angular (6+) to support development of Custom Elements along with Angular Application development. As you all know most teams runs with Angular today and they can easily convert or develop their Angular Components to Angular Elements (nothing but web components) and which can seamlessly work with their own application and also can be shared to other team (non-angular) as web components (just a post build event can do the trick). More read - 5 reasons to choose Angular Elements

Dojo2 - One of the early player on Javascript frameworks (dojo) has come up with a full re-write called dojo2. As every other framework it is built on top of Component architecture, keeping high performance and re-usability as the objective. Dojo2 is an application framework and also provides a compiler for web components which can create really a small bundle (in few KBs) for each component.

Stencil - It is an Ionic team developed open-source compiler for web components with rich application features. Stencil adopts the best practice from Angular and React etc. For an example, it uses Typescript and on the other hand it supports JSX. Ionic 4 is built on Stencil, which comes with ready to use web components for your application development and Ionic is really a low code platform for mobile application development. Also outputs an optimized web component bundle and which can be added to any web application (more read)

AngularJS (1+) upgrade opportunities

There are number of applications built on AngularJS 1.x and running successfully. In some cases, they are also looking for an upgrade opportunity to Angular 2.x, for better performance and future enhancements. In the past there were lot of options discussed and suggested for upgrade from Google’s Angular team and others. Recent times in few Angular events there are topics discussed, we can use Angular Elements to upgrade AngularJS 1.x applications progressively. I did link a video of AngularConnect event which covers more about it (link)