[troupo]

> 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?

[lelanthran]

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.

[troupo]

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/

[lelanthran]

> 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.

[troupo]

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.