The Hundred-Year Web Component Darkness is Over
Web Components have a somewhat sordid past. Historically, they’ve been viewed as slow to be production-ready, or not able to work well enough to support business needs today. The result of course, being the engineering-driven “let’s just solve this ourselves” mantra that has led to over a decade of churn in JavaScript framework land. I’ve been around long enough to witness it all: jQuery, Backbone, Angular, React, Vue, and that’s just the most well-known candidates.
However, the winds are changing. As organizations grow, they feel the pain of having design system components built in any specific JavaScript framework. This isn’t a post about Web Components vs. [whatever framework], but how they can live in harmony. Let’s take a look at a few recent happenings, and how legacy challenges can leverage modern solutions.
I was simultaneously surprised and unsurprised (it’s a weird feeling) to see Dan Mall’s mention in his new book, Design That Scales, that “React is a perfect fit for design systems”. Surprised because I know Dan and Brad Frost are friends, and so there seemed to be a bit of a mixed messaging there (which I’ll get to shortly). Unsurprised because I’ve been looking at a lot of design systems job descriptions lately, and 99% of current design systems roles mention React, making Dan’s assessment spot on given the current landscape.
However, Brad Frost’s recent Design System Ecosystem blog post is perhaps the most organized thought I’ve encountered around structuring separate tiers in design systems (prior thinking remains perfectly relevant). One highlight from Brad’s post is the recommendation to have your core layer consist of Web Components, and any flavor JavaScript framework sit at a completely separate tier:
Now, this might be a result of Brad’s consulting with larger, enterprise clients, however, the same separation should be a consideration for any organization, especially those with future unknowns on the horizon (think acquisitions, shifts in the JavaScript landscape, etc.).
I’ve seen this particular challenge rear it’s ugly head at multiple organizations, and believe it or not, is something I shared thoughts about way back in 2018. But don’t take it from me, take it from a slew of design systems experts working across various organizations in the industry.
I’ve been attending Ben Callahan’s “The Question” series recently, which is a sort of roundtable of design systems experts. I was surprised at session 7 (“How many platforms does your design system support?”) to hear so many responses mentioning Stencil.
Surprised because I recommended it to a former employer over 4 years ago, and delighted to hear so many stories of the challenges teams have faced with their initial attempts at design systems that were built using the popular JavaScript framework of the moment (side note: connecting with others who have faced similar challenges is wonderfully therapeutic).
Below are some of the responses from week 7 of The Question, that reflect both challenges and success design systems teams found with opting for a JavaScript framework vs. browser standard Web Components.
This story really summarizes the challenges:
From the beginning of our system it was decided that React was the way to go, because it was widely used by the product teams in the organization. However, the challenge we’re facing now is that the teams that don’t use React, cannot adopt the design system. This is happening both internally and especially with external partners. This is causing them to rebuild components using our documentation, but costing so much time and money, that it’s doing the opposite of what the design system is for. Abandoning React for something like web components at this stage seems like too steep of a hill to climb. Especially because we have to keep maintaining the current system for our current subscribers at the same time. We’re also not sure if we even need to support those teams that don’t use React internally or if they would benefit from switching to React so they can adopt the system.
Others shared success found using Stencil to support multiple web platforms:
Our Web Components platform is not really consumed directly by teams. Instead, it is used to output React and Angular versions of components through Stencil that provide much better support for the platform it is used in.
And this mention of not being able to mandate what tech the org uses rings true:
We currently build on Stencil.js and support web components, React and Angular. We cannot mandate what technology any team within the organization uses, so we have tried to create a flexible component library that can meet most teams’ needs. We have struggled with some legacy technologies trying to use design systems.
To summarize:
- Teams sharing that choosing a JS framework for the core layer caused product teams that don’t use that JS framework to either 1) not use the design system, or 2) rebuild it in their own language. Ick.
- Teams sharing that over time, choosing a JS framework for the core layer created hurdles and maintenance nightmares for the core design systems team. Oof.
- Teams identifying they can’t mandate what tech the org uses as it grows. Yup.
- Teams using Stencil to provide support to products built on varying tech stacks. Yay!
The pushback against using Web Components historically has been one of the two rallying cries from product engineering teams:
- “They don’t work in React!”
- “They don’t work in Angular!”
Recent tooling and standards have evolved to provide top-notch support for these two common JavaScript framework layers.
First, tools used to build Web Components are offering wrappers to allow Web Components to play nicely with JavaScript frameworks. Some examples:
Angular has been the most challenging integration I’ve seen historically, and specifically getting Angular’s reactive forms to talk to Web Components with Shadow DOM enabled. I was delighted to find that the ElementInternals API is a browser standard designed to address this exact challenge. While browser support is excellent, and a polyfill exists to patch things where it’s not, the most exciting development is Stencil’s abstraction leveraging the Element Internals API, which they’re calling Form Associated Components:
It’s exciting to see standards adopted so quickly in Web Component tools to allow design systems teams to leverage them as quickly as any JavaScript framework, which reduces (and mostly eliminates) the bridge to future browser support that JavaScript frameworks were originally created for.
When you take a step back to galaxy gaze, the larger patterns come into focus. Our responsibility as design systems practitioners is to ensure that the decisions we make today will best serve the organizations we support today, tomorrow, in 2 years, in 5 years, in 10 years, and to infinity.
The fact is, JS frameworks come and go, and what’s popular today is not popular tomorrow. That doesn’t mean JS frameworks are bad, they’re just a tool, and as such they serve their purpose. There’s been a lot written about how they’ve sidetracked the industry for the better part of an industry. Jared White thinks React will be extinct in 10 years. Jeremy Keith thinks it already is.
What it does mean for design systems teams is that if we’re committing to providing support to the organization(s) and product(s) we’re in service of, choosing anything else than Web Components for the core tier is nothing short of shooting ourselves in the foot with Mando’s blaster.
Whatever your personal opinion is, it’s this author’s belief that the Web Platform has evolved enough as of this writing in 2024 such that if anyone is responsible for making decisions to start a design system today, it can be a solid choice for the core layer, and JS frameworks can be layered on as a separate tier to support legacy code as it slowly goes the way of the Slith.
Best bet on the guy who rises from the dead.
