Web components are a great companion to reusable component design systems. However, trade-offs over custom designs can be large for enterprise web apps.
The design process involves laying out screens in tools like Sketch, Adobe XD, Envision and Figma. For complex projects, the designer relies on creating reusable components to maintain consistency. They have become a central feature of design tools for exactly that reason. In other words, consistency in design is key. But so is their ability to transfer to object-oriented development. Parameters of reusable components directly translate to user interface (UI) objects during development.
Web components are custom HTML elements embedded with unique functions, styles and behaviors. For example, button elements can have event listeners, themed styling or other requirements. These custom buttons replace standard HTML buttons. The defining aspect of web components is they are encapsulated away from the document object model (DOM). Instead, they use their own sub-DOM, called a shadow DOM.
Encapsulation is essential for maintaining consistency in interface design. This is true for web applications of even average complexity because CSS styles can often inherit and overwrite each other in unpredictable ways. The behaviors are difficult to pinpoint and fix. But web component style rules are independent of the DOM and other components. Therefore, encapsulation solves the problem by untangling the mess created by CSS styles.
Web components match the simplicity and function of reusable components. They allow for a seamless translation between the designer’s component file and developer’s web component UI kit. The biggest benefits come when the team agrees on standard functions and styling. Then global style rules can be applied to a common, reusable, web component library. This strategy reduces both design and development time and cost.
For prototyping user interfaces, web components are fast and effective. Yet, there are performance costs to adding too many. To illustrate, I copied simple web components and tracked page load finish times. The following table shows increases in load times as I added more components:
|Number of Components |
Added to DOM
|Page Load Time|
In the abstract, it may seem preposterous to add over 1000 elements to a screen. In fact, the common case of order-entry systems—showing hundreds of products, each composed of many web components—requires an extraordinary number of elements. The load times shown above don’t even include the time to receive data from an API endpoint. For Enterprise Resource Planning (ERP) and Cloud Provisioning systems, web components stall the load time and UI responsiveness. If levels are unacceptable, the their use requires complex loading strategies. General development frameworks, such as React and Angular, specialize in the necessary loading strategy. But web components are best suited to front-end micro frameworks. Combining web components with other frameworks also has trade-offs—a discussion for future posts.
In short, structured consistency in design and development is key. Web components offer a clear advantage. But for enterprise web apps, speed is an essential feature. On that, web components do not easily deliver.