- I think it's better to think of "Web components" as "Custom Elements" they really aren't components in the way you think of components in other frameworks (which on the web introduced them first), and I think most of the dissatisfaction with them comes from trying pretend they're an alternative as they just aren't. Components in almost every other framework are efficient (efficient rendering runtime) and expressive (the ability not to have a root element but instead a frag, or context APIs etc) in ways that web components never will be, which makes them unappealing.
But when you think of them as a suite of APIs to define custom elements, that can coexist with your framework components, this delimma goes away.
I do think it's a-shame that modern frameworks don't better support shadow dom and local styles, and local events. Understandably I also get why they also don't see that as a good use of their time either, it adds complexity to the runtimes, they need to observe events at multiple root nodes.
Besides the cost of implementation and commitment to additional complexity, assuming that was a nonissue, with the exception of those otherwise legitimate reasons, there's no technical limitation that prevents React from supporting shadow roots for arbitrary custom element. I made a proof of concept of this myself seems to work quite nicely with a stylesheet loader hook (which ensured it was loaded once and there was a shared sheet between all instances of the same element), but I had to start observing events in each elements shadow root.
- I think also the lack of framework support for things like defining a shadow root probably feeds into this idea it needs to be mutually exclusive.
Elements in shadow root elements can be updated more or less the same way as elements in light doms with incremental patches and updates.
The main beneficiary of supporting shadow root and local stylesheets would likely be hobbyist projects looking to minimise their build step, as local stylesheets give you much of the benefits of many of the tools that handle localising a stylesheet to a component at build time.
Unfortunately, I haven't really seen numbers on this but I can't help but I feel the way styles are bundled by most modern bundlers (with global styles and minified classNames) will likely outperform a bunch of disparate components with their own individual local stylesheet with its own request (even with http2 or whatever). So again I can see why the framework maintainers may struggle justify spending time and energy on this.
- There's also the issue that web components are eager. Once it's in the DOM, and upgraded, it will cause an endless cascade of requests for every import inside.
I don't know if they fixed it, but when reddit rewrote their menu with web components, it required 100+ http requests to render.
- > don't know if they fixed it, but when reddit rewrote their menu with web components, it required 100+ http requests to render.
Nothing to fix, mostly. Those are static requests and get cached.
- Or you do a single request with a sane framework, and it gets cached.
It's a menu, not a nuclear plant dashboard.
- I have a wrapper around fetch for static requests so that no matter how many requests for the same file are made at the same time, only one of them actually goes out over the wire.
There is no problem here, whether you have a page that requests a static file 1000 times in a nested DOM or a single time. The outcome is still only a single request.
- > I have a wrapper around fetch for static requests
imports are not fetched by JS fetch. They are fetched by the browser. It happens before any JS in the component is even run.
That's why web components force request cascades: for every import the browser fetches the script, parses it, and starts fetching imports there, recursively.
Edit: it's also one of the reasons why bundling exists in most JS build tools. `import` was conceived when parallel fetching over http2 was right around the corner... and never materialized. So why make potentially hundreds of inneficient network calls (with browsers restricting them to something like 4 at a time), when you can just collocate code and dependencies?
- Ah, I see what you mean. You were talking about using imports recursively.
I use fetch instead of imports for web components because I have a web component that does client-side includes, and it's literally easier to do client-side includes in a performance manner than anything else, including the recursive case.
- So we're back to my original comment: https://news.ycombinator.com/item?id=49131513
Yes you can invent all kinds of workarounds for their core design. Re-implementing imports like you do. Or bundling, like everyone does and something that even lit recommends: https://lit.dev/docs/tools/production/
- > So we're back to my original comment: https://news.ycombinator.com/item?id=49131513
And we're back to my original comment - imports get served from the local cache, so a bit of a nothing-burger in the great scheme of things.
- Except cache is not infinite, it is routinely expunged and re-fetched.
The "nothing burger" is so significant that even projects whose stance is "web components are the end all be all of web development" like lit recommend bundling.
- I don't know I've encountered this same issue, but I've seen cases where the same stylesheet would be fetched multiple times which is quite annoying. I had to go out of my way to setup something to handle this.
Basically in my own render DSL like, I do this:
There's a bit going here, and my terrible method names probably don't help, but `ctx.useRemoteStyleSheet` internally checks if the stylesheet has been fetched is the process of being fetched, returns an object which contains the load state allowing the component to handle its unloaded state. But this might avoid that specific issue of 100+ css requests, I still get quite a few just not that many.import { customElement, define, shadow } from '...'; export const ExampleInput = define((props, ctx) => { const sheet = ctx.useRemoteStyleSheet(styleSheetUrl); const onInput = ctx.useHandler(...); const onKeyDown = ctx.useHandler(...); // ... const field = input .css({ opacity: sheet.loaded ? '1' : '0' }) .on(onInput, onKeyDown) .void({ type: 'text', value: text, disabled, className }); return customElement('akst-input-number') .shadow(shadow.css(sheet).c(field)) .void({ className: hostClassName }); });Before that I had a more manual process where fetches had to go through a style sheet loading "service" (or a light stateful wrapper over one). This was before I effectively made the above react like clone. Now that just happens behind the scenes, instead of all the nasty wiring I had with the web component class.
- Support for anything web components-related is a death by a thousand cuts both for the browsers and for the framework authors.
For the browsers:
Shadow dom breaks almost literally everything. It's a parallel world that exists on its own and that needs dozens of additional web standards to patch holes introduced by it. And delays dozens of useful web standards that now have to be aware of it.
On top of that nothing in web components is ever created thinking even one step ahead, and break multiple pieces of basic functionality. It's a collection of barely fitting patches. E.g. at first they couldn't send data in forms. Enter FormData. Oops, still cannot be a custom form submit button. Here's a 7-year old still unresolved issue: https://github.com/WICG/webcomponents/issues/814
For frameworks:
Framework authors have to patch all thise holes on their own. Because unlike web components they actually do care about standards and browser functionality. If styles don't work, forms din't work, code doesn't work etc. because of web components, it's the framework that will be blamed.
It doesn't help that there's an insane amount of work involved in figuring out all the ways they are broken. See for example: https://xcancel.com/Rich_Harris/status/1841467510194843982#m
- 100% agree, and for most heavy users it really doesn't really enable them to do build any kind of app they weren't already able to do before.
The web platform has been shit long enough that frameworks and build tools ended up getting around to working around many shortcomings that shadow dom and web component APIs seek to address (such as scoping css with css modules then css in JS, now whatever else the cool kids are using), and the end result has less runtime overhead.
So say React adds support for shadow dom, as a user building a SASS app why adopt these APIs when your build system already does these? The framework authors know this, and so it's unclear what they gain from directing resources into making these parts of the frameworks API.
The only reason I tried it in my toy render DSL, is it sounded fun and unlike react I don't have to worry about breaking 10s of thousands of apps if I do it wrong.
Like I found it useful because I was trying to avoid using a build system and local styles allowed me to clean up my styles without resorting to build steps. But I'm largely building tools for myself and I don't really care about load times, and this likely isn't a representative use case.
- One fun thing I did once is use the custom elements API to make a custom tag <element-template>. When the page sees <element-template tag=what-name></element-template>, it looks inside, finds any <template></template> <script></script> and <style></style> tags, and builds a new custom element with that tag name and all the powers. Cool but not incredibly simple.
Another amazing trick is to put a mutation observer on the page to detect <template> tags as they're created. (template tags parse the HTML within but don't actually create it on the page). Once the observer finds a template tag it can upgrade them to have new powers, like replacing the contents of other tags. There are ways to tame web components and make them very easy to use.
- > One fun thing I did once is use the custom elements API to make a custom tag <element-template>. When the page sees <element-template tag=what-name></element-template>, it looks inside, finds any <template></template> <script></script> and <style></style> tags, and builds a new custom element with that tag name and all the powers. Cool but not incredibly simple.
I went a similar way: https://github.com/lelanthran/ZjsComponent
Not using it in anger in any prod system right now (finding the past, prior to AI, though), but all my side projects use it. Need to check and close any security issues this may have (not that I know of any yet. Should probably ask an LLM at some point about the danger of this).
- This article I came across last month on “Framework-agnostic design systems” happens to use this Elena library and I think explains its use case well: https://piccalil.li/blog/framework-agnostic-design-systems-p...
- For web components to be consumable across frameworks, you still have to write it to be compatible for different frameworks. Our platform team thought they could get away with just focusing on native js, but when it came time to use in React, many behavioral approaches were incompatible. Dealing with re-renders would clear the state of the WC, losing all dropdown items. The toggle button had an infinite re-render glitch when combined with setState. We lost the ability to require event handlers, and prod had a few P0’s over unhandled click events.
The ideal was to be close to the browser, but it’s mostly blown up in our face. The approach in this post would’ve been helpful, and it’s almost worth the cross-framework compatibility, but I just wish the entire web components standard didn’t come with an unbelievable amount of these and other problems
- isn't the issue here that React & Co. don't follow standards to support web components?
- React had their own solution to web problems and went with it. Don't confuse that with obstinately discarding your favored technology. I personally tried web components and it was nothing but pain and solved no problems I actually had, unlike React.
- I work mostly with React but maintained a cross-framework web component library for a while, most of the issues that came in from our users we could not do anything about, as they had to be fixed by framework maintainers...the project died.
- Turns out that it's really difficult to make web components work with existing frameworks because instead of simply using existing web primitives as you'd expect, they made new ones. They use incapsulation primitives and state boundaries that make integrating them seamlessly with other frameworks anywhere from difficult to literally impossible. So it's unfortunate but unsurprising that the frameworks didn't fix the issues in time. Framework authors have spoken at length about their difficulties in developing generic interop with web components. Many of those issues persist to this day, long, long after the enthusiasm and momentum has gone.
- I'm sorry but purposely ignoring standards that were decided upon by multiple parties is always a shithead move. It shows that you don't actually care about community standards and just want to thrust what you believe down everyone's throats.
- The issues were more behavioral for us. You can build the web component however you want, and the venn diagram of acceptable WC behavior vs React isn’t a full circle at all. Changing elements directly will mess up any VDOM-based approach, resetting state because rerendering means having a brand new WC, creating custom events in an esoteric way, it was a minefield of incompatibility beyond just “React can work with web components”
- Lol. Or is introducing a "standard" that no one asked for and squealing that no one wants to spend their lives integrating your leaky "solution" a shithead move? Who is shoving things down people's throats really? You are very confused about the timeline for how these events played out.
- Sorry but software development is more important that what some tech bro at a malware company thinks. I'm not confused at all. This is the culture of SV and it is the culture that VC wants: when they don't get their way they complain and force it upon others. The desire to exploit is their only ethos.
- Web Components are great for doing multi-pass rendering with template placeholder substitution happening at multiple levels in the component hierarchy. The entire element HTML hierarchy can be declared in one place. It's extremely versatile.
React cannot do this. It's difficult to explain without writing a whole essay but the benefits are very clear once you try this approach.
- True, but at the same time if you're building an app the number of times when you think "I want to render this HTML without hooking it into the data store, other components on the page, data fetch layer, logging implementation, etc" is literally zero.
React can't do the thing people building apps with React never do is not an argument against React.
React is for building React apps, in case that wasn't obvious.
- Anyone doing anything interesting to use CSS libs like Bulma, Bootstrap with web components? Definitely feels like swimming against the tide. Got a hobby project in Lit.js, can't easily wrap (e.g.) `.btn` in a component without breaking styles because the component root/host ends up between `.btn-group` and `.btn`. One can manually add classes to the root/host but that only gets you so far. Ideally I could select when to render a root and I vaguely remember that Lit allows this but I don't remember figuring this one out.
- Nice! Reminds me of https://semantic-ui.com/ and its forked cousin https://fomantic-ui.com/
- My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered.
It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.
- Why is the uniqueness constraint of tag names a problem?
- I tried to embrace web components, but when I reached "declarative shadow DOM" I really just stopped seeing the point of all that complexity just to do what I can already do with a library. The target audience of that API seems to be library developers.
- Yup. Lit element is much more accessible if you want “just” web components, but with a sane syntax.
- As much as I dislike Google, Lit has been a nice middle ground for me.
It's lighter then a framework, events are vanilla JavaScript so you don't have to figure out how to make a JS libray you've found work within some framework's custom event bus.
It has enough rendering support so you don't need to update everything with .innerHTML. Change the state of a component, lit will call your render function but only update the parts of the DOM that have changed. I felt that was a nice partial answer to suggestions you need a virtual DOM because updating the real DOM is slow.
- I’d argue that the target audience of Web Components in general should be library developers.
Web Components are great for distributing UI elements that work with every framework.
Web Components are terrible for just building apps. Use a framework!
From this perspective, Elena seems like a welcome approach. If Web Components are for library authors, and they are, then it stands to reason that Web Component frameworks optimize for that as well.
- > The target audience of that API seems to be library developers.
And then most library developers find them severely lacking, riddled with unsolved and unsolvable issues, filled to the brim with invalid assumptions and awkward APIs etc :)
They are somewhat okay as framework-agnostic "leaf" components if the authors spent a lot of time honing the usage and the APIs. Things like date pickers for example.
- The syntax looks very similar to Lit, but it's a nice application of HTML & CSS first, instead of relying entirely on JS to do that.
- The HTML + CSS first approach and JS only for enrichment sounds great, and like what should be done anyway. I wonder though, how it will play out in reality. Will web developers using this library make the effort to keep essential functionality JS free, if possible, and provide additional views using whatever web framework they use, or will they implement essential functionality as "JS enrichment", requiring JS for things that do not actually need to be done in JS at all?
- In reality, building anything complex is a huge pain using web components, particularly because it is hard to author them with appropriate level of styling API and accessibility support. In my experience, web components are fantastic for consumers but terrible for the authors.
Still, the advantages are clear: they don’t need any special runtime and can be used with other JS frameworks.
Another thing in favor of web components is support for custom registries which make gradual migration from one version to another trivial. AFAIK, no JS framework has an equivalent of custom registries.
- Try keeping them in the light dom.
Everything works like normal html + css, but you get all the benefits of reusability and encapsulated script logic.
Lit-html (the library, not the framework) gives this approach super rendering speed too.
- At what point does a library start being a framework and when does the distinction matter to the end user?
- I like web components, the simpler the better, so I like what I see but having a strong OCD about syntax I just want to propose the use of <Button ... instead of <elena-button ...
It's just a matter of using a regex [1] and making your syntax more palatable
Regardless, kudos for the release
* const componentRegex = /<%[ ]+([A-Z][a-zA-Z0-9])([^%]?)%>/g;
- HTML is case insensitive, so <Button> is the same as <button>, and custom element names must have a hyphen.
Your component regex represents a JSX limitation, but web components do not need React. Plus, if you capitalize the first letter, JSX would treat it as a React component rather than a web component (i.e. custom native HTML elements)
- I don't understand your proposal
Customer elements MUST have an hyphen.
<Button> is the same as <button> in HTML
- When you built this you probably were aware of lit. How does Elena differ from lit?
- Hm, the page is unreadable on brave on dark mode.
- Si by by
- We use webawesome.com for all our projects, it works great and is very underrated. HTMX + WA
- [flagged]
- Ok but ... why? With that I mean, why do we need it? What can be created with PWC specifically? Is there a gallery of web games? That would at the least make understanding the use case easier.
- It’s on the page: https://elenajs.com/#why-should-i-use-elena
You can create anything and everything. Web components are about extending html to make it do more, progressive web components are about rendering that on the server and progressively enhancing with interactivity in the browser. Elena solves the major pain points in doing that. Components built this way can be used in any framework.
