React does not require a build system. Just alias createElement() to e() and you get the exact same capabilities with a slightly more verbose syntax. I’ve done just that in the past to add small bits of interactivity to vanilla JS client side without modifying anything else.
It is a similar sort of confusion that comes from people thinking React is a Web framework. It’s actually a small library.
Yeah I've tried that way of using React and I don't like it.
I know it's an unpopular opinion (and the React people swear it's not true) but React is absolutely a framework, not a library!
Adding React to a project fundamentally changes how that project is architected, and affects almost all of the code written for that project going forward.
Trying to use it just as a library very much goes against the grain of how it is commonly used.
> I've tried that way of using React and I don't like it.
I didn’t say you would like it. I just said a build system is not required, contrary to what you wrote. JSX is not an integral part of React, and it is practical to omit it for small cases where interactivity is needed. Contrast it with things like Vue, Qwik, Astro, etc.
> I know it's an unpopular opinion (and the React people swear it's not true) but React is absolutely a framework, not a library
On the contrary, I think it is a very widespread opinion (most of this site will probably claim the same, and opposing comments are often downvoted), but that doesn’t make it less wrong. People form their opinion from encountering various instances of React use in the wild and common patterns of using React, not from what React actually is. Those instances or patterns will necessarily be mostly bad because the barrier of entry to Web development is very low and with LLMs the amount of that bad code only multiplies as of late.
> Adding React to a project fundamentally changes how that project is architected, and affects almost all of the code written for that project going forward.
By that logic, something like fp-ts or Effect is a framework, rather than a set of tools for functional TypeScript programming.
An important quality of a framework is that “you are building within its realm”. Consider Django. You have project scaffolding and structure, batteries are included, and the way you use it is strongly prescriptive or you are fighting the framework.
By contrast, like the above-mentioned Effect, React prescribes little and can be used in vastly different ways and applications not limited to Web. React itself does not even depend on there being DOM or browser context of any kind, I think last I checked it actually had no Web-specific code at all, though I don’t know if RSC changed that. All DOM-related stuff comes from ReactDOM, which is another library.
> Trying to use it just as a library very much goes against the grain of how it is commonly used.
First, if most people use it wrong[0], then just go against that grain. It will not go against React’s grain, because it has not much grain to speak of. It is a library with a few restrictions about what kind of callbacks you pass it.
Second, React is most commonly used through frameworks, like Next.js and such. There are also many instances of people using React via CRA project templates, which again are not part of React proper.
[0] …and using a library as if it was a framework is most definitely wrong. If your use case is of the framework-fitting scale, you should either A) use a framework or B) be conscious of the fact that you will end up with a framework of your own and plan accordingly (by default those frameworks tend to suck).