[lmm]

I'd highly recommend Wicket. It's quite different from the conventional page-oriented MVC style; it's built around components in a way that leverages the advantages of OO (and I say this as someone who's usually an OO sceptic). HTML is kept very close to the corresponding code but there's no confusing intermixing (e.g. there's no control flow in templates); your component hierarchy corresponds to your data hierarchy and ultimately your DOM hierarchy.

[cryptos]

Oh, no, not Wicket anymore! Something like 12 years ago I was a fan of this framework and thought: "Finally, Swing for the web!". I really don't like the technical approach of Wicket with server-side UI stuff. The framework contradicts the nature of HTTP.

I think it is much cleaner to have a clean separation between server and client frameworks and use, for example, something like Quarkus on the server and Angular on the client and get the best on each side instead of a strange mixture.

[lmm]

Grandparent explicitly asked about "conventional server-rendered web applications (as opposed to API backends)". IMO Wicket does a really good job of doing everything in a clean, consistent way (on the server), so you don't actually have a problem of mixing e.g. server- and client-side form validation (and while a network roundtrip is always going to be slower than local validation, the AJAX integration is very good and makes it a lot lighter than a full page load).

I go back and forth on whether that's a good architecture in principle - a client-side UI calling an API has clear technical advantages, and it's much easier to build first-class applications that can run in JavaScript than it used to be. But certainly if you want that architecture then I think Wicket is still the best way of doing it - indeed I'd say it's the best UI framework I've used anywhere, the model/component split forces you to clearly decouple your data from your UI in a way that's not as thoroughly enforced in e.g. Qt.