[eyelidlessness]

This is it, for me. I don’t want React, but I want (a subset of) its API. I’m building a site with Next.js which in theory should be 99+% static and it should be able to ship with a very small JS footprint. But by default all that static junk gets bundled up anyway. And stripping it out would require a lot of manual work, or building yet another layer of build tooling that would be wonderful to have but is pretty daunting to think about.

[leerob]

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.

[eyelidlessness]

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.