Web Components are the Future

Over the last few years I’ve drafted 4 posts that shared roughly the same sentiment. 2 were all but finished and none of them saw the light of day. This is because the projects I worked on changed and with them my stance ebbed and flowed. The short version is “use frameworks or don’t, I think the web standards and their custom elements will prevail”. Here is a summary of each post:

• Standards > Frameworks, November 2023
  • Standards are designed to be stable and long-lasting. They provide a set of guidelines and best practices that can be used to build web applications that will work well for years to come. By following standards, developers can ensure that their code will be compatible with a wide range of browsers and devices, and that it will continue to work even as new technologies emerge.
  • Acknowledged that at some point a sufficiently complex internal/in-house framework built on standards can look very similar to an external one. At least by staying close to standards, it is easier to maintain utility libraries that can be updated or swapped independently.
• Web Component Paradigms, May 2024
  • The web component spec is imperative, wanting developers to detail everything that is needed for a component and its lifecycle and this can make them hard to extend, especially when complexity grows.
  • I wrote about how using ‘wrapper’ elements can be an interesting way to find a balance between imperative and declarative programming approaches and how standards-backed policy-based classes would make HTML elements even more powerful than they already are.
• Shooting for Web Standards, March 2025
  • I don’t like frameworkism elevating products to an ideology-esque level, especially as more and more frameworks are commoditized. Instead of targeting web or JavaScript/TypeScript, popular solutions have the aim of keeping you inside their house (eg. Vercel is built on Next.js which is build on React, which is build on JavaScript). In our hyper-attention internet age it’s all too easy to get caught up in someone’s next greatest thing, which is not helped by the all too frequent version releases of your current framework of choice.
  • Metaframeworks kinda suck. Frameworkism is a lot of the reason why for current options, but the web already operates on high levels of abstraction so locking in to more can easily leave you disconnected from what your browser is actually doing.
  • Some solutions don’t lock you in per se, but rely heavily on a single commercial entity to maintain their development. I’m wary of this because ‘open-source’ can sometimes mean ‘freemium’ and when survival of the project depends upon the ‘premium’ element, open functionally could be diminished down the line.
  • I get it. We all have bills to pay and casting a wide net for a general purpose framework helps build a user base, but it can lead to frameworks that include way more features than you need and perhaps with more opinion than you’re able to change. Also, I’d rather nurture a healthy tree and keep the shaking to a minimum. If you must use large libraries or batteries-included solutions, pick your battles well.
  • A global design system built on web components is an amazing idea, but one I think will percolate organically through the web for now. We’ll see more discrete web-component systems and opinionated libraries before something global can be considered. Perhaps a registry or common directory format would help with this?
  • Highlighted Spectrum, Nord, and others for design systems & libraries as sizeable examples of web components being used in the wild.
• Naming the Stagehand Pattern for Web Components, just now
  • Shadow DOM, light DOM, exportparts, shadowRootMode, SSR, etc - there are lots of ways to render content including with suspense and hydration patterns.
  • Using :not(:defined)), elements can be styled only while they are not loaded and display:contents can be used to make components functionally invisible if you want them to enhance elements within, but avoid issues with box rendering. This is useful for scoped data providers or event handlers.
  • Giving a name to a pattern that’s more than progressive hydration by also having components act invisibly to users. Opting-in fully to SSR would allow a client-side component to do nothing when it loads, or it could progressively enhance what’s inside it; I focused on validating the child DOM (light or shadow “stage”) instead of fully re-rendering children and filling in the gaps only when full SSR isn’t possible. The emphasis being that how the contents of a component is rendered before it finishes loading doesn’t matter because it can step in client-side if needed. Akin to a stagehand only moving props during a performance (on the shadow DOM) or an understudy taking the place of a performer (hydrating the light DOM).
  • I’m not even sure if this is a good analogy, but I’m happy with having something that describes flexibility and resilience without also taking the spotlight by becoming a ‘full stack component’. DOM population can happen in whatever way one chooses without concerning components themselves. It’s an aid for discussion.

A common theme through these was that state is still difficult to manage client-side. The community Context API, building on CustomEvents, is one way to ensure component states stay up-to-date with each other and you might also consider MutationObservers, OPFS, service workers, or some of the many other relevant web APIs. State management can become but one of the pieces we plug-in to our system. The point I’m making is that we can thin the layers that exist on top of web standards to bring us back to a more composable web, and with an interoperable development experience too.

XKCD 915 Connoiseur comic

Really, I think trying to write about this took a while because it’s a hill I’ll advocate for, but not one I’m willing to die on. Arguments against web components are fine, but they exist within what is really a small bubble. After all, the world at large accepts USB as a standard interface. Maybe the web development community can progress by doing the same with web components as well? Jared White has written up a similar sentiment well in their own blog post and Brad Frost argues in favour of web components with a bit more positivity - go check them out!