[city41]

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.

[AnonHP]

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

[dgb23]

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.

[city41]

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.

[kilburn]

"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

[city41]

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/

[youngtaff]

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

[dgb23]

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.

[city41]

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