I hear you. I reached for React for 6 year or so. I built the first application for the client I've been working for for the last 4 years with React. We built the next 20+ w/ server rendered Rails. The interactivity was the same. It's forms-over-data, but the forms have a relatively unique collaborative nature -- you and others can be editing them simultaneously and you'll see each other's field changes in (relatively) real time. The forms can also be massive and have fully dynamic sections. We did it with React (using react-query) and then did it again with Rails, turbo, and stimulus.

The JavaScript code that manages the collaborative form I mentioned is around 300 lines. Every new form we build is just Rails partials with helpers. No APIs, all server-rendered. It works very well. It loads faster than the React version and it has observably less maintenance cost.

> For server side rendering to take off...

> date picker

A reasonable one is built into most browsers now. You don't tend to anything more unless you need something specialized, and then there are libraries you can use (or you could reach for vue/preact/etc w/ the so called "islands" technique)

> form validation

On the server with Turbo/LiveWire/HTMX

> expand/collpase

This can be done with just CSS and a hidden checkmark. The JavaScript version is lines of code.

> selection

Not sure what this means

> reordering

There are libraries for this. By the way, I built a Trello plugin that effectively re-implements Trello within Trello including drag-and-drop reordering and I used Preact and one of the React DND style libraries (don't recall which now). There was nothing easy about it, but it was likely easier for my specific use case to use those technologies. That's one feature in most apps though (for us it was basically the whole thing), so if I needed it in this app, even if I reached for React/Preact, it would be isolated to that one feature. I'd try very hard to avoid it though.

> lazy loading

Turbo/HTMX make this trivial. Note that we use SSI (server-side-include) to compose web applications. This is all done on the server. Our apps are fast enough that we don't need lazy loading to maintain a very low response time even when hitting multiple servers in a request.

> Trust me, I’ve done it with jquery, it can get the job done but it will be a compromise, nowhere near the ease and accuracy that react gives.

So have I. Then I did it with React for over 6 years (including the transition to and from Redux and to hooks). I championed React and CSS-in-JS at my agency. Now I've done it with server-rendering again and different front end libraries (turbo/stimulus) for 3 years most recently. The difference is night and day. I have 15 other devs on my team that would tell you which stack they are observably more productive with. I'm just some guy on the internet, so take everything I say with a grain of salt, but I am uniquely positioned to be able to speak on this with practical experience on all 3 topics in this discussion (how server rendering was, how React is, and how server rendering is now).

Honestly, much of it comes down to what we let our "designers" force us into. If it's just the type of things that you described, it's server rendering all day. If it's random/unnecessary interaction/fluff/flare, the appropriate countermeasure is saying "no". Again, if it's Miro, Linear, Superhuman, etc, then sure -- reach for a full-fledged SPA framework/library.