[HN Gopher] Web Components: The Framework-Free Renaissance
___________________________________________________________________
Web Components: The Framework-Free Renaissance
Author : mpweiher
Score : 181 points
Date : 2026-02-20 08:45 UTC (14 hours ago)
(HTM) web link (www.caimito.net)
(TXT) w3m dump (www.caimito.net)
| foobarbecue wrote:
| I skimmed this. I use web components a lot. Unless I'm mistaken,
| they don't provide reactivity; you have to write that yourself.
| Reactivity was the feature that launched modern js frameworks so
| I think the article really overstates the case.
|
| The article also misses something more important: broad native ES
| module support in browsers means you don't need a build step
| (webpack).
|
| The "AI makes it easy!" part of the article makes me want to hurl
| as usual. And I'll stop short of an accusation but I will say
| there were some suspicious em dash comparison clauses in there.
| dankobgd wrote:
| you have `observedAttributes` and a callback to react whenever
| they change. That is basically it.
| desdenova wrote:
| You can use lit-html to get declarative reactivity, but then
| it's just basically react again.
| tym0 wrote:
| Do you still have to pass every args as json/strings or has
| there been an improvement on that front?
| lloydatkinson wrote:
| It's still exactly like that.
| balloob wrote:
| This has never been the case. Custom elements are DOM
| Elements and so are just JavaScript objects. Just like you
| can do aEl.disabled = true, you can set any prop to any type
| of value.
| gedy wrote:
| I think they mean in the markup via <some-tag
| data={anObject}> ala React, svelte, etc.
| lloydatkinson wrote:
| > they don't provide reactivity; you have to write that
| yourself. Reactivity was the feature that launched modern js
| frameworks so I think the article really overstates the case.
|
| This is the truth that a lot of web component advocates gloss
| over on purpose. They know this, just like they know that
| there's no decent templating solution either as tagged template
| literals still need escaping. Then there is efficient DOM
| updates, etc. (aside, I got Claude to write a web component
| recently, and it's code had every single keystroke assigning
| the same class to the element)
|
| There are many features like this, and when you finally get
| them to admit it, they just say "write your own"!. Well guess
| what, frameworks already provide all of this.
|
| The really funny part is that Stencil, one of the popular tools
| for writing web components actually _does_ provide all of the
| above! Their web components have exactly the same type of
| features you 'd expect in any other framework *because it IS a
| framework*.
|
| Which again highlights how stupid the discourse is here. It's
| not "independence" of frameworks, your components will still
| depend on a framework of some kind, be that Stencil or Lit or
| whichever thing YouTube uses now or your own supporting code to
| get back even half the features you get elsewhere.
|
| It all starts to make sense when you realise that the Chrome
| developers hated frameworks because they didn't understand
| them, pushed for web components, not realising frameworks dealt
| with all of the above.
|
| https://youtu.be/UrS61kn4gKI?t=1921 32:00 (but the whole video
| is valuable and I wish everyone on both sides of this debate
| would watch the whole thing).
|
| I think the only thing I like about web components is they
| scope "this" to the element it owns.
| lloydatkinson wrote:
| Not that votes matter on HN, but I do find it typical of the
| type of discourse around Web Components I dislike. My comment
| had +3, now it has 0. It seems no one is able to admit WC's
| have big problems.
| g947o wrote:
| Yes. You can tell the author either doesn't have experience
| using web components in a non trivial page, or they are
| intentionally hiding the complexity. Realistically, you don't
| want to make pure web components. You want to use a framework
| to build it for you.
|
| Put it another way, you can make a page out of web components
| without using a framework, but you are not going to convert a
| React page with that approach.
| dankobgd wrote:
| I just wish declarative shadow dom had bit better support or
| declarative custom elements landed already. Problem is that now i
| have to duplicate the template part, instead of just declaring it
| once and then specifying component instances many times.
| cube00 wrote:
| _The question is no longer whether they work, but why more
| developers haven't embraced them._
|
| Anytime it's attempted, someone tries to scare them into thinking
| that their code will impossible to maintain without a framework
| to provide "structure"
| LtWorf wrote:
| I see it a lot with people who ask for help about learning
| python.
|
| According to the people "helping" them, before writing any line
| of code you should learn about ruff, uv, pip, venv, black,
| isort and so on... I guess most people aren't good at imagining
| other situations than their present one.
| whizzter wrote:
| Because people are discussing different things.
|
| We need to talk more about pages vs applications, web compnents
| are an excellent choice for making pages more maintainable, but
| without support for somehow automating translion of internal
| state (often data in a machine suitable format produced by an
| API) to visual state (for human consumption where said data
| might be scattered or otherwise recomputed) then you do run
| into the "maintainability" issues as soon as the visual state
| needs to be updated by user updates to the more machine near
| data model.
| smashah wrote:
| I used to write all my webapps in pure lit webcomponents but
| eventually moved onto react
| hiccuphippo wrote:
| Can you explain what made you move? I'm about to start a
| project and was looking at lit to do it.
| smashah wrote:
| I was a huge webcomponents evangelist and tbh i wanted to
| vomit for the first few months of react just based on the
| fact how antithetical to web standards it is. But I wasn't
| able to pay the bills with lit work. And now the react
| ecosystem is much more comprehensive even compared to the
| polymer/bower days. I'm happy I did webcomponents and can go
| back to it if I need anything significantly lightweight.
| arianvanp wrote:
| I tried Web Components to create a `<passkey>` element to allow
| Passkey support in forms without having to write javascript as an
| end-user.
|
| I ran into https://github.com/WICG/webcomponents/issues/814
|
| As long as this is not fixed I can't take Web Components
| seriously.
| cpburns2009 wrote:
| Why would you want your face to submit a form? How could it
| even be selected by default? Is this an April Fools joke?
| arianvanp wrote:
| Say you want to have a custom button element. You cant give
| it a `type=submit` whilst you can set that on <input> and
| <button>
|
| Also if you have a face that wraps a button of type submit.
| The submit doesn't propagate due to shadow dom
| cpburns2009 wrote:
| Does "face" have some sort of special meaning in this
| context? I thought it might be related an open web
| implementation of Face ID.
| vazark wrote:
| The biggest issue is the lack of tooling and the inability to
| manage a shared state. We actually ended up creating new
| libraries like Stencil & Lit.
|
| Custom Elements missed the mark with the problem frameworks
| solve. We don't necessarily need custom HTML, we needed easy way
| to build and manage the whole data and visual flow locally while
| treating the backend response as a datasource.
|
| Nowadays, I use web components for one-off, isolated components
| as a replacement for iframes, but rarely for anything complex.
| whizzter wrote:
| This so much, automatic "data struture state -> visual state"
| without manual synchronization code to update the visual state
| is the main reason why frameworks are useful, not for
| components.
|
| BUT, these frameworks are most useful for actual
| "applications". So much of web development is "merely" focused
| on making beautiful "pages", and a framework can very well be
| overkill in those scenarios.
|
| People "going back to basics" really need to learn to evaluate
| when what you are doing (or how much) falls into each camp.
| crassus_ed wrote:
| I have heaps of experience with Stencil and it works great
| until a certain size indeed. It is a great way to ship web
| components quickly.
|
| Coding agents will allow us to write plain JS way more quickly
| but it still takes a bit more time by humans to read compared
| to reading something that was written with in a framework.
|
| Until the day that I don't have to do reviews of my AI
| generated code, or some sort of pseudocode abstraction layer
| becomes available, I think there is still a place for
| frameworks and libraries to create web components like Stencil.
| _heimdall wrote:
| The shadow DOM and all the encapsulated CSS shenanigans it comes
| with has get to win me over. I do reach for custom elements quite
| often though.
|
| A lot of times I just need a small component with state simple
| enough that it can live in the DOM. Custom elements gives me
| lifecycle hooks which is often all I really need for a basic
| component.
| lelandfe wrote:
| It's not actually in some capsule separate from the page,
| though. CSS variables leak in to it from the "light"/regular
| DOM. You can query elements in it from the host with
| `shadowRoot.querySelector()`.
|
| The elements also inherit styles from parents: https://open-
| wc.org/guides/knowledge/styling/styles-piercing...
|
| You can do a closed root but last I checked that had profound
| accessibility issues.
|
| (As an aside this is why the linked article is incorrect in
| saying this: "global styles don't leak in (unless you
| explicitly allow them).")
| marcosdumay wrote:
| > CSS variables leak in to it from the "light"/regular DOM.
|
| > You can query elements in it from the host with
| `shadowRoot.querySelector()`.
|
| > The elements also inherit styles from parents
|
| Why do people keep talking about those things as if they were
| problems?
| lelandfe wrote:
| They ain't! Long live the cascade!
|
| But when the desired outcome is "complete separation from
| the surrounding page," those are pretty serious problems!
| WorldMaker wrote:
| I'm certainly feeling like Shadow DOM is the new iframe and
| mostly useful for ad networks and "embeds" which are not things
| I'm generally building with Web Components. It's interesting
| how many developers seem enamored with Shadow DOM, but for me
| the sweet spot is keeping all of a Web Component in the "Light"
| DOM, let CSS do its cascading job, and let my Web Component
| adapt to the page hosting it rather than be a lonely island of
| its own style.
| lbreakjai wrote:
| > A component deep in your UI hierarchy can dispatch an event
| that bubbles up through the DOM tree
|
| Sounds like people are about to rediscover why Redux came to be.
| spankalee wrote:
| Redux really should have just been events up and new data down.
| KostblLb wrote:
| i think now with signals proposal to new ecmascript, one can
| easily have both web components and reactivity. my main question
| is, which tool do you use to have normal html syntax highlighting
| inside web components?
| WorldMaker wrote:
| Personally, I'm still using JSX/TSX to template my Web
| Components. (I'm not using React, I'm using the non-Virtual DOM
| approach with Butterfloat [1], but there are other small JSX
| template language options like Preact and snabbdom out there as
| well and also other non-Virtual DOM approaches.)
|
| I like the type safety of TSX as well as the syntax
| highlighting. (As may be obvious with Butterfloat, I also
| prefer the power of RxJS over signals, but that's a longer
| conversation.)
|
| [1] https://worldmaker.net/butterfloat/
| hackrmn wrote:
| Every time Web Components is being fronted, one has to duly
| inform the reader that Apple _rightfully_ refuses to implement
| what in my humble opinion is at least one broken piece of the
| specification that if implemented -- and it is implemented
| faithfully by Chrome and Firefox browsers -- in principle breaks
| the Liskov's Substitution Principle: *
| https://lists.w3.org/Archives/Public/public-webapps/2013OctD... *
| https://lists.w3.org/Archives/Public/public-webapps/2016JanM...
| To be fair, this only concerns so-called "custom elements" that
| need inheriting existing HTML element functionality, but the
| refusal is well explained IMO. Meanwhile everyone else is just
| chugging along, like it tends to happen on the Web (e.g. History
| API giving way to Navigation API that in large part was designed
| to supercede the former).
|
| To all of the above I might add that without "custom elements"
| Web Components is severely crippled as a feature. If I want to
| sub-class existing functionality, say a `table` or `details`,
| composition is the only means to do it, which in the best style
| on the Web, produces a lot of extra code noone wants to read. I
| suppose minimisation is supposed to eliminate the need to read
| JavaScript code, and 99% of every website out there features
| absolutely unreadable slop of spaghetti code that wouldn't pass
| paid review in hell. With Web Components that don't implement
| "custom elements" (e.g. in Safari) it's a essentially an OOP
| science professor's toy or totem. And since professors like their
| OOP theory, they should indeed take Liskov's principle to heart
| -- meaning the spec. is botched in part.
| ernsheong wrote:
| I'm an early fan (Polymer, anyone?) but somehow the mindshare is
| just not there and trying to evangelize it to mainstream was too
| much. So now it just kinda there for people to slowly discover
| when they run into niche use cases.
| lukax wrote:
| Wow, XSS just waiting to happen.
| <h3>${this.getAttribute('title')}</h3>
| benatkin wrote:
| It looks similar to Lit code, but it's not Lit, so yes, it is
| XSS waiting to happen all right. If it were Lit it would be
| escaped. It would start with html` which evaluates to a
| TemplateResult and the render() function only accepts a
| TemplateResult.
| teg4n_ wrote:
| How? If the attribute is not trusted doesn't that mean the dom
| is already compromised?
| balloob wrote:
| 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...
| shafyy wrote:
| 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?
| zackify wrote:
| 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.
| afavour wrote:
| 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.
| hliyan wrote:
| 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.
| mickeyp wrote:
| 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.
| sheept wrote:
| 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.
| colordrops wrote:
| it's also impossible to look at the DOM and figure out what
| the hell is going on with React.
| llbbdd wrote:
| React has excellent dev tools of its own that cover this.
| colordrops wrote:
| I have those dev tools installed. I wouldn't call them
| "excellent".
| llbbdd wrote:
| 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).
| harrall wrote:
| 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.
| megaman821 wrote:
| 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.
| nayroclade wrote:
| Hooks were introduced in 2019. so, seven years ago.
| megaman821 wrote:
| 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.
| c-hendricks wrote:
| 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.
| socalgal2 wrote:
| 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...
| nextaccountic wrote:
| > 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
| socalgal2 wrote:
| I thought so too but it failed for me. Maybe I'll try
| again
| jshen wrote:
| What model did you use? Curious if something like Opus
| 4.6 does a better job.
| bflesch wrote:
| > 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
| troupo wrote:
| > 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.
| spankalee wrote:
| Lit is fully compatible with Polymer (and any other web
| components).
| troupo wrote:
| _The output_ of lit is.
|
| _Not_ lit.
|
| Stop pretending this isn't the case
| spankalee wrote:
| 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...
| catskull wrote:
| 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
| unlog wrote:
| 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.
| le-mark wrote:
| 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.
| wsatb wrote:
| 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.
| austin-cheney wrote:
| Its not a conspiracy. It is just group behavior following a
| trend as loudly as possible.
| wsatb wrote:
| 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.
| austin-cheney wrote:
| 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.
| troupo wrote:
| > 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)
| wsatb wrote:
| > 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."
| troupo wrote:
| > 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.
| wk_end wrote:
| Some links to examples of the sort of behaviour you're
| describing would be really helpful here (I say this as
| someone who is sympathetic - I work with on a web
| component/Lit codebase in my 9-5 and I'm not a fan,
| compared to the React workflow I had in a past life).
| PaulHoule wrote:
| 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.
| psygn89 wrote:
| 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.
| PaulHoule wrote:
| 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.
| DrScientist wrote:
| 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.
| austin-cheney wrote:
| 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.
| DrScientist wrote:
| > 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.
| austin-cheney wrote:
| 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.
| DrScientist wrote:
| > 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.
| troupo wrote:
| > 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.
| DrScientist wrote:
| Still not sure what you are attacking - is it just
| custom-elements or does that include js modules etc?
| austin-cheney wrote:
| 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.
| jazzypants wrote:
| You can interoperate between frameworks the same way you
| interoperate between web components-- with events and
| attributes.
| troupo wrote:
| > 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.
| epolanski wrote:
| 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.
| catapart wrote:
| 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.
| jazzypants wrote:
| Shouldn't you be using relative units like rem anyways?
| epolanski wrote:
| Yes, which makes it very difficult to make stuff work okay
| cross application at changing of base font and user's zoom.
| afavour wrote:
| > 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.
| don_searchcraft wrote:
| 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.
| mock-possum wrote:
| > 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?'
| spankalee wrote:
| 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.
| g947o wrote:
| Frameworks provide real value, and one will likely end up using a
| framework like Lit. As soon as your page logic gets complex
| enough, you'll need many little things to make it work, and
| eventually a framework is what you want.
|
| (Ignore me if all you do is readonly pages with no state
| transition)
| akst wrote:
| As someone who spent the last year messing around with web
| components, I think there's some cool stuff there but I have a
| new level of appreciation for actual components APIs from actual
| frameworks.
|
| It's more a custom element API than a component API, I mean that
| line in the sand is pretty subjective, but I just can't see this
| API being a part of any major web framework, I can see that with
| shadow dom, I can't see that with the whole
| customElement.register and garbage you have to do in the
| constructor.
|
| Also the goals of this API are just not aligned with the purpose
| of a framework/component system. I do encourage people to play
| around with them but it's really annoying to hear how they're
| being promoted they're are a lot less exciting than the platform
| advocates are willing to admit but that doesn't mean they are
| useless but we need up stop pretending they're the future of web
| applications.
|
| Frameworks are often designed with the goal of managing
| application complexity without being overwhelmed by the
| shortcomings of the platforms. Web Components have done little to
| reduce the need for such a thing.
| mikebelanger wrote:
| 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...
| gedy wrote:
| > 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)
| catapart wrote:
| I love web components and, for the past few years, I've been
| building a simple demo app that is, itself, a web component[0].
| The main problem I've found with web components is the ecosystem.
| The reason 1000 different devs can make react/svelte/vue
| components that all work together (obviously with some
| exceptions) is because they have the framework as a basis. If you
| want to use pure web components, you can't rely on a framework
| for any kind of architectural certainty. You're at the whim of
| what the other dev needed when they built the component.
|
| And I don't find that bad for web components, as a whole, but if
| you wanted to build an app, you would most likely just use a web
| component framework (something that uses a base component and
| extends the rest from it), in which case you're limited to what
| that framework provides (and it won't be as robust as any non-wc
| framework). But if you're just looking to quickly slap in a
| component that "just works", you would have to do some real
| diligence to make sure it would fit which just is _not_ a problem
| for any defined framework.
|
| My approach has been to make a complete suite of CC0 components
| (which also meant no dependencies that I didn't write myself, so
| that I could make each dependency CC0, too), and let each
| component be an entirely standalone library, so that you could
| treat them like drop-in new html elements, rather than libraries
| to ingest and work with (in effect, the component should be as
| self-sufficient as an <input> or a <select> and require no js
| interaction from the consumer to work; just add the script and
| use the new tag). Of course, the major downside of that is that
| each component has to be it's own library which needs competent
| documentation (at least, _I 'm_ not going to remember how 15-20
| different components all work in fine detail. I want some docs
| _and_ examples!), and no other dev has any way of knowing that
| these components won 't require an additional "base" script or
| component to work.
|
| Overall, though, I'm happy with the results I've got (just
| finishing up all that documentation, at this point). And I
| definitely don't mind things like web components "not having
| reactivity" or "state", because I, personally, don't like being
| forced to push every piece of data through the rube-goldbergian
| plinko machine of reactive state. Different paradigms for
| different purposes and all that. So between not being forced to
| use it and having the events and attribute observation to be able
| to use it when I want it, I'm pretty satisfied with the state of
| web components on that front.
|
| Honestly, the biggest issue I have with web components is how
| they work with "parts". I had to write a whole little library to
| make working with parts reliably comfortable for both library dev
| and consumer devs. I'd love a way to query on the "part"
| attributes, while within the component's shadow dom. As it
| stands, the best you can do is `[part="my-part"]`, which has
| obvious shortcomings if you're trying to use it like a class.
| Multi-classed elements are easy to select; doing anything
| complicated with part selectors would quickly spiral into a lot
| of `[part*="red"]:not([part*="redorange"])`, instead of `.red`,
| or whatever. The light dom is better because the ::part()
| selector treats parts like classes, so you can write selectors
| like class selectors. But, of course, you're limited to the part
| itself, so every single thing that should be stylable (in a lot
| of components, every single element; implementing devs should
| control style and display layout, just not functional layout)
| needs to have a part. And that's still a fairly superficial
| problem compared to the issue of not being able to automatically
| convert all "part" attributes into an "exportparts" value for the
| parent element. Again, not something that most libraries will
| need, but when you do need it, it's crazy that I would have to
| make a porting solution, myself. That's just begging for errors.
|
| In any case, I generally agree with most of what the article has
| to say. As others have pointed out, some of the examples aren't
| really "best practices", but the overall point that web
| components are perfectly capable of building with is a solid one.
| I do still think that the old adage holds true, though: 'if you
| don't use a framework, you'll build one'.
|
| [0] https://github.com/catapart/magnit-ceapp-taskboard-manager
|
| ( _Notes for the demo pages: not production ready; the component
| will write to an indexedDB instance in your browser; the pages
| will add to your browser history [an option that is currently on,
| but is not the default config of the component];_ )
| pjaoko wrote:
| > in which case you're limited to what that framework provides
| (and it won't be as robust as any non-wc framework).
|
| Is there something inherently wrong with wc that stops robust
| frameworks being built on top of it? Have you tried actual
| framworks built on wc like Lit for example.
| catapart wrote:
| No, I'm saying that if you use a non-wc framework, it will be
| more robust than any wc framework. Not because it's non-wc,
| but because it's more mature. Lit is mature, but it's not
| _more_ mature than React, and it definitely has less
| contribution to it than react.
|
| It's definitely possible to make a _comprehensive_ web
| component library. Something that could compete with React.
| But, as far as I know, it doesn 't currently exist (and would
| be a huge task to achieve with... no discernible reason to do
| it?).
| ChrisChou wrote:
| Web components are already very mature. I have used them to
| develop a desktop and mobile note-taking application called
| Simark, which is available on the Apple App Store. If you are
| interested, you can download it and take a look. It has zero UI
| framework and is 100% web components.
| mediumsmart wrote:
| I have 3 web components working inside the body frame - rectangle
| with text, with image or blank, been using that since the
| Renaissance.
| skrebbel wrote:
| Web Components are amazing for distributing frontend libraries.
| But they're awful as building blocks to replace a framework like
| React, Vue, Svelte or Lit with.
|
| I blame the Chrome people for the misleading naming. The entire
| term "Web Components" is ridiculous. If only they'd stuck with
| the technical term, "custom elements", then none of this
| confusion would've happened. It's pretty obvious to me that
| custom elements are a great idea for distribution (add a script
| tag, poof, magic new HTML element exists!), but the term doesn't
| imply anything about how to best build the internals of your app.
|
| Thing is, Web Components are a needlessly painful abstraction.
| There's properties and attributes, they're kinda sorta the same
| but not really and you gotta sync them up manually, the naming is
| global so you get zero modularity, really it's all a mess. And at
| the same time, you get no support at all for things like props
| handling, event calling, data binding; none of the stuff
| frameworks give you.
|
| But Web Components are also what enabled my company to distribute
| a single UI library that works with all web frameworks. It's a
| _fantastic_ technology for that.
|
| tldr: - distributing UI components: web
| components - building an app: just pick a framework
| already
| Garlef wrote:
| When presented with a choice, I'd prefer to pick something where
| I know that the sky is the limit in terms of features.
|
| And going with a non-framework approach has the following risk:
| Of course I might build individual, customized skyscrapers but as
| soon as I'd like to connect them, I'm in the business of building
| an ad-hoc framework.
| dnlzro wrote:
| Web Components are a great way to implement things that the
| browser should have already implemented, like accordions, combo
| boxes, and date pickers that don't suck. It's been a pleasure to
| use them in a mostly static, content-heavy Astro site.
|
| But beyond that, they're not really usable without a framework
| that can deal with state and reactivity across a whole
| application. And that's fine! They fill a good niche. But just
| because the browser provides an API doesn't mean it should be
| used whenever possible.
| WorldMaker wrote:
| Accordions: just use `<details name="accordion-name">` and
| style it however you like. No need for JS or Web Components any
| more for an accordion.
|
| Combo Boxes and Date Pickers: CSS Form Control Styling Level 1
| [1] will be a massive game changer. `appearance: base` will
| make it easier to style every part of a browser's form input
| with just CSS as they start with fewer opinions on how it
| should be styled (less trying to be platform-specific, more web
| platform generic) and have more CSS selectors for their
| component parts. Yet they will still have all the accessibility
| of native form controls. Really hoping that draft moves forward
| this year.
|
| [1] https://www.w3.org/TR/css-forms-1/
| dnlzro wrote:
| I didn't know about the `name` attribute on `<details>`,
| thanks for pointing that out!
|
| Stylable form controls are definitely a step in the right
| direction. It really should not be taking this long though.
| In the meantime, developers have been building broken, half-
| assed, inaccessible inputs just to satisfy aesthetic
| requirements.
| sandreas wrote:
| I think lit[1] is a good compromise between vanilla and framework
| bloat. It IS a dependency but a very lightweight and useful one.
| And it can act as a layer in between whenever requirind a
| specific framework.
|
| 1: https://lit.dev/
| chuckadams wrote:
| The thing I enjoy the most about writing UIs with Vue 3 is that
| I'm not forced into JavaScript's insane OOP mechanics, and can
| use plain old functions without concerning myself with
| incantations like `this.foo.bind(this)`. Web Components embrace
| JS's OO system whole-hog, and well, they can keep it. I'm also
| not too big on having to deal with things like "shadow DOM",
| which to me seems like the kind of implementation detail
| frameworks are supposed to abstract away in the first place.
|
| Web Components seem a nice compilation target for other
| frameworks, but working with them directly is a hair shirt I'm
| still not willing to wear.
| chknkachunga wrote:
| In my experience as a web component library builder, writing and
| maintaining web components is the easy part.
|
| Getting them to work well in various react and angular codebases
| is not easy. New versions of React work well with web components.
| Old version s of react need web component wrappers. Angular works
| out of the box with web components (aside from some quirks and
| sometimes encapsulation issues with the web components). However,
| web component form controls will not work with angular reactive
| form controls and require an implementation of the control value
| accessor interface. So if you're a web component form controls
| you need some kind of intermediary layer to play well with
| angular forms.
|
| Problems tend to surface with testing infrastructure as well,
| especially in older codebases running Jest or other jsdom based
| testing frameworks that don't recognize the web component apis
| well (shadowDOM, elementInternals, ect). Upgrading to vitest with
| browser mode can solve these problems, or writing lots of mocks.
| jezzamon wrote:
| Web components are a good tool for building literal components
| (buttons, sliders, etc). From experience, I can say they're not a
| great tool for building the higher level things you build in a
| typical web app. The output they produce ends up being such a
| painful mess of shadow dom everything that it makes using other
| tools with the website painful
| benterix wrote:
| While the topic of this article is interesting for me, the fact
| that it was output by an LLM by itself makes it less trustworthy
| than if a human wrote it, taking into account the disadvantages
| of both.
| singpolyma3 wrote:
| I don't understand takes like this. Web Components don't even
| compete with modern frameworks and solve totally different
| problems. Reactivity and data binding are not features of web
| Components that I have seen.
|
| If you just want encapsulation you never needed web Components
| for that.
| milky2028 wrote:
| Web Components are bad. Lit in particular is one giant memory
| leak. No tooling exists for making use of server-rendered Shadow
| DOM, which means users pay CPU cycles for client-side rendering.
|
| Everything here is still true: https://dev.to/richharris/why-i-
| don-t-use-web-components-2ci...
| AndrewHampton wrote:
| I love web components. The one thing I really wish browsers
| supported though was a per-site custom element registry that
| persisted across page loads.
|
| Give me 10mb and an API like service workers have to manage a
| library of custom elements that can be used on my site as soon as
| the page loads.
| pier25 wrote:
| I've been using custom elements and web components in production
| since 2016. The reality is that these don't even solve half the
| problem.
|
| The biggest problem frameworks solve is data binding and
| reactivity. Until there's a native solution to that, WCs will
| need some framework for anything non trivial.
| iLemming wrote:
| Renaissance? Yup, checks out. I've been waiting for Web
| Components to become a thing for a loooong time. The (European)
| Renaissance took two-three centuries - from Petrarch and Giotto
| to Leonardo, Michelangelo, and Raphael. I suppose we have to wait
| for another hundred years or so, and in couple of generations we
| could finally say: "web components is a thing". My grandchildren
| will laugh at my React-based code, that will happen someday.
| Right now, there's shit to ship.
| stronglikedan wrote:
| > My grandchildren will laugh at my React-based code, that will
| happen someday.
|
| I assure you that is happening today, not by your
| grandchildren, but it's happening.
| iLemming wrote:
| hon, this has been "happening" at the time when I grew out of
| my jquery pants, and still was happening when I was going to
| my backbone.js induced ptsd therapy sessions; Angular has
| shipped 20 major versions and React made six rewrites,
| Next.js switched to rust-based compiler and added the app
| router, making 15 major revisions - and "web components"
| still yet "happening". It feels when I finally have
| grandchildren, it is still be only "happening"... Where's the
| darn promise? Where the heck is the fame and riches? I've
| been hearing about this shit for almost two decades now. And
| have not witnessed it. I hope, it is truly around the corner,
| but I just fail to see it coming.
| looneysquash wrote:
| You really really do want to use a framework (such as Lit) if
| you're writing web components.
|
| Or at least, I don't want to use your framework free web
| components. Because the frameworks handle a bunch of stuff for
| you, like reactive properties, that you'll surely get wrong if
| you do it by hand for each and every component.
| dbvn wrote:
| the first time I wrote a custom HTML element was the last time I
| ever reached for a React framework
| postpress wrote:
| Even at only v1, along with the "don't break the web" mentality,
| Web Components are an extremely important stepping stone. We
| should cheer the implementers of these proposal on and help!
|
| We can now render whatever content we want confidently, inside of
| other apps. Less than an iframe, but enough isolation (or not if
| you want) with all of the important benefits of being baked into
| the current document.
|
| Example: https://kherrick.github.io/block-garden/
|
| Same custom element running inside Angular:
| https://kherrick.github.io/apps/playground/block-garden
| Heff wrote:
| I've been building for the web since the 90s and it's always felt
| a little off how slow the uptake on web components has been.
| Glenn Maddern's X-GIF talk at JSConf EU '13 opened my mind to
| expanding the browser beyond its locked-in set of HTML tags. I
| got super excited and started building with web components v1,
| but React was so dominant they never really got traction. And to
| be fair they had real problems too (not easy to create without
| something like Lit, complex async lifecycles, reactive frameworks
| really don't like other things having state). Around 2020, after
| almost a decade building Video.js and being tired of trying to
| make the player work with every single framework, I started
| building Media Chrome (https://www.media-chrome.org/) as web
| components. It's been out almost six years and if you look at the
| npm stats there's been a real spike in just the last year, even
| the last few months to over 1M weekly downloads. I don't know
| what's driving that but it's cool to see.
|
| We're putting out Video.js v10 beta in March, rebuilt from the
| ground up and merged with Media Chrome. We're being really
| intentional to build an idiomatic React version in addition to
| WCs, not just wrapped web components, but I'm interested to see
| if the web component version is actually the more popular flavor.
| mathgladiator wrote:
| So, I'm going the direction of Web Components because Claude can
| pump them out fast. They are easy to test and well isolated, and
| claude can compose them very well which further helps to keep
| context well focused within a hierarchy.
|
| A year ago, I would have groaned hard about Web Components as
| they require yet another investment to integrate and deal
| without. Now, just vibe them in after extensive validation.
___________________________________________________________________
(page generated 2026-02-20 23:01 UTC)