Comment by AnonHP | Hacker News Reader

Comment by AnonHP | Hacker News Reader

> Static site generators are significantly faster than dynamic websites because they run expensive computations beforehand and compile static files. First, let’s dig deeper into the first point. If you run a website with dynamic software like WordPress, there are multiple steps to send your content to the user.
…
> These steps take valuable time, and if they take too long, the user could leave before the content loads.
…
> If you use one of the SSGs that use a JavaScript framework, you are likely sending unnecessary JavaScript to the client. However, partial hydration can solve this. To understand why, let’s first look at what hydration is. Most JavaScript frameworks run code on both the build step and the client. The build step creates the HTML. However, interactivity is still needed. To solve this, they use hydration. Hydration uses client-side JavaScript to make static HTML interactive. Sounds good, right? The problem is that frameworks often send code for parts of the HTML that are not interactive. Doing that slows down page loading without actually changing anything.

> The solution is partial hydration, which allows you to define what you want to hydrate.

So if you started out with performance as a key measure and moved to SSGs (despite the usage being more complex compared to a GUI based CMS), with the JavaScript framework based SSGs (not to be mixed up with simple JavaScript/Node based ones) that use/prefer client side rendering and hydration you now have poorer performance for a lot more complexity in designing the site and building it.

Somehow it feels like the JavaScript framework based SSGs are poorer on many fronts, and seem to give me the impression that they could appear slower to the end user browsing the content (I hate seeing empty placeholders with animations while they wait for the content to be rendered).

Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.

> Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.

It is, even on good connections and using new hardware, they'll load slightly slower than bare HTML pages. The latter will finish rendering before you're even aware that it loaded. I've run into many simple blogs that won't load at all without JavaScript.

It isn't just blogs either. I inherited a static site from a client that ran a real estate development business, and it wouldn't load without JavaScript. If you opened it on a phone or tablet you'd see a loading screen for 5+ seconds. The site just had some images and text.

That isn't a fair assessment. For example Next allows fully static content (no JS at all) all the way to fully dynamic content with a few steps in-between. It's up to the developer to decide which of these they use. This decision is made per page btw.

Hence my snippet “a lot more complexity in designing the site and building it” in the comment above. That developers need to take on the additional complexity of deciding what to do can be a burden (as compared to the ones that do everything at build time).

You can have the best of both worlds at the cost of additional setup / wiring.

Build or use a headless CMS for pure content management, have a preview build (client side rendered) of your site to see the changes instantly. Then trigger releases for optimized, static builds.

For me this is a quality improvement in terms of performance and security and a DX improvement in terms of extensibility and separation of concerns. But again, requires one to make a bunch of decisions and plumbing so everything plays nice and coherent.

It's just a choice the developer needs to make. It's a pretty straightforward choice too, if the page is just static content, make it static. The ones that do everything at build time don't let you build a site that can be interactive or dynamic when it needs to be unless you hack JavaScript into it. It's a lot simpler to just use a tool that supports both use cases.

Rehydration costs in nextjs aren’t trivial, tend to see 500ms+ of long tasks in many nextjs implementations

Rehydration feels „free“ because the site is rendered before that. So there more might be a danger of excusing „bunch of unnecessary stuff“ with it. I think one still has to be reasonably frugal with client side dependencies regardless.

When I said no JS I meant React too. See my other comment in this thread.

"allows" as in "you can hack it to support that use case" [1].

Moreover, Nextjs's devs are increasingly ignoring that use case to the point where it is unclear if you'll hit a roadblock where you can't update anymore because the required amount of hacking is just too much to continue using it like that.

https://github.com/vercel/next.js/issues/5054

You don't need to do that, just put this config setting on the page

https://github.com/city41/neo-geo-dev-book/blob/main/src/pag...

Here is that page: https://neogeobook.mattgreer.dev/

I would argue that if it doesn't work with Javascript disabled it shouldn't be counted as a static site.

I'm confused by what your baseline is here. What are you comparing JavaScript framework SSGs to?

The ones that build the site server side completely (including the ones that are JavaScript based, but not the ones that are JavaScript framework based that tend to move certain parts to the client).

Reply on news.ycombinator.com