If not React, then what?

Agree that WASM cannot yet directly manipulate the DOM. But are build times in JS/TS framework world any slower than Rust compile times? I'm not convinced on this point.

As a disclaimer, I still prefer vanilla JS and progressive enhancement.

Why do you think that?

The only client side component of interest would be filtering and sorting, (although the server could render the new state too). I would choose traditional server side + a little bit of client side code here.

I disagree a bit with the article's implication that putting more code on the client leads to a loss of control. With web programming, there is no way to have full control. Even if you avoid JavaScript on the client and concentrate all the code on the server, the server output still has to be rendered by the browser, and you don't control that. You have no control over what browser is being used, what settings have been applied to the browser, the level of resources available on the client machine, what other programs are running, and so on.

I've come to the realization that unless you're OK with some very clunky front-end, there's just no way to avoid quite a bit of JavaScript on the client. Once you need to write a non-trivial UI heavy web app, you quickly realize that avoiding JavaScript on the client is a non-starter, as cool as that would have been.

The issues involve a lack of standardized sophistication of the web technologies, like HTML controls being clunky, very unsophisticated and hard to configure/style properly, CSS not being properly composable, HTML forms not implementing the full set of HTTP verbs, etc... To me these are fundamental problems with the web architecture that need solving.

Revamping the web architecture to properly support a sophisticated negotiation of control between the developer, the browser, and the end-user would greatly reduce, if not almost eliminate, all the thorny problems that declarative UI frameworks and libraries bring into focus.

> I disagree that SPAs are the only solution to some problems.

I disagree with that too. Did I ever say otherwise?

I do believe, however, that there are problems for which a SPA offers the best trade-off. Not the only solution, but the best trade-off.

> This is an orthodoxy which people buy into but there are always a few different approaches possible.

Like the orthodoxy that "nobody needs an SPA"?

> What do SPAs actually offer which is unique?

Interactivity. Good luck keeping your focus or scroll position while reloading a page. If done carefully, performance can also be on that list, though I agree it is often not done carefully.

> Just because you want to load code and data dynamically doesn’t mean you need to buy into SPAs

Agreed. Though you can load both code and data dynamically from a SPA, if you need.

Perhaps our definitions of a "SPA" differ? SPA is when you don't do reloads, hence "single page". But there are many ways to do that, some of them involving React.

> The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial)

Server-rendered front end frameworks (like Rails) have units of composition as well (partials, helpers).

> with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket)

What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach. There are even more interactive applications like hey.com (a full-on email client) that is server rendered.

My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

> Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.

Are you trolling? The things I listed are "over-complicated"? HTML is what React renders. You need to write something like it when you write your JSX. Sorry, you gotta know that. Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive or SEO. Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

And, "debug some HTML"?