Hacker News Reader

Comment by dmitrygr | Hacker News Reader

"time to interactive: 1.0s / first content paint 1.0s"

My man, let me introduce you to ... HTML. It has "time to interactive" at 0.0 seconds and content paints instantly!

I think you might have misunderstood the blog post. It is server-side rendering on the edge, shipping nothing more than plain HTML/CSS to the browser. There is no client side JS *at all* here.

The shown page could be served on 0.01 seconds if it was...html. Or, if you MUST lob complexity at it, use a static site generator... that generates...HTML

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

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

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.

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

No, not even remotely accurate.

The browser still has to fetch and render the HTML. JS-heavy sites do tend to be slower, but no site has a 0s TTI/FCP.

I think it's actually much worse than that - it's a little tricky to tell on mobile, but going from "stats" to "bagle" and back again - looks like this mucks up the client side cache? While one whole second is "90s slow" for a first render for a static site - it's truly ludicrous for navigating back to an already cached page?

How are the cache control headers with this set-up - is there a varnish or similar cdn/cache doing useful work (I'm assuming not, more importantly I'm worried pointing something like fastly at this will fail in caching static pages?).

The request headers have no-cache set. I assume this is because it's in a live developer playground page instead of a production deployment.

Still, that's quite different from live editing static files on disk - then you'd normally get cache and invalidation (if-modified-since/304 etc).

> I assume this is because it's in a live developer playground page instead of a production deployment.

Not how I read it - the first link is to a site deployed via "deno deploy", the last one is a link to the same content in a playground.

>> Hosted on Deno Deploy, this little website is able to acheive a perfect pagespeed score. Serviced from an anycast IP address over encrypted HTTP from 29 data centers around the world, the site is fully managed and will be available indefinitely at zero cost.

>> Everything mentioned here can be viewed on a playground.

For what it's worth, the deployed site seems a little snappier to me now on mobile - maybe I'm just less grumpy after dinner...

You know what's funny I'm a fool that still had "disable cache" checked in the dev tools from a previous session when I was checking the request headers. At the current moment now that I have unchecked that in dev tools it is actually respecting the cache for those images. I can't definitively say if that is different than before but either way at least it seems cache is verifiably working with it normally now that I have that unchecked.

Report a bug in Lighthouse then.

Reply on news.ycombinator.com