I still think you’re misunderstanding what React is optimizing for. When you say "React has to force you into making everything an expression", you’re describing its core philosophy, not a constraint. JSX is built around the idea that rendering is just data transformation. It's UI as a function of state. That’s why using map() is idiomatic here. You’re building trees, not iterating imperatively.

Also, it bears repeating that React isn’t just slightly dominant. 82% of JS developers have used it according to the 2024 State of JS survey, and for good reason. It shaped the modern frontend mindset in a way that Vue or Angular haven’t, despite their own merits. For instance, many frameworks came up with their own version of hooks. It's telling that most new frontend frameworks are aiming for the "better React" position.

I realize we just have different interpretations of what "winning" means in a fragmented ecosystem, but it’s worth acknowledging how much React has set the tone for modern web development. UI as a function of state (and using map() a lot...) is here to stay.

> And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.

I think you're wrong here. The point at which the rendered template is actually stuffed into the DOM (and hence the screen) is I/O, sure. But the creating / rendering of the template is a pure function, which is what we are dealing with here.