7 ms·

That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark,

That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.

joshlemer 2y ago
What is so bad specifically about play?
- KajMagnus 2y ago
  I use Play, and I think it is a good web framework, nowadays. In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.) And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL. Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen). Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice. Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
- hocuspocus 2y ago
  Like KajMagnus mentioned: - The churn caused by breaking changes in minor versions used to be annoyingly high. - Slick looks neat at first but caused a lot of friction when used by less experienced developers. - The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun. Additionally: - It was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple. - The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter. - Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies. - Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...) - Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly. - Swagger/OpenAPI integration is brittle. I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.
  - KajMagnus 2y ago
    Tapir looks nice, didn't know about. Can I ask, do you use it together with Netty? How fast is it for you? (if you happen to have benchmarked it) Have you tried Vertx with Scala? (Or Spring + Scala, or sth else?) > The introduction of Guice Personally I've wired everything statically at compile time, zero dependency injections. (Felt as if what I did went a tiny bit against the framework, but works fine.)
    - hocuspocus 2y ago
      I use Tapir with http4s as the http server isn't my bottleneck anyway and I like Cats Effect and fs2. But SoftwareMill has done extensive benchmarking to make sure the overhead from Tapir vs calling the http backend directly was insignifiant. I believe Netty is the recommended backend if you want direct style (i.e no effect systems) on Java 21+ virtual threads even though Oracle's Helidon Níma is supported too.
      - KajMagnus 2y ago
        Thanks! Ok, seems direct style is what I would want, after having asked an LLM: it says it's then simpler to debug async call stacks, with Java 21+ virtual threads. Nice to know that there are good alternatives, if time it is some day to migrate away from Play.
  - joshlemer 2y ago
    > Slick Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/ https://scalikejdbc.org/, if not just plain JDBC > It was in state of semi-abandonment for several years Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less. > Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy > Play-JSON depends on Jackson > Standard library Futures are not so nice Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it. The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).

That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.

joshlemer 2y ago

What is so bad specifically about play?

KajMagnus 2y ago
I use Play, and I think it is a good web framework, nowadays. In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.) And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL. Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen). Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice. Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
hocuspocus 2y ago
Like KajMagnus mentioned: - The churn caused by breaking changes in minor versions used to be annoyingly high. - Slick looks neat at first but caused a lot of friction when used by less experienced developers. - The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun. Additionally: - It was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple. - The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter. - Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies. - Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...) - Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly. - Swagger/OpenAPI integration is brittle. I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.
- KajMagnus 2y ago
  Tapir looks nice, didn't know about. Can I ask, do you use it together with Netty? How fast is it for you? (if you happen to have benchmarked it) Have you tried Vertx with Scala? (Or Spring + Scala, or sth else?) > The introduction of Guice Personally I've wired everything statically at compile time, zero dependency injections. (Felt as if what I did went a tiny bit against the framework, but works fine.)
  - hocuspocus 2y ago
    I use Tapir with http4s as the http server isn't my bottleneck anyway and I like Cats Effect and fs2. But SoftwareMill has done extensive benchmarking to make sure the overhead from Tapir vs calling the http backend directly was insignifiant. I believe Netty is the recommended backend if you want direct style (i.e no effect systems) on Java 21+ virtual threads even though Oracle's Helidon Níma is supported too.
    - KajMagnus 2y ago
      Thanks! Ok, seems direct style is what I would want, after having asked an LLM: it says it's then simpler to debug async call stacks, with Java 21+ virtual threads. Nice to know that there are good alternatives, if time it is some day to migrate away from Play.
- joshlemer 2y ago
  > Slick Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/ https://scalikejdbc.org/, if not just plain JDBC > It was in state of semi-abandonment for several years Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less. > Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy > Play-JSON depends on Jackson > Standard library Futures are not so nice Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it. The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).