Hacker News

Web Components: The Framework-Free Renaissance

2026-02-208:45211151www.caimito.net

Modern browsers now support everything needed to build sophisticated, reactive web interfaces without React, Vue, or Angular. Web components, custom elements, shadow DOM, and native event systems l...

8 min read

Building Modern UIs Without the Framework Tax

17.02.2026, By Stephan Schwab

Modern web browser window showing interconnected custom HTML elements with clean, modular code

The Shift That Already Happened

Something remarkable occurred while many developers weren’t watching. The web platform itself became capable of doing what frameworks were invented to do.

"The browser has become the framework. We just haven't fully noticed yet."

Custom Elements let you define your own HTML tags with their own behavior. Shadow DOM provides encapsulation that keeps component styles and structure isolated. Templates and slots offer composition patterns. And perhaps most importantly, the native event system provides a robust mechanism for components to communicate without tight coupling.

These aren’t experimental features. They’ve been shipping in every major browser for years. The question is no longer whether they work, but why more developers haven’t embraced them.

Freedom from the Upgrade Treadmill

Every framework carries hidden costs. There’s the initial learning curve, certainly. But there’s also the ongoing maintenance burden: major version upgrades that break things, deprecated patterns you must migrate away from, build tooling that needs constant updating.

"When your component is just HTML, CSS, and JavaScript, there's nothing to upgrade except your own code."

Web components built on platform standards sidestep this entirely. The browser vendors have committed to backward compatibility in ways that framework maintainers simply cannot. Code written to web standards a decade ago still works today. That’s not true of code written for Angular 1, or React class components, or Vue 2’s options API.

For organizations building products that need to run for years, this stability matters enormously. It’s one less thing that can break, one less dependency that can become a security vulnerability, one less abstraction layer between your code and the runtime.

Components That Talk to Each Other

The elegance of web components becomes most apparent when you consider how they communicate. The native Custom Events system provides everything you need for sophisticated component interaction.

A component deep in your UI hierarchy can dispatch an event that bubbles up through the DOM tree:

this.dispatchEvent(new CustomEvent('item-selected', { detail: { itemId: this.selectedId, metadata: this.itemData }, bubbles: true, composed: true
}));

Any ancestor component — or the application shell itself — can listen for and respond to that event. There’s no need for a global state store, no prop drilling, no context providers. The DOM itself becomes your communication infrastructure.

"The DOM has always been an event bus. We just forgot how to use it."

Components can also communicate downward through attributes and properties. When a parent changes an attribute, the child’s attributeChangedCallback fires, giving it a chance to respond. For more complex data, properties allow passing objects and arrays directly.

This creates a natural, predictable flow: data down through properties and attributes, events up through the bubbling system. It’s the same pattern React popularized, but using web standards instead of library abstractions.

Learning Through Building

Here’s something that surprises many developers: you don’t need to master every detail of the Web Components specification before you can build useful things. The basics are remarkably accessible.

A minimal custom element looks like this:

class TaskCard extends HTMLElement { connectedCallback() { this.innerHTML = ` <div class="task"> <h3>${this.getAttribute('title')}</h3> <p>${this.getAttribute('description')}</p> </div> `; }
}
customElements.define('task-card', TaskCard);

That’s a working component. It’s not production-ready — it lacks reactivity, encapsulation, and proper lifecycle handling — but it demonstrates how accessible the entry point is. You can iterate from this simple beginning toward more sophisticated implementations as your understanding grows.

AI as Your Pair Programming Partner

"The best way to learn web components is to build them — and AI makes experimentation nearly frictionless."

This is where modern AI assistants transform the learning experience. You can describe what you want a component to do, receive a working implementation, and then ask questions about the parts you don’t understand. The AI can explain why composed: true matters for events that need to cross shadow DOM boundaries. It can show you the difference between connectedCallback and constructor. It can help you refactor toward better patterns as your requirements evolve.

You don’t need to read the entire MDN documentation on Web Components before building your first real component. Instead, you can learn by doing, with an AI partner that understands the specification deeply and can answer questions in context.

This approach — building first, understanding deeply second — works remarkably well with web standards. The patterns are simpler than framework patterns because there’s less abstraction. When something doesn’t work, the debugging surface is smaller. When you want to understand why something works, there are fewer layers to peel back.

A Practical Architecture

Consider a realistic scenario: a dashboard with multiple independent panels that need to respond to a shared filter.

