React is nigh-universally agreed to solve a set of problems related to frontend web development. You may not recognize the pain of those problems and it may not solve them the way you like it, but the way you've attacked the sentence is really strange.

What if you could eliminate a lot of the pain points that React solves but without having to write much (if any) Javascript but still have an application that feels like it's rendered client side while getting server side rendered templates for free, and things like "but I can share my logic between the backend and frontend" goes away because the backend can do both?

This is just one type of problem that Phoenix's LiveView solves and LiveView is only a small aspect of what Phoenix has available. I'm very thankful work is being done in this area instead of just accepting that everyone wants to use React.

I mean, cool, great. I like React and I like TypeScript more than I like Elixir so that does nothing for me, but great.

But I'm not sure why you replied to me.

Ostensibly, because it helps to solve the problems you've been hired to solve...

Whether or not you like React, the point is that it's solving a problem. Maybe not for you, but (I'd like to believe) at the very least for some of your colleagues.

True that whether I like it or not doesn't matter in a business and team sense. I should have phrased my comment better.

I don't believe it is solving a problem. It's creating unnecessary complexity. The app is just a typical CRUD app. Traditional server side rendering would be fine in my opinion. Or perhaps coupled with LiveView or TurboLinks, and Stimulus.js.

Btw, this is not so much a knock on React specifically, but on the overuse of the SPA paradigm [1]

So in conclusion, using React in this case (in my opinion) doesn't solve a problem and yet I need to use it.

[1] https://news.ycombinator.com/item?id=19134260, https://news.ycombinator.com/item?id=19184496, https://news.ycombinator.com/item?id=19905004