[mwcampbell]

> tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else.

My main reservation with Spring is the heavy dependence on runtime reflection. I'd like to see a Java web framework designed for conventional server-rendered web applications (as opposed to API backends), with authentication, CSRF protection, form validation, and so forth, but without heavy use of runtime reflection for wiring up objects.

Edit: Also, especially given that Project Loom is on its way, I think a blocking API like Ninja or Spring MVC is best.

[vips7L]

Quarkus does all of its wiring at compile time.

[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.

[yumraj]

> My main reservation with Spring is the heavy dependence on runtime reflection. I'd like to see a Java web framework designed for conventional server-rendered web applications (as opposed to API backends), with authentication, CSRF protection, form validation, and so forth, but without heavy use of runtime reflection for wiring up objects.

Add Phoenix style LiveView and we'll have a winner..

[debarshri]

I'm not sure if you have heard about java spark [1]. Back in the day, around 2-3 years ago we used to implemented all our java service in java spark.

[1] https://sparkjava.com

[dxxvi]

Its last release was in Oct 2020. I think io.javalin:javalin is a bit more up-to-date.

[daniel-grigg]

Take a look into micronaut too, I’ve used it for a couple things and it’s pretty full featured even though it’s geared towards micro services. Very easy to migrate to from spring too.

[__jem]

The functional Spring APIs in Kotlin allow you to write Spring apps with minimal reflection, and are honestly great, although a bit immature.