There's an experimental flag for disabling runtime JS on a per-page basis in Next.js. Not sure when it will land, but the Next.js team is trying to add this directly into the framework.
That’s cool and I was reading about it today. But it’s really not what I want. I’d like to have a mostly static site but still be able to ship interactive components where they’re actually interactive. What I want, in order of preference (lowest to highest):
- The ability to specify that a given component is static and should never hydrate (and never bundle in the build as a result). There’s a bunch of proofs of concept of this out there, it’s definitely a better UX, but it’s not a good DX. It’s a fight to set up, entirely manual, and generally opt in (which means you’re more likely to ship broken components if you forget to opt in, whereas opt out is more likely to deoptimize by mistake)
- Static analysis to determine where components are constant at build time and automatically strip them from the build/hydration flow.
- Compile to DOM operations like Svelte.
Basically, I want a Svelte build with a React/JSX interface.
I’m certain it’s possible, given a long enough timeline. I’m not sure how well it would work with real world React code, as hooks and context could deoptimize whole pages in unexpected ways. And that’s frankly where I wish for a much simpler React subset for this use case.
- The ability to specify that a given component is static and should never hydrate (and never bundle in the build as a result). There’s a bunch of proofs of concept of this out there, it’s definitely a better UX, but it’s not a good DX. It’s a fight to set up, entirely manual, and generally opt in (which means you’re more likely to ship broken components if you forget to opt in, whereas opt out is more likely to deoptimize by mistake)
- Static analysis to determine where components are constant at build time and automatically strip them from the build/hydration flow.
- Compile to DOM operations like Svelte.
Basically, I want a Svelte build with a React/JSX interface.
I’m certain it’s possible, given a long enough timeline. I’m not sure how well it would work with real world React code, as hooks and context could deoptimize whole pages in unexpected ways. And that’s frankly where I wish for a much simpler React subset for this use case.