I would say react being the default expands to apps that normally would work perfectly server-side rendered. The insane amount of added boiler plate associated with writing an API, tests for the API (including contract tests), API documentation, API versioning concerns, deployment timing considerations; front-end API integration, front-end state management, front-end tests, API mocks, I feel like there's about 10 more items I could rattle off.

I feel like people forget that web apps can be rendered server-side, and with HTML-over-the-wire (HMTX, Rails Hotwire, Phoenix LiveView, Larvel LiveWire, etc), server-side rendered apps can have a UX similar to a react app, but with far less total effort.

▲

palmfacehn 10 hours ago | parent | next [-]

Even for dashboards or other cases where the React maximalists claim that application state is too complex, it is usually trivial to inline a bit of JSON representing the initial state and handle updates with Vanilla JS. For me, I appreciate that my pages can render with one single request. There's something deeply wrong when you have the entire browser API at your fingertips, yet include 10mb of dependencies. The browser is already a heavy piece of tech, yet the typical JS heavy page is larger than the equivalent static binary of a native application.

	▲	lelanthran 8 hours ago \| parent [-]
		If you dont need two way data binding you can go quite far without React, using a single general dispatch function for one way data binding. Few use cases need two way data binding, but under React every use case gets it. IOW with React to get the 800lb gorilla attached to the entire jungle when all you wanted was a banana!

▲

kqr 7 hours ago | parent | prev | next [-]

You might not even need fancy techniques to have UX similar to a React app. When the page load is fast enough, browsers hide that it happened. This means you can afford to do everything in the backend and just send plain HTML over to the user. For example the Decision Drill[1] application performs a complete page load on every interaction, but the server is fast enough that at least with my internet connection, it feels to me like the corresponding React-based application would.

[1]: https://xkqr.org/decision/

▲

mberning 15 hours ago | parent | prev [-]

I agree 100% on the added cost and complexity. I think a lot of that gets masked by the boilerplate that makes it so easy to get started. Then they have their hooks in you and 6 months or a year later you are scratching your head and hiring “react developers” to help solve the problems you were trying to avoid.