Hey there, design systems enthusiasts! Let’s talk Web Components again. We’ve discussed why they’re great and how to build them, but it’s time to address the elephant in the room : “Why is their adoption so low if they’re so great?”. On the surface, they seem like a perfect fit for building reusable component libraries. But hold on, there are reasons they haven’t taken over the world.
A Case of Bad Timing
Web Components arrived in 2011, just as Angular was blossoming and React was waiting in the wings. By the time the specs solidified, these frameworks had revolutionized app building. Developers saw them as a one-stop shop, handling everything from interfaces and interactions to state management and routing. Web Components, with their narrower focus, simply didn’t have room at the table.
This led to a smaller Web Components community, resulting in…
A Lacking Developer Experience
With fewer developers using Web Components, even fewer were working on improving the developer experience. While Google’s Polymer was a pioneer, the limited benefits coupled with the shadow of AngularJS’s drastic overhaul (another Google project) discouraged investment. Building Web Components remained a complex, JS-heavy task, leaving Design Technologists and UI Engineers on the sidelines. Even today, finding good tooling and learning resources for Web Components pales in comparison to any framework, including niche options like Svelte.
The SEO, Accessibility, and SSR Hangover
Web Components rely on JavaScript and Shadow DOM, which can raise eyebrows when it comes to SEO, accessibility, and server-side rendering (SSR). In the past, elements relying on Shadow DOM, like <select> or file upload inputs, caused headaches for developers and assistive technologies. This stigma carried over to Web Components, even though they can be implemented accessibly with careful use of Light DOM and complex spec features. The same goes for SEO – it’s achievable, but requires extra effort and careful planning.
SSR, a crucial aspect of modern frameworks, presented another hurdle. Frameworks let you create static sites for users with disabled JavaScript or search engine crawlers, while still offering app-like features for interactive users. Web Components aren’t inherently incompatible with SSR, but they require a different approach than originally envisioned. Shadow DOM, once seen as the hero of abstraction, became the villain of complex DOM structures and challenging documentation. Thankfully, Web Component libraries offer solutions, but the SEO, accessibility, and SSR concerns remain significant barriers to adoption.
What people usually mean when they ask if they can SSR their web components is this: hey, can I take the code I’ve already written for client-side web components using all of the web component APIs (especially shadow DOM), and basically take an on-the-fly snapshot of that render tree and stick it in my output HTML (whether for a static site or a dynamic server)?
Enhance vs. Lit vs. WebC…or, How to Server-Render a Web Component
The Talent Pool Problem
Most companies were already invested in frameworks like Angular, React, or Vue. Introducing Web Components meant adding another tool to the shed. Similarly, content-oriented websites using CMSes didn’t see a burning need for Web Components, especially considering the potential inconsistency. Finding Web Component developers is also a challenge – their numbers pale in comparison to the vast pool of React, Angular, or Vue devs. Even hiring specialists creates limitations; their expertise might not be transferable across other projects within a company.
The Design System Dilemma
All these issues translate to challenges for component libraries and design systems. Internal contributions become trickier, as developers need to learn a new language to contribute to the system.
[On the importance of contributions] unlocking scale and reach that would not have been possible without the engagement
Supercharging your design system contribution model – Mark Boyes-Smith
While framework-agnostic design systems benefit from Web Components, it limits the option to large companies with dedicated design system teams (like IBM with Carbon), or those building systems for external use (like Salesforce for plugins).
So, What Now?
Web Components have immense potential they haven’t reached yet. The good news? The community is actively working on improving developer experience, tooling, and addressing SEO, accessibility, and SSR concerns, as we’ve seen in a previous article about the Ecosystem around Web Components while companies are seeing the ROI of Design Systems and ready to invest more into them.
Companies also learn from their mistakes and some of them are already working on their 4th or 5th iteration of their Design System, accepting the fact that all the issues presented above may not be worth than the pain of delivering and maintaining a Design System for multiple frameworks at the same time.