I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames.
JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF.
GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know JavaScript and your DOM to write GWT. So it turned into a fight against that main idea of GWT.
I am frequently surprised by folks that are active fans of both. So, I don't think they are dead dead. But GWT, in particular, really helped cement a ton of distrust for any framework coming out of Google.
JSF was trying to make handy components for JSPs. And made them unusable in the process.
Also Vaadin which sort of combines two approaches and these days even allows you to go Java-only or Javascript-only. The company is still alive and well so I assume it's popular for internal enterprise apps.
JSF and GWT were rightly abandoned, but the new frameworks are different in ways that might be relevant. One of the main problems with JSF is the mismatch between it's stateful programming model, and HTTP's statelessness; as I understand it, LiveView uses a persistent websocket connection to a stateful server process, so that mismatch doesn't apply. Another JSF problem is it involves a component-based templating system that abstracts quite a long way from HTML, making it hard to figure out what's actually going on. LiveView, Hotwire, and htmx all seem to be much closer to HTML, which might make them easier to work with.
I admit I'm still to scarred by JSF to be keen to try out these new frameworks and find out if they've actually solved these problems, but I'd love to read an evaluation of the new server-side frameworks from someone who experienced the problems with the old ones.
I've worked quite a bit with JSF and although I was never a fan it does have some points. It allows for focusing more on contents than visuals also assuming the visuals won't be that fancy. There's plenty of apps that don't really require going all-out on eye candy. Note that it was always a problem when people do want eye candy. I also rarely had issues with performance but perf. is always an issue regardless of working with server- or client-side rendering.
I pray for WASM to eventually replace JS. NodeJS ecosystem with all the experimental features, job ads in update notes, shitload of dependencies, one-function packages, legacy JS is a special kind of pain that I avoid whenever I can.
JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF.
GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know JavaScript and your DOM to write GWT. So it turned into a fight against that main idea of GWT.