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...
[deleted]
Progressive Web Components
31–40 of 61 posts
Re: Progressive Web Components
#32I 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.
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.
Re: Progressive Web Components
#33Earlier quoted context omitted.
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.
Re: Progressive Web Components
#34I 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.
> 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.
Re: Progressive Web Components
#35Earlier quoted context omitted.
> 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.
Re: Progressive Web Components
#36Earlier quoted context omitted.
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?
Re: Progressive Web Components
#37Earlier quoted context omitted.
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. `imp…
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.
Re: Progressive Web Components
#38Earlier quoted context omitted.
> 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. `imp…
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/
Re: Progressive Web Components
#39We use webawesome.com for all our projects, it works great and is very underrated. HTMX + WA
Re: Progressive Web Components
#40For 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