5 ms·

It’s a shame that the Play framework is being abandoned. v1 had a lot of great ideas, but v2 kind of jumped off the cliff into Scala lala-land, where it got los

It’s a shame that the Play framework is being abandoned. v1 had a lot of great ideas, but v2 kind of jumped off the cliff into Scala lala-land, where it got lost in the weeds. It never really recovered. If you’re looking for a straightforward Java framework similar to Play v1 check out Ninja: https://www.ninjaframework.org/ https://www.ninjaframework.org/ For me at least, it hits a sweet spot of enabling fast productive development and maintainable code.

mountainriver 5y ago
You could say that again, play v1 was so simple and productive. Then v2 was pure insanity. I switched from v2 to golang and it felt like I had been punishing myself. This is what really sold me in Go as a language and I’ve used it liberally since then. Nothing beats just being able to get your head around things.
yumraj 5y ago
I can concur. Many years ago, I had used Play v1 to solo develop a reasonably functioning website, in part time. But then came Play v2, and for some reason it never clicked for me. Haven't looked at Ninja. Currently I'm looking at Phoenix as my go-to framework for side projects.
eropple 5y ago
I really enjoyed Play V1. I got some stuff done with V2, but (and I say this as somebody who really liked Scala at the time) I think it absolutely disappeared into the morass and never came back. Ninja is pretty cool. It works well with Kotlin, which is what I reach for today with the JVM, but tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else.
- mwcampbell 5y ago
  > 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.
  - yumraj 5y ago
    > 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..
  - lmm 5y ago
    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 5y ago
      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 5y ago
        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.

mountainriver 5y ago

You could say that again, play v1 was so simple and productive. Then v2 was pure insanity. I switched from v2 to golang and it felt like I had been punishing myself. This is what really sold me in Go as a language and I’ve used it liberally since then. Nothing beats just being able to get your head around things.

yumraj 5y ago

I can concur. Many years ago, I had used Play v1 to solo develop a reasonably functioning website, in part time. But then came Play v2, and for some reason it never clicked for me. Haven't looked at Ninja. Currently I'm looking at Phoenix as my go-to framework for side projects.

eropple 5y ago

I really enjoyed Play V1. I got some stuff done with V2, but (and I say this as somebody who really liked Scala at the time) I think it absolutely disappeared into the morass and never came back. Ninja is pretty cool. It works well with Kotlin, which is what I reach for today with the JVM, but tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else.

mwcampbell 5y ago
> 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.
- yumraj 5y ago
  > 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..
- lmm 5y ago
  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 5y ago
    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 5y ago
      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.