[ajcp]

I understand the blog post, and the capability itself is neat, but I'm having a hard time understanding the utility in what they are showcasing from the actual example site[0].

As other posters have pointed out, why not do it in HTML from the start? It's more simple and efficient than this -or any- framework. Just drop the ol HTML file on your server and away you go!

I understand that the supposed "real" utility in this would be when you want to do JS-y things in HTML (auth, API, hand state, etc), but they don't show any of that on their showcase site...so...yeah.

0. https://website-in-a-single-js.deno.dev/

[AaronO]

I agree we could have elaborated on auth, API endpoints or parametric routes (maybe a follow up !).

But this example does showcase a few things you don't typically get with a single vanilla HTML file:

- JSX + reusable/shared components

- Multiple URLs / pages

- Tailwind

[e12e]

I actually think this is quite neat, but I am a bit worried about caching.

Someone mentioned rails, and rails have a lot of facilities to set correct cache headers for assets (css, js, images etc) and for dynamic content (for logged user in and/or for pages that are dynamic but public).

If you're deploying static files via a vanilla web server, you also get a lot of that for free, via the file meta-data.

I would expect a framework for publishing sites to showcase a minimum of good caching (client cache, ability to interact with a caching reverse proxy like varnish - and/or a cdn).

[ajcp]

I get that after reading your blog post, so that's fair. Maybe it's just a case of the magic trick that's missing that third act.

Clicking around with the Dev Console open and watching the pages in Sources was enjoyable.