Without frameworks, you might structure this with a simple event-driven architecture:

// FilterPanel dispatches when criteria change
this.dispatchEvent(new CustomEvent('filters-changed', { detail: { dateRange: this.selectedRange, categories: this.selectedCategories }, bubbles: true
})); // Dashboard shell listens and broadcasts to children
document.addEventListener('filters-changed', (e) => { document.querySelectorAll('[data-filterable]').forEach(panel => { panel.applyFilters(e.detail); });
});

Each panel component implements its own applyFilters method. The panels don’t know about each other. The filter component doesn’t know about the panels. The dashboard shell provides minimal coordination. Components can be developed, tested, and reused independently.

"Loose coupling isn't just elegant architecture — it's faster development and easier maintenance."

This same pattern scales. As you add more panels, they simply implement the expected interface. As you add more event types, the coordination logic grows proportionally, not exponentially.

Shadow DOM: Encapsulation That Actually Works

One of the most practical benefits of web components is shadow DOM encapsulation. Your component’s styles don’t leak out, and global styles don’t leak in (unless you explicitly allow them).

class StyledCard extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); } connectedCallback() { this.shadowRoot.innerHTML = ` <style> .card { padding: 1rem; border-radius: 8px; background: #f5f5f5; } h3 { margin: 0 0 0.5rem 0; color: #333; } </style> <div class="card"> <h3><slot name="title"></slot></h3> <slot></slot> </div> `; }
}

Those styles affect only this component. You can use simple, semantic class names without worrying about collisions. You can refactor styles without fear of breaking something elsewhere.

This is encapsulation that actually encapsulates. It’s what CSS Modules, CSS-in-JS, BEM, and countless other approaches have tried to achieve — built directly into the platform.

When Frameworks Still Make Sense

Web components aren’t always the right choice. If your team already knows React deeply and moves quickly with it, there’s real value in that shared expertise. If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction.

"The best technology choice is the one that fits your team, your timeline, and your constraints."

For new projects, though — especially smaller teams or solo developers building products that need to run for years — web components deserve serious consideration. The reduced complexity, improved stability, and smaller bundle sizes create real advantages.

And there’s an interesting hybrid path: many frameworks now work well with web components. You can introduce custom elements gradually into an existing React or Vue application. You can wrap web components in framework-specific bindings. Migration can be incremental rather than revolutionary.

Getting Started Today

The path to building with web components is surprisingly short:

  1. Build a simple component. Something with a template, maybe an attribute or two. See how it mounts to the DOM.

  2. Add interactivity. Handle events within the component. Update the DOM in response. Experience the directness of working without virtual DOM abstraction.

  3. Implement communication. Have one component dispatch a custom event. Have another listen for it. Feel how naturally the event system handles component coordination.

  4. Encapsulate with shadow DOM. Add scoped styles. Use slots for composition. Appreciate how encapsulation simplifies your mental model.

  5. Iterate and expand. Build more components. Let AI help when you encounter unfamiliar territory. Learn the lifecycle callbacks as you need them.

Each step teaches something useful. Each component you build adds to your understanding. And unlike framework knowledge that might become obsolete, your understanding of the web platform will compound for years.

The Renaissance Is Here

We’re in an interesting moment. The platform has caught up to — and in some ways surpassed — the capabilities that made frameworks essential a decade ago. The tooling exists. The browser support is universal. The patterns are well-documented.

"The future of web development might look more like its past: standards-based, interoperable, and built to last."

What’s been missing is momentum. Developers gravitate toward what’s popular, and frameworks have dominated mindshare for so long that many never seriously evaluated the alternative.

But trends shift. The JavaScript ecosystem’s complexity has become a recognized problem. The appeal of simpler, more stable foundations grows as developers tire of churn. AI assistants make learning new approaches faster and less intimidating.

Web components offer something valuable: a way to build modern, sophisticated interfaces with technology that will still work decades from now. For developers willing to explore beyond the framework mainstream, there’s a quieter, more elegant path waiting.

The tools are ready. The browsers are ready. Perhaps it’s time to rediscover what the web platform can do.

📅 Remind me to explore more


Read the original article

mpweiher

Karma: 57735
...
 @Hacker__News
@hacker._news

