Not having all the code in-line that can be in-line is like the 90s. You had me until the 'no bundling' thing. Separate http requests for all resources is a non-starter for anyone worried about page speed. I do like the choice of Preact though!
I take the opposite approach - bundling is a non-starter for me. But it really depends on what you're building. Bundling can be great for web apps, but for content-driven websites where SEO optimization is key, I prefer the "90s-style" approach and Fullsoak's philosophy.
Also, separate HTTP requests allow for granular caching, and with HTTP/2 the overhead is minimal.
You're doing the opposite of SEO optimization if page speed score is of any value to your SEO (and it's important to Google's SEO ranking, so yeah). I work on a "content-driven website" - actually a few thousand of them - and our clients definitely want their SEO to be top-notch and page speed score factors into that. Any http requests for external resources will bring page speed down, and that can affect SEO. I don't have to worry about caching at all when the pages are scoring perfect 100% on Lighthouse.
and that's a totally valid concern :) So far I only wish to check the concept in general (ie: "does it work"). As for "does it work fast / at scale", definitely a future topic.
So it can be just 1 HTML resource + 1 js file for every unique path.
And with preact-iso (or react router) we can make subsequent pages load on-the-fly without a hard browser refresh / hard resource reload. Like so: https://github.com/fullsoak/bun-examples/blob/main/src/compo...
But ultimately: I do see rooms for improvements re. resource optimizations. My personal wish is to use standard web specs such as "preload", "prefetch", "server push", etc. to optimize as much as possible, without taking the "bundling route" - so: just exploring a different taste, not that I have anything against the existing "build routes" :)