TL;DR: In previous posts I described common web storefront performance issues and provided a quick introduction to web components. This post continues the series by exploring applying web components to the field of web e-commerce.

So what are some of the benefits of using web components on an e-commerce site? (Many of these benefits are not e-commerce specific.)

• Web components can reduce development effort because components can be shared between projects. This can be particularly useful for agencies working on multiple e-commerce platforms. 
• The component model in general allows large complex pages to be broken down into smaller reusable components. e-Commerce pages can get pretty complex, especially on desktop.
• Web components can be developed and tested individually.
• Web components can be created by JavaScript experts who have deep knowledge of how to build performant JavaScript code, know how to support accessibility, etc, with the components being easily used by less skilled developers.
• The built-in Chrome developer tools understand web components, making pages easier to debug.
• Web components can make indexing a page easier for search engines, because there is less JavaScript to skip over.
• Web components allow declarative markup to be stored in a database — different presentation interfaces can load up different web component definitions based on context.

The first point in this list I want to reinforce. When working with e-commerce platforms, developers generally have two pick one of two routes to follow:

1. Use the built in e-commerce platform storefront technology stack, where not all platforms give full control, or
2. Use a standalone (“headless”) storefront and connect to the e-commerce backend via APIs.

Web-components work directly in most web browsers (with polyfill support for older web browsers). That can make them easier to use in both contexts, much like CSS. I personally find this flexibility appealing. Web components let you go beyond what CSS alone can do, without mandating a different toolchain, which may not be easy to incorporate with your existing e-commerce platform stack.

Looking back at the complete list of benefits above, not all are unique to web components. For example, code reuse and testability are equally valid for components in frameworks such as React, Vue, or Angular. However, again, web components have an edge in that they are a browser level technology that works across all of these frameworks, as well as on sites that do not use such frameworks.

So web components appeal to me as a flexible technology upon which to build a library of e-commerce components that are usable across a range of different platforms and frontend stacks. They allow richer components to be built while staying within the space of basic web standards such as HTML and CSS.

What do Web Components Not Solve?

One performance problem can be the cascading waterfall load of JavaScript files. A page can refer to another JavaScript file, and so on. The problem with this pattern is the first JavaScript file has to be read and parsed before it realizes a second file is needed. Several levels of indirection can lead to a “waterfall” as all the files are loaded.

To overcome this problem, one approach is to use a tool to bundle all the JavaScript files into a single download. This is an orthogonal topic to web components. The same bundling technologies can be used with web components if desired.

The only benefit that web components could offer here is it has been observed that by having special purpose web components, they tend to use minimal JavaScript code. This is in comparison to using a more feature rich JavaScript library such as jQuery. However, this is a trend not a guarantee. Web components can be built using jQuery if desired.

Do Web Components Have a Future?

Web components are not new, so why have they not taken off until now if they are as good as the above implies? One reason is they have not been supported by all the major browsers until recently. As a result, there was a lot of noise early on but they never really took off due to lack of cross browser support.

It was also less certain early on that they could be used with frameworks such as React. This however has been now addressed by the main frameworks as well, so is no longer a significant concern. (React even has a page describing web components can be used in React, and React can be used inside web components.)

Returning to the original list of problems, while there are other solutions as well, web components can help with the following issues as noted:

• Referenced images are too big. Web components can implement more advanced logic to pick the most appropriate image resolution, without cluttering the marked up page with such logic. This also allows the logic to be changed later without modifying the original content.
• Images on low-end devices. Web components can encapsulate the knowledge of the right image format and size to select.
• Unused CSS and bundling CSS. Web components can result in simpler CSS as styling may be incorporated inside the web component (e.g. when using Shadow DOM).
• The average volume of JavaScript on a site is going up. Special purpose web components can encourage leaner code bases. Rather than loading a large multi-purpose library like jQuery, you can load a single component with just the code needed for that component. (This of course falls down if the component implementer uses the larger libraries.) Note that if you are doing smaller DOM manipulation tasks, you might not need jQuery.
• JavaScript can be render blocking. Web components don’t stop render blocking JavaScript, but do encourage code reuse. Experts can develop web components for a larger team of developers to use without being as expert.

Web components also have additional benefits.

• They browser level technology allowing them to be reused across platforms
• They can be used in plain HTML without knowledge of JavaScript. This makes them accessible to lower end developers. (I personally really like th
• They can be used by platforms that use HTML server side rendering. There are still a lot of platforms that rely on server side rendering.
• They can be used by most frameworks such as React, Vue, Angular etc allowing a component to be written once and reused on multiple frameworks. A React component library in comparison can only be used with React, not Angular.

Conclusions

One of my goals this year is to explore the idea of building up a library of web components and examples using them focussing on e-commerce use cases. These would provide examples of common UI patterns. My personal goal is to build production quality sites with no JavaScript on the page, reducing the complexity of creating efficient storefronts. It would be up to developers whether to use the components or not giving them freedom of choice.Such components can then be used on multiple e-commerce platforms, from advanced React/Vue/Angular based sites down to the simplest PHP server side rendered sites. The more JavaScript can be removed from pages, the less chance of JavaScript negatively impacting site performance.