Comments

  • By balloob 2026-02-2012:286 reply

    Home Assistant [1] has been written using web components and it has been great. In 13 years that we've been around, we never had to do a full rewrite of the frontend but always have been able to gradually update components as needed. Not being tied to the JavaScript industry upgrade cycle (which is short!), has allowed us to pick our own priorities.

    We currently use Lit for the framework on top (you do need one, that's fine). For state management we just pass props around, works great and allows community to easily develop custom cards that can plug into our frontend.

    The downside is lack of available components. Although we're not tied to a single framework, and can pick any web component framework, the choices are somewhat limited. We're currently on material components and migrating some to Shoelace.

    I talked more about our approach to frontend last year at the Syntax podcast[2].

    [1] https://www.home-assistant.io [2] https://syntax.fm/show/880/creator-of-home-assistant-web-com...

    • By catskull 2026-02-2021:251 reply

      I've written quite a few web components that were more or less standalone. I've looked at lit quite a bit but never fully understood the "why". Could someone share their own personal experience with why they needed lit? What does it offer that can't be done with standard spec web components?

      For me, a big draw of web components is that there's no `npm install` needed. I prefer to ship my components as plain JS files that can either be hot linked from a CDN or downloaded and served locally. Call me paranoid but I just don't fully trust node modules to be clean of bloat and spyware and I just don't want to have to regularly deal with updating them. I'd prefer to download a web component's static JS file a single time, read through it, and forget it. Maybe down the line I might revisit the source for the component as part of standard maintenance.

      For example, I made a simple like button component[1]. Later, my friend made a cool component for showing a burst of emoji confetti[2]. I decided to optionally pull it in if an attribute was set on the like component. I downloaded his source and hosted from my own domain. However, there was actually a bug in his code that caused the confetti to "rain" if you spammed the like button a few times quickly. He fixed that, but I actually kind of liked it so I just didn't update the source for the confetti component.

      [1]: https://catskull.net/likes [2]: https://github.com/samwarnick/confetti-drop

      • By troupo 2026-02-219:28

        > I've looked at lit quite a bit but never fully understood the "why".

        Because people don't want to write hundreds of lines of useless boilerplate by hand.

        Web Components API is verbose enough that you want to handle it with at least some abstraction. And at one point it was explicitly marketed as aimed at library/framework developers.

    • By zackify 2026-02-2015:163 reply

      The cycle isn't short like people continue to say each year. I use react since 2014 and it hasn't changed much in 6-7 years.

      I just built a script tag based reusable library for our company with react as the only dependency and thanks to stuff like shadow Dom and dialogs I get a much higher quality dev experience than plain js.

      • By afavour 2026-02-2015:244 reply

        Best practises have changed dramatically in React since 2014 though. It’s easy to say “oh you don’t have to use hooks, you can keep using class components” but that’s not really true when the entire ecosystem is pivoting.

        My bigger problem with React is that it ends up being used as a form of vendor lock in. Once your entire page is in the React VDOM it’s very, very difficult to pivot to a different framework piece by piece. That’s a core strength of web components.

        • By sheept 2026-02-2017:36

          Class components still work, and you can still use function components with hooks inside class components and vice versa.

          In the parent comment's case of not having other dependencies, whatever the React ecosystem does isn't relevant if you aren't using any React libraries, which aren't really necessary anyways, especially nowadays when the LLM can reimplement what you need for you.

          Nothing has changed about react-dom that prevents you from using React piece by piece—its docs still recommend attaching to a #root node even for single page apps.

          Including web components in a React app is very seamless, and embedding non-React-controlled elements inside React is not uncommon (e.g. canvas, Monaco, maps), though for common use cases there's usually convenience libraries for React that wrap around these.

        • By hliyan 2026-02-2016:211 reply

          I think React originally started with the opposite intent: a library where you can mount a component onto selected elements of the web page. The lock in only happened when React was used to develop SPAs, which effectively meant that React takes over the document root. With that came state management, and frameworks that managed the complexity of state were not far behind.

          • By mickeyp 2026-02-2017:33

            Indeed. I've gradually adapted a server rendered jquery and HTML site to react by making react render a component here and there in react and gradually convert the site. Works great.

        • By harrall 2026-02-2018:40

          React state management has changed a lot.

          React DOM/views have not significantly changed in 12 years.

          Our 10 year React projects that used mobx have not changed very much.

          Savage take: I found React when it came out and I thought “wow you made this gorgeous DOM library and then you bolted on this messy ugly wart for state.” Then hooks came out and I’m like… this is a good electrician pretending they can also do plumbing.

        • By colordrops 2026-02-2017:531 reply

          it's also impossible to look at the DOM and figure out what the hell is going on with React.

          • By llbbdd 2026-02-2020:411 reply

            React has excellent dev tools of its own that cover this.

            • By colordrops 2026-02-2021:391 reply

              I have those dev tools installed. I wouldn't call them "excellent".

              • By llbbdd 2026-02-2022:14

                Agreed I might have gone too far with "excellent". :) I think they do a good job though at operating at the level of abstraction React lives at, which generally requires less detail to live in the DOM (e.g. ids/classes used only for JS bindings compared to classic jQuery soup).

      • By socalgal2 2026-02-2019:321 reply

        I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.

        To be clear, it's not 100% react. It's the entire ecosystem around it. Want to take wigdet-x v3 for bug fixes. It requires newer react, which may or may not be compatible with widget-z I'm using. Newer react requires newer tools which aren't compatible with the configuration that was created by create-react-app from 2 versions ago. etc...

        • By nextaccountic 2026-02-2019:431 reply

          > I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.

          That's what AI is for. It makes previously unfeasible projects feasible again

          • By socalgal2 2026-02-2020:311 reply

            I thought so too but it failed for me. Maybe I'll try again

            • By jshen 2026-02-2020:51

              What model did you use? Curious if something like Opus 4.6 does a better job.

      • By megaman821 2026-02-2017:381 reply

        Exactly what are you using in React land that has lasted for 6-7 years. No components to hooks transition? No styling library changes? No state management changes? No meta framework changes? The React ecosystem is the least stable thing I have ever worked with.

        • By nayroclade 2026-02-2017:421 reply

          Hooks were introduced in 2019. so, seven years ago.

          • By megaman821 2026-02-2017:561 reply

            Even only looking at React provided hooks, they added a lot over years and best practices around things like useEffect have changed a lot.

            If you have a complex app from 2019 that you haven't updated, it is virtually guaranteed that it has memory leaks and bugs.

            • By c-hendricks 2026-02-2019:041 reply

              I don't really agree that "best practices around useEffect have changed a lot". It's more that that particular hook was used a lot when it didn't need to be so the team finally wrote some guidelines.

              • By zackify 2026-02-2221:42

                yeah same... i have always tried to useState and minimal effects, those have not really changed in 7 years

    • By shafyy 2026-02-2013:09

      Hey, cool to see you here on HN. I was recently looking through your codebase to see how you handle automations. It looks like you are relying on asyncio? I was wondering how you came to this decision and if you ever considered alternatives like a APScheduler or any other job library?

    • By gitaarik 2026-02-218:49

      For state management, you might be interested in looking at Lit State. It's a very lightweight state management lib written specially for Lit, with the same mindset. With it you won't have to pass props everywhere all the time.

      https://github.com/gitaarik/lit-state

    • By troupo 2026-02-2018:001 reply

      > Not being tied to the JavaScript industry upgrade cycle (which is short!),

      > We currently use Lit for the framework on top

      These two are contradictory statements.

      1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer

      2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.

      > We're currently on material components and migrating some to Shoelace.

      Again, this is exactly the "fast js churn" you're talking about.

      • By spankalee 2026-02-2020:121 reply

        Lit is fully compatible with Polymer (and any other web components).

        • By troupo 2026-02-2022:101 reply

          The output of lit is.

          Not lit.

          Stop pretending this isn't the case

          • By spankalee 2026-02-2022:411 reply

            I can't even tell what you're arguing.

            Lit helps you write web components.

            Those web components are interoperable with other web components made with Polymer, Stencil, FAST, etc...

            • By troupo 2026-02-213:441 reply

              [flagged]

              • By spankalee 2026-02-215:031 reply

                I still don't know what you're arguing.

                Is it that Lit gives you a different way of authoring web components than the raw APIs? Yes, that's entirely the point. It's a library that gives you better ergonomics.

                Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.

                • By troupo 2026-02-215:121 reply

                  > Is it that Lit gives you a different way of authoring web components than the raw APIs?

                  than the raw APIs, than Polymer, than Stencil, than...

                  > Is it that from the outside the components aren't "Lit", but consumed as standard web components? Again, yes, that's entirely the point.

                  No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"

                  Again, at this point I literally couldn't care less for your obstinate willful avoidance of authoring, and of your pretending that only the output matters. (And other lies like "lit is native/just html" etc.)

                  • By spankalee 2026-02-216:291 reply

                    > than the raw APIs, than Polymer, than Stencil, than...

                    Yes, and? Those are all different opinions and options on how to author web components.

                    > No. That is literally not the point. Which is extremely obvious from what I wrote in my original comment: "lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer"

                    It's extremely hard to tell what your point is. Lit's newer than React? Yes. Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components. We have customers do this all the time.

                    I don't avoid authoring, authoring is the main point of these libraries. And what you build is just web components. That's like... the whole idea.

                    Can you even communicate what this complaint actually is?

                    • By troupo 2026-02-219:21

                      > Lit started as an alternative to Polymer? Yes. Lit is "fully backwards incompatible [with] Polymer"? No, Lit and Polymer work just fine together because they both make web components.

                      Keyword: make.

                      Again: you keep pretending that authoring web components is an insignoficant part of what people do.

                      At this point I am fully disinterested in your pretence.

                      > I don't avoid authoring, authoring is the main point of these libraries.

                      Yes yes. When authoring web components Polymer is fully compatible with lit.

                      (Funny when even lit's own channgelogs talk about backward incompatible breaking changes between versions, but sure, sure, Polymer you can just drop into the authoring flow, and everything will work lol).

                      But as I said, I am completely disinterested in web component salesmen at this point.

                      Adieu.

    • By bflesch 2026-02-2016:47

      > Home Assistant [1] has been written using web components and it has been great.

      That could explain why the percentage slider is not showing a current value tooltip when sliding it :P

  • By unlog 2026-02-2012:339 reply

    Getting tired of their framework-free narrative.

    What they are doing is backing in the browser, via specifications and proposals to the platform, their ideas of a framework. They are using their influence in browser makers to get away in implementing all of this experiments.

    Web Components are presented as a solution, when a solution for glitch-free-UI is a collaboration of the mechanics of state and presentation.

    Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.

    Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.

    On the other hand, you have the Web Component Group, and they wont listen, they claim you are free to participate only to be shushed away by they agreeing to disagree with you and basically dictating their view on how things should be by implementing it in the browser. Its a conflict of interest.

    This has the downside that affects everyone, even their non-users. Because articles like this sell it as a panacea, when in reality it so complex and makes so many assumptions that WC barely work with libraries and frameworks.

    • By afavour 2026-02-2015:271 reply

      > Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.

      You could say the same about the DOM itself. That’s why frameworks were created in the first place. The Custom Element API is complex. The DOM is complex. It’s just that we’re used to the latter and not the former.

    • By epolanski 2026-02-2014:172 reply

      I love web components, but the fact that there's plenty of shadow-dom piercing properties defeats their purpose of "author them once, reuse them in different applications".

      One very common pitfall I encounter is the html's own base font size, since it impacts all the calculations in your webcomponents. Use a webcomponent with a font size of 12/14/16 and you get completely different behavior.

      If they were truly isolated they would really scale, but they don't.

      • By catapart 2026-02-2014:48

        Not to nag, but this seems like a design error? WC font settings should be inherited and relative, rather than any specific pixel size. Designs should be robust enough to support overflowing text, should the user increase scale/zoom/etc.

        Admittedly, I might not be understanding your problem well enough, so sorry in advance if I've mischaracterized the issue.

      • By jazzypants 2026-02-2014:501 reply

        Shouldn't you be using relative units like rem anyways?

        • By epolanski 2026-02-2016:131 reply

          Yes, which makes it very difficult to make stuff work okay cross application at changing of base font and user's zoom.

          • By DANmode 2026-02-210:43

            Yes. But does my target market even know how to change those things?

    • By DrScientist 2026-02-2013:583 reply

      Ideally, good ideas battle tested in various frameworks, would make it into the browser over time.

      For example with signals https://github.com/tc39/proposal-signals

      I agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing and perhaps the most valuable ideas ( custom elements and ES modules ), were those which did have the biggest precedence.

      > Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.

      This feels a bit deflective from the very real issue of in page framework interoperability - which is different from dev's taking to each other and sharing ideas.

      • By austin-cheney 2026-02-2014:061 reply

        What does battle tested really mean in numbers?

        When people say battle tested what they are really doing is looking for bias confirmation. Its no different than when they say software becomes more durable due to community validation.

        The only way to be sure is to actually measure things, with numbers, and then compare those numbers to some established baseline. Otherwise its just a guess. The more confident the guess becomes the less probable from the average it becomes. This is how rats out perform humans in weighted accuracy tests in clinical trials.

        • By DrScientist 2026-02-2015:171 reply

          > What does battle tested really mean in numbers?

          Not sure what you mean - are you asking number of users, length of time etc?

          All I'm saying with this is that ideas which have actually been implemented, used and evolved, are much less likely to have rough edges than something that's never left a whiteboard or spec document. I wasn't expecting that to be controversial.

          This stuff is difficult - if I remember correctly the original web components vision was a completely self-contained package of everything - that didn't survive contact with reality - however the things like custom-elements, templating and ES modules are, in my view at least, very useful - and I'd argue they are also the things that had the most precedents - because they were solving real world problems.

          • By austin-cheney 2026-02-2015:391 reply

            That is an irrational comparison. There is no comparison between components and something imaginary or theoretical. The comparison is between components and not imposing components into the standards, which are both well known conditions.

            People don't need components. They want components because that is the convention familiar to them. This is how JavaScript got classes. Everybody knew it is a really bad idea to put that into the standards and that classes blow out complexity, but the noise was loud enough that they made it in for no utility reason.

            • By DrScientist 2026-02-2016:002 reply

              > People don't need components.

              The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.

              We can argue about whether components as proposed was the right solution, but are you arguing that templates, custom elements and modules have no utility?

              Templating, for example, has been implemented in one form or another countless times - the idea that people don't need that seems odd.

              Same goes for a js module system, same goes for hiding markup soup behind a custom element.

              • By troupo 2026-02-2017:341 reply

                > The idea that people don't want some sort of improved modularity, encapsulation, reusability, interop etc I think is wrong.

                And web components are an extremely shitty half-baked near-solution to any of those.

                • By DrScientist 2026-02-2017:481 reply

                  Still not sure what you are attacking - is it just custom-elements or does that include js modules etc?

                  • By troupo 2026-02-215:131 reply

                    We're in the discussion under an article about web components. So, web components. Which I literally explicitly called out in my comment.

                    • By DrScientist 2026-02-239:59

                      Hmm...

                      So what do you think web components are then?

                      There was an initial proposal called web components that comprised a whole slew of enabling technologies - like custom elements, like modules, templates etc. Some of the proposals never got implemented.

                      The closest single thing to web components is custom-elements ( with optional shadow dom and optional slots ).

                      So is that what you are objecting to?

              • By austin-cheney 2026-02-2018:001 reply

                That completely misses the point. You are mistaking your preference for some objective, though unmeasured, benefit.

                I could understand an argument from ignorance fallacy wherein your preference is superior to every other alternative because any alternative is unknown to you. But instead, you are saying there is only way one of doing things, components/modularity/templates, and this is the best of that one way's variations, which is just a straw man.

                You really aren't limited to doing this work the React way, or any framework way. If you want to continue doing it the React way then just continue to use React, which continues to evolve its own flavor.

                • By DrScientist 2026-02-2310:12

                  > But instead, you are saying there is only way one of doing things,

                  Nope. I did not say there is only one way of doing things. I asked you whether you really thought people didn't want improved modularity, encapsulation, reusability, interop.

                  For example without standardised modules you either had to choose one of several community module systems or live with poor modularity and encapsulation. And by standardising modules interop improves.

                  > If you want to continue doing it the React way then just continue to use React,

                  Only one of us is appearing to want to stop the way the other only likes to develop. If I want to use custom elements why all the anger?

      • By jazzypants 2026-02-2014:49

        You can interoperate between frameworks the same way you interoperate between web components-- with events and attributes.

      • By troupo 2026-02-2017:331 reply

        > agree that the original 4 parts of the web component spec ( custom elements, shadow dom, templates, modules ) had varying levels of battle testing

        What battle testing? Literally nothing in Web Components was ever battle-tested before release. You wouldn't need 20+ specs to paper over the holes in the design had they actually veen battle-tested.

        • By DrScientist 2026-02-2310:16

          Read my comment again. I literally said that various parts had various levels of precedents - and that the more successful parts were those with stronger precedents.

          > Literally nothing in Web Components was ever battle-tested before release.

          So you don't thing the ideas of modules or templates had had multiple precedents?

          Totally agree that some aspects had much less precedent - and that's why, in the end, they either didn't get implemented or haven't got much traction.

    • By spankalee 2026-02-2020:191 reply

      Web components are just a way for developers to build their own HTML elements. They're only a "framework" in as much as the browser is already a framework that wires together the built-in HTML elements.

      I don't see any reason to lock away the ability to make nodes that participate in the DOM tree to built-in components only. Every other GUI framework in the world allows developers to make their own nodes, why shouldn't the web?

      > too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.

      Do you have any concrete examples there? What "mechanics" are you referring to. Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.

      With your other specific complaints about the community, I think I can guess you are. That person come into our discord server, was so mean and rude to everyone that they had to be told by multiple people to chill out. Had one very specific proposal that when multiple people thought it was a bad idea, threw a fit and said we never listen. You can't just come into a place and behave badly and then blame the community for rejecting you.

      • By troupo 2026-02-215:151 reply

        > Do you have any concrete examples there? What "mechanics" are you referring to

        Try the 2022 Web Components Group Report. Including things like "most these issues come from Shadow DOM".

        > Given that very complex apps like Photoshop, Reddit, The Internet Archive, YouTube, The Microsoft App Store, Home Assistant, etc., are built with web components, that would make the claim that they're unusable seem silly.

        Trillion dollar corporations also build sites in Angular, or React, or Blazor, or...

        • By spankalee 2026-02-216:311 reply

          So you're saying that the web components community ignores the issues with web components by... writing a report on the issues with web components?

          I still don't know what "mechanics and assumptions" are baked according to the OP.

          • By troupo 2026-02-219:17

            So you're deflecting from the original point raised.

            Anyway, yes. Web Component "community" was fully and willfully ignoring most issues that people (especially framework authors) were talking about for years.

            At one point they managed to produce a single report (very suspiciously close to what people like Rich Harris had been talking about since at least three years prior for which he got nothing but vile and bile from main people in the "community"), and then it went nowhere.

            > I still don't know what "mechanics and assumptions" are baked according to the OP.

            Again: you do, people who wrote the report do, but you all keep pretending that all is sunshine and unicorns in the web component land.

            While the report very explicitly calls out a very major behaviour baked in, for example. And calls out a bunch of other issues with behaviours and mechanics. While web components need 20+ specs to barely fix just some of the assumptions and baked in mechanics (that literally nothing else needs, and most of which exist only due to web components themselves).

            Anyway, I know you will keep pretending and deflecting, so I stop my participation in this thread.

            Adieu.

    • By PaulHoule 2026-02-2013:271 reply

      We have been using the isolation stuff in Web Components to make React applications that our partners can embed in web pages regardless of what other CSS and JS they use. I don’t know if I’d want to make an application with 100 tiny web components at the level of individual buttons and such that work together but self-contained widgets that pop into a web page look great to me.

      • By psygn89 2026-02-2015:141 reply

        We basically tried wrapping an entire registration app into the Shadow DOM just for a hopeful kick but it came with weird accessibility quirks, arrow keys not always working to go through selections, and some overlays acting strangely. We were using Shadcn which is powered by Radix Primitives, however, and a setup they probably weren't expecting or testing their code to be in.

        But for smaller things like chat widgets or players I think it's a great solution.

        • By PaulHoule 2026-02-2015:27

          We had overlay problems with a fancy <Select> control, also systems like Emotion can have trouble, or anything that is portalized or computes coordinates for absolute positioning. We were able to fix all the ones that affected us.

          Funny we have been using the HTML <dialog> because you can't really pass accessibility reviews if you use the modal dialogs that come with MUI, Reactstrap, etc. Only <dialog> really inerts the whole page but you run into very similar problems getting components to work properly inside them which we were able to solve for all the components we use inside dialogs, but I think it's an absolute shame that this has not been adopted by MUI or anything I can find in npm -- what I hate about accessibility is that I feel like I'm held accountable and my organization is held accountable but not the people who write trash specs, make trash screen readers that crash my computer, vendors of React components, etc.

    • By wsatb 2026-02-2013:152 reply

      Wow, this is a weird a comment. Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks. Is the Illuminati behind this? I kid, but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable. It's quite a bit different than the fluidness of a JS framework.

      This discussion comes up all the time and I always have the same response: not everyone needs a full-on framework for what they're doing. They also may need to share that code with other teams using other frameworks or even third parties. The post even mentions that web components may not be a good fit for you.

      • By troupo 2026-02-2017:411 reply

        > Who are "they"? You sound like you think there's some giant conspiracy against JS frameworks.

        Yes. There is. The main developers and proselityzers were completely insanely biased against web frameworks (especially React).

        It wasn't even a conspiracy. All you had to do was to follow Alex Russel (the person who introduced the idea of web components in the first place) and see his interactions with framework authors and his views towards web frameworks.

        The new people in the space driving the specs are hardly any better. E.g. their reactions to Ryan Carniato's rather mild criticism of Web Components is just filled with vile, bile, and hate.

        They literally refuse to even admit they have a problem, or want to look at any other solutions than the ones they cook up.

        > but a browser feature is kind of what it is. It can take years for features to make it into enough browsers to make them usable.

        Strange, browsers push dozens of specs for web components without ever taking any time to see if the yet another half-baked "solution" is actually workable.

      • By austin-cheney 2026-02-2013:411 reply

        Its not a conspiracy. It is just group behavior following a trend as loudly as possible.

        • By wsatb 2026-02-2015:192 reply

          Web components are a trend? I've been using them for close to 10 years and they're still not anywhere close to mainstream. Loudly as possible? They've quietly just kind of been there for years.

          I think we have a generation of developers that only know React and they're so engrained with it they simply cannot imagine a world without it. If you really can't find a use case for web components then you're living in a bubble.

          • By austin-cheney 2026-02-2015:34

            We have been through all this before with jQuery. The generation of JavaScript developers at the beginning on React only knew jQuery and they really wanted to shoehorn all the jQuery nonsense into the standards. From their perspective it makes complete sense because that is the only one way to do things. They got querySelectors into the DOM.

            Now we are seeing the exact same thing again. People only know React, so they want the standards to look like the only one thing they know. That doesn't make it a good idea. Every time this comes up we exchange simplicity and performance for easiness and temporary emotional comfort. Its only a temporary win until the next generational trend comes along.

          • By troupo 2026-02-2017:461 reply

            > If you really can't find a use case for web components then you're living in a bubble.

            There's a very tiny use-case for web components. And even there it's riddled with a huge amount of potential (and actual) footguns that "in the bubble" devs have been talking about for a decade at this point, and some which were finally acknowledged: https://w3c.github.io/webcomponents-cg/2022.html (no updates since)

            • By wsatb 2026-02-2020:041 reply

              > There's a very tiny use-case for web components.

              That's weird, we've been using them at my company for a number of years and there's plenty of other examples of them being adopted elsewhere too. This continues to read as, "it's not React, so it's bad."

              • By troupo 2026-02-2110:50

                There are companies that still use jQuery, or Angular, or Ember, or vanilla JS, or Blazor, or...

                Just because tech exists and is usable doesn't mean it doesn't have a list of issues and footguns a mile long, some of which are explicitly recognized by the Web Components Working Group. And which still need 20+ various specs to paper over.

    • By don_searchcraft 2026-02-2015:50

      Agree. web components are not a 1 to 1 replacement for a component based framework. There was a lot of promise but the implementation is lacking.

    • By mock-possum 2026-02-2016:40

      > Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex.

      Does not line up with my experience (the past 8 years or so of working with native web components, Polymr and the Lit library) at all. You can build staggeringly complex views using nothing but web components, I’ve done it, I am doing it, and inshallah I will keep doing it.

      What in particular do you believe web components are unusable for? What do you count as crossing the line into ‘slight complexity?’

    • By le-mark 2026-02-2012:50

      Yes Microsoft DHTML and behaviors were this and represented tremendous lock-in. Plus, they were terrible. Those who don’t know their history are truly doomed to repeat it.

  • By mikebelanger 2026-02-2012:451 reply

    I lean towards vanilla javascript and webcomponents myself, and eschew large frameworks in favor of lighter, or in some cases, no framework at all.

    That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:

    1. Being "Framework-free"

    Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:

    "If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."

    In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.

    2. Webcomponents and the shadow DOM go together

    For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:

    https://enhance.dev/blog/posts/2023-11-10-head-toward-the-li...

    • By gedy 2026-02-2013:38

      > For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM

      Yeah this a thing that turns lots of people off from using and it's usually presented as "of course you want this". And it's a real practical limiter to using for normal apps (I get embedded standalone widgets)

HackerNews

About