The Many Faces of a Web Component
When we learn a new technology and use it for a while, our minds can get locked into a particular way of thinking. We can create fixed associations which don’t necessarily exist and miss the obvious opportunities staring us in the face. Sometimes this leads to over architecting solutions or even mis-solutioning a problem entirely.
For these and other reasons, I wanted to write a short article about a few of the very different ways to use Web Components. I hope to demonstrate that there isn’t a 1:1 relationship between Web Components and any particular architecture or topology.
Contrary to what some may believe, Web Components aren’t an architecture. They aren’t a framework. They aren’t even a pattern, per se. Web Components are a core Web Platform capability. Because of this distinctive, this set of standards can help enable a wide variety of software architectures and component topologies.
Read on to explore with me a few of the many different ways to leverage Web Components in modern web development.
Architectures
For decades, we’ve built every existing browser experience, in some form or another, out of elements. They are, true to their name, elemental, and by their very nature, form the foundation of every existing browser-based architecture.
Now we have Web Components, the way the platform opens up its foundation to enable anyone to build their own elements. Prior to this, all our architectures have been built on a fixed set of “black box” elements. With Web Components, that’s no longer the case. Now, we can use custom elements to enhance all our previous software designs, and even envision new ones.
SPAs
Similar to any modern component-based JS framework, Web Components can be used to build Single Page Apps (SPAs). You can design an architecture where your entire application exists as a composition of hundreds or thousands of Web Components, all rooted in a single application-level Web Component that lives in the document body. Some very large Web Component experiences have been built this way.
If a SPA architecture is the best fit for your problem/solution space, then Web Components are a great set of capabilities to explore. However, this isn’t the only way to use Web Components.
MPAs
Web Components aren’t confined to SPA scenarios! Again, just think of them as elements. From the beginning of the web, we created multi-page applications (MPAs) using elements. That continues and is enhanced with Web Component custom elements.
You can use any server framework and all the traditional techniques for multi-page applications with Web Components. In the same way you would server-render a <div>, you simply output <your-custom-element> tag. This means you can use Web Components for your design system, mixing them with built-in elements on each page. You can also use Web Components to build out more highly interactive experiences, embedding little pieces of richness into individual pages as needed. You can use Web Components for shared navigation, such as a sidebar or common header, across the hundreds or thousands of sites an enterprise may own, and you can deploy the shared components independently from the individual sites. There are no limits to how or where you can use custom elements within a multi-page application.
With server-side frameworks like Rails, Laravel, ASP.NET, Spring, etc. you can even build out custom HTML helpers that generate your standard Web Component markup, adding ergonomics and consistency for your server-side dev team.
There is a lot of innovation just waiting to happen in this space! Please reach out if you are building anything for a specific backend technology. I’d love to see what you come up with!
MiniApps, Micro Frontends, and Composite Applications
One of the critical technical questions to resolve when creating a MiniApp ecosystem or a Micro Frontend architecture is how various components will plug into the system. ES Modules and Import Maps help out with the loading and modules part of the answer. Web Components are a great solution for the DOM integration part of the answer.
ASIDE: There is a lot more to shell architecture than just module loading and component interop. For example, there is also router integration, shell services, design system coherence, etc. But the first things you will usually have to figure out, just to get something up and running, are loading, modules, and component integration, which I’m happy to say are now all addressed directly by Web Standards.
In fact, if you are building any sort of an open ecosystem, even within the boundaries of your own company, Web Components are a huge enabler for not only the necessary technical integrations, but also for the processes that are involved. For example, because a Web Component decouples its implementation from its interface, unlike with React, you can ship modules that use the Web Components without a build-time dependency on the component implementations. This late-binding feature of the platform massively simplifies large-scale, modular architectures, simplifies deployments, and enables teams to work in a more agile fashion.
Design Systems
Probably the area of widest Web Component usage today is in the creation of design systems. One of the reasons for this is that by creating your core system in Web Components, it can then be used with any front-end library or framework. This approach enables incremental adoption in existing codebases, which is important given the large amount of web code businesses have already.
Here’s another important point that is often missed. By building your design system with Web Components, you decouple your system decisions from your application decisions. This gives you more flexibility and agility because you can now choose the technology, library, or framework that makes sense for the type of application you are building, without having to tie that to your design system’s technical implementation.
Topologies
When building experiences, there are a variety of ways to distribute and execute your components. The overall application architecture type doesn’t sit in a 1:1 relationship with component topology. Any given application may use a variety of different topological approaches within its architecture.
Progressive Enhancement and Islands
The technique of Progressive Enhancement (PE) can be enabled by highly targeted use of Web Components throughout an application. The most obvious place for this would seem to be traditional MPAs. This approach is not unlike using jQuery or Mootools widgets in the past, or following the principles known as “unobtrusive JavaScript”.
That said, the technical approach that accomplishes this, while not strictly progressive enhancement, can make sense in certain SPA’s or SuperApps as well, particularly where there may be a massive number of components and no way to know/predict which ones will appear at any given time on the page.
A typical example of this scenario is a social feeds experience where many different types of content components may appear in the feed, but which ones appear are highly contextualized to the current user, current events, and any number of rapidly changing inputs. While this experience may take place in the context of a SPA, a targeted approach of progressively enhancing card components on the fly based on user interaction can have a dramatically positive impact on user experience.
Server Only
Now that we have Declarative Shadow DOM (DSD), Web Components can be rendered on the server. There’s no reason that these components have to exist on the client as well though. There is a subset of Web Components in many apps that don’t have any behavior, but only compose markup and styles. This is particularly common in content-heavy experiences. This type of component can be fully rendered on the server with zero JavaScript sent to the client afterward. The browser then automatically handles rendering the DSD and styles with no intervention from the developer.
NOTE: Technically, this isn’t a Web Component at all! It’s just using Declarative Shadow DOM. A benefit of many Web Component-related technologies is that they can be used independently of custom elements. In practice, you’ll probably want to keep your DSD templates and styles co-located though, and a server-side component of some sort is probably still the best way to manage that, especially if the static rendering still requires some logic. Just don’t forget that you have Web Components as-a-whole as a tool, but also each individual standard capability as well. Use this to your advantage.
Client Only
Likewise, you can render content on the server, but choose for some Web Components to only render on the client. A good case for this is probably the typical design system. You will need to profile your own application, but you may find that there is no performance advantage to SSR’ing your primitive design system components. It may actually be better and simpler to let those client-render only. Profiling may even reveal a specific set of your components across your app that benefit from this approach. Don’t make assumptions and be sure to use all the tools available to you.
Server and Client
Of course, you can also choose to server render your components with DSD and then hydrate them on the client as well. But this isn’t the only way to do it.
You may recall that a critical feature of Web Components is that they decouple their interface from their implementation. As a result, you can have more than one implementation for a given Web Component. For example, you could have a server version that is different from the client version. Your first inclination might be that this would create double the work, but I want to remind my readers that there need not be a 1:1 relationship between interface and implementation.
Let’s revisit the social feed experience I discussed above in the section on progressive enhancement. Imagine that each card in your feed has unique HTML and CSS but that the interactions across all the cards, or a significant subset, are the same. In this situation, we could begin with unique server implementations for each of our components. When the feed needs the next page of cards, the server will render the cards out using DSD and stream them to the client. The client will simply append the HTML to the feeds container and be done with it. But imagine that we don’t have unique Web Components for each of those card types on the client. We could give every card type on the client the same implementation. This singular implementation could read metadata from the host element and its DSD and use that to connect up a set of common behaviors shared across all cards, or even load custom behaviors on demand based on various heuristics (scroll into view, mouse position, first click, etc.). Instantly, your JavaScript payload could be decreased from hundreds of kilobytes or even several megabytes, down to just a few kilobytes. Not only is your payload decreased, but your JavaScript parse time is reduced as well, and all along you have a massively simple, highly cacheable approach that will perform very well even on down-level devices. This is just one example of many possible client/server component topologies.
NOTE: If the above topology sounds familiar to you, it’s because it’s very similar to Qwik. The big difference is that what I describe here requires no framework, is based on Web Standards, works seamlessly with open and closed Shadow DOM, and is performance optimized directly by the platform. And yes, you can build something like this yourself. I encourage you to give it a try for fun. Let me know what you come up with!
Wrapping Up
There are so many ways to leverage Web Components. Above are just a few thoughts showing how Web Components don’t dictate a particular architecture or topology. They can fit in and enhance just about any web scenario that you need to build out and provide new platform-optimized opportunities. As I have spoken about previously, take time to think critically about the real problem you are trying to solve and what the best fit solution is. Once you have established that, only then consider whether Web Components make sense as part of your technical implementation, as well as how they fit in. They might integrate in one of the ways I’ve mentioned above, a combination of these, or something else entirely. There isn’t only one way to use Web Components, which is part of the enduring nature of the Web Platform.
If you enjoyed this look into Web Components, you might want to check out my Web Component Engineering course. I’d also love it if you would subscribe to this blog, subscribe to my YouTube channel, or follow me on twitter. Your support greatly helps me continue writing and bringing this kind of content to the broader community. Thank you!
