Stop Comparing Web Components to React: The Trap of Library-Centric Criticism

The realm of web development is teeming with choices, each technology vying for developers’ attention. On one hand, powerful libraries like React have revolutionised how we build web applications. On the other, there are Web Components—although not as “foundational” as one might think, given that they’ve been universally supported by browsers only since 2020. Yet, they are increasingly important in the modern web ecosystem.

With its massive ecosystem and community, React often becomes the yardstick against which other technologies are measured. This is especially true for Web Components. However, this comparative framework is unfair and fosters misleading criticisms stemming from overreliance on libraries like React. This post aims to disentangle these misplaced critiques and highlight why Web Components deserve to be evaluated on their own merits.

Web Components: A Newer Entrant with an Old Soul

First, let’s set the record straight: Web Components aren’t as foundational as HTML, CSS, or JavaScript. They gained full browser support only in 2020, making them relatively new entrants in the web technologies arena. However, they encapsulate the philosophies of the open web—extensibility, encapsulation, and modularity. They enable developers to create custom, reusable HTML elements, extending the HTML specification on a per-project basis.

Web Components stand on the shoulders of all the work done on the HTML and Javascript specifications before them. There are many specifications in various stages of development to make them even better, including support for reactivity and other improvements around styling and presentation.

The “Verbose API” Misconception

One frequent criticism of Web Components is their verbose API compared to React’s more streamlined approach. It’s essential to understand that this verbosity is not an arbitrary design choice; it serves a purpose. Web Components are designed to be low-level and unopinionated, giving developers more control. The API’s explicitness facilitates a clearer separation of concerns and enables more modular and maintainable code.

Shadow DOM: Misunderstood, Not Flawed

Shadow DOM is another feature that draws criticism for being “overly complex” or “difficult to work with.” The reality is that Shadow DOM offers robust encapsulation for behaviour and style right out of the box. This isolation level is not natively achievable in React without relying on external libraries or specific CSS methodologies.

It’s not that Shadow DOM is inherently complicated; many developers lack familiarity with it. This unfamiliarity leads to discomfort and, ultimately, misplaced criticism.

Performance: The Apples-to-Oranges Fallacy

Comparing the performance of Web Components and React is akin to comparing a truck’s fuel efficiency to a sedan—they’re designed for different use cases. React’s Virtual DOM solves specific DOM manipulation problems, offering its own performance advantages and trade-offs. Web Components, being “close to the metal,” provide a different set of performance characteristics, which can be fine-tuned to a greater extent.

The Perils of Overreliance on Libraries

Much criticism against Web Components arises from an overreliance on libraries like React. This dependency can atrophy a developer’s understanding of web fundamentals, leading to unfair judgments when encountering different paradigms like Web Components. It’s not that React or Web Components are universally superior; they serve different needs and should be chosen based on the problems at hand.

We have seen the same thing happen with arguments against classes. When React famously introduced React Hooks, it was interpreted by the community as classes are bad and shouldn’t be used. React introduced Hooks because of design flaws in React itself, not because classes are bad.

Conclusion: The Value of Technological Pluralism

Web Components and React serve different purposes and are geared towards solving different problems. But one key distinction that often gets glossed over is their relationship with the web platform itself. Web Components align fundamentally with the platform’s core extensibility, encapsulation, and modularity philosophies. They’re about leveraging what the browser already provides, about coexisting with the HTML, CSS, and JavaScript that power the web.

React, on the other hand, has a different ethos. It’s not just that it offers a higher level of abstraction; it’s that this abstraction often veers into the territory of being “anti-platform.” While powerful, it creates its own ecosystem that often operates like a silo within the broader web landscape. It’s telling that React doesn’t even offer native support for Web Components. The library is so wrapped up in its own world that it doesn’t fully embrace what the platform offers.

So, what’s the takeaway here? Simple: Don’t get so caught up in the React echo chamber—or any library’s echo chamber, for that matter—that you lose sight of the web platform itself. The platform is more than just a stage on which libraries and frameworks perform; it’s a robust, feature-rich environment that we can—and should—engage with directly.

Next time you instinctively reach for React or any other library, pause for a moment. Consider whether you’re making that choice because it’s the best fit for your project or because it’s simply what you’re accustomed to. Technologies like Web Components aren’t just alternatives to React; they’re reminders of what the web platform is capable of.

The criticisms often levied against Web Components usually reflect less on the technology and more on our conditioned behaviours and limited perspectives. It’s time to break free from the gravitational pull of familiar libraries and take a fresh look at what the web platform can offer. That’s not just being a skilled developer; that’s being a thoughtful one.