But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
<%~ includeFile('./navbar', { pages: [
'home',
'about',
'users'
] }) %>
<navbar pages={['home', 'about', 'users']} />
> would just be JavaScript functions that take props and return some JSXThey can also be async functions that process data independently. Whereas templates are commonly just passed in data from the controller.
If you are building a growing design system with any degree of complexity, React is one of the best tools available.
I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html ?
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.
Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.
In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.
Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.
Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.
Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.
That doesn't make either of those things true.
As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.