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/

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

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

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.

I know it's taken from their marketing lingo, but edge makes sense only if you have a "core". This demo app doesn't use that model. It's just "cloud", or lambda if you want.

I'm not sure Deno(the service, not Deno the language) are actualy proposing a model - similar to Cloudflare, for example - where you have your infra somewhere and they only host the "edge", in a CDN, or spread around the world.

Try playing around with the pagespeed link provided in the article. You can see that in the default view the network is set to slow 4G throttling with an RTT of 150 ms so it's going to be impossible to get times like 0.01 seconds. Even just loading https://x.com, a site that literally serves a single character of content "x", gets 0.8 seconds.

You can see for yourself with the provided Pagespeed metrics that the root document was served in around 30ms (corresponding to TTFB).

If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.

Unless the server runs at negative cycles per second, more cycles means more time taken. Did i miss-math?

You've shown a way to add multiples of ~0.0000000003 seconds to the time but haven't explained how the page is going to go from .01 seconds to 1.0 seconds as a result when TTFB is 0.03 seconds.

The demo is literally a static site generator that generates HTML

It's not, unless "static site generator" is one of those terms (like "literally" or "REST"[0]) that has morphed to mean the opposite of what it was supposed to mean. (Not to be confused with "serverless", which never meant what the word suggests.)

This application is generating HTML on the server, but so does PHP. A Web site backed by a PHP application is the antithesis of a static site.

0. https://news.ycombinator.com/item?id=23672561

The shown page is HTML. It's a plain-old website that works the same way websites have always worked: the page is generated at request time, and HTML is served directly to the client. It's not technically a "static" site because the HTML is not cached ahead of time, but apart from the fact that the whole back-end is a single JS file, there's nothing special here.