[nl]

I think you are missing the point.

React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.

[bayraktar]

So what other kind of thing do you suggest (and which currently has some traction)?

[berkes]

What about the tried and trusted "have some backend generate HTML and push that to the client"?

It still works for me, has many benefits, and many downsides. But so do the "react-alike" frontend frameworks. There's no silver bullet.

It cracks me up (and makes me sad) to see all the effort going into "hydrating, SSR and whatnots" in JS frameworks, where we move our ball of react-js-spagetti onto some deno-based-edge-function-container thing, in order to serve clients plain HTML... I mean, this problem was solved in 1998 already!

[bayraktar]

Okay, I'm with you - but I meant for, like, people who have some idea of what they're doing (and don't just impulsively reach for a massive framework to deal with routine content dispatch).

What do you suggest for manageable SPA-like development -- for those of us who have actually thought the matter through and have decided that's what we need (at least in certain corners of this otherwise lean and mean, mostly static / old-school website we're building)?

[berkes]

I'm not familiar enough with the current space.

But my preference would be something like: plain old server side rendered HTML with JS that enhances the site, adds some dynamicity etc. But in which a link or button-click usually is just fetching a new page over the wire.

This JS can (also) fetch data over the wire, websockets or such. And I wouldn't even expect it to be some fancy "progressive enhancement" - fine if the web-app doens't work without JS for me.

[nl]

I don't agree with the Twitter thread but the implied alternative is serverside HTML and unclear what is the solution for rapid UX on the client.