*breathe in*

Consider an App (app.js). It’s setup to lazily load components A on route /a, comprised of a.js and a.css, and component B on route /b, comprised of b.js and b.css. This is a fairly common architecture.

There exists no bundler that for the route /a, starts loading a.css before app.js finishes parsing/evaling. The so called ‘waterfall’ appears.

So you build a meta framework, that includes a server, where routes and top level components are “first class”. This helps because of you know the dependency graph across these systems, you can ‘make decisions’ earlier than the code itself would. The waterfall collapses.

Now either you build this yourself, or you get it from next/gatsby/remix/etc. Now you’re bound to the bundler/server stack. If you use any bundler specific idioms or syntax, and the moment a new bundler stack with a good enough value proposition comes along, you’re kinda stuck.

The answer is probably to introduce a lower level primitive. Maybe not at language level (but maybe yes?). React’s server components are a good idea and helps with this situation (but of course, is react only, and maybe that’s fine). But it’s a good lead.

What _html_ is probably lacking is annotation primitives. If WCs were done right, basically. But the powers that be aren’t setup to innovate (which is the point of standards bodies, after all, very little is standardised without prior art), so it’ll be a while before we get there

(Yes I know all the proposals. Hence, “it’ll be a while”)

Back to my original point. It strikes me that the only thing that really works is if your “framework” (or more accurately, your toolbox) is setup to consider your components and bundler and server as a continuum. I bet that’s the thing to build.

And until that exists and is widely accessible, expect some motion in the ecosystem.

*breathe out*

* mute * sorry it’s Sunday, and I regret this thread! Might delete too, didn’t mean to cause contention. Have a great weekend!