7 ms·

Why I'm Moving Away from the Play Framework

118 points by timf 15y ago

kaolinite 15y ago
I'd be very interested to hear people's responses to this post. I've been considering learning Play as I was very impressed with what I saw.
- dkhenry 15y ago
  It is a very well written opinion piece that gives his ( valid ) reasons for not using play any more. That being said he doesn't say anything bad about the framework or the idealogy behind it and in fact laments having to move away from its ease of use. He does bring up the point that Play 1.X is essentially out to pasture at this point. Thats not to say typesafe can't come back and once 2.0 is settled and fix the outstanding bugs , but as far as the community is concerned most have moved on to 2.0 or are aren't experiencing these issues. For my part I have never ran into any serious bugs on my Play apps and services. I would note that I don't have any very large scale deployment, mostly just internal applications. I am however using Play 2.0 as the foundation for my next big project and so far even the RC have proven stable and functional.
  - stevelosh 15y ago
    s/he/she/ s/his/her/
    - deleted 15y ago
      [deleted]
- codemonkeyland 15y ago
  Sounds like the author doesn't understand concurrency or how to set up the unit tests from an IDE with a version of play framework which is only weeks away from being completely replaced.
jemeshsu 15y ago
I'm interested to know what alternative framework the author has chosen in place of Play!.
- timf 15y ago
  She said on Twitter she is looking at Dropwizard: https://github.com/codahale/dropwizard https://github.com/codahale/dropwizard That's focused on RESTful services so presumably also a JS templating tool browser-side or similar.
  - hallnoates 15y ago
    DropWizard, huh? I'd be really careful about anything that overly simplifies opening up CRUD functionality via REST. Be sure to spend some of that time you save looking into the security of your service. Easy generation of RESTful services has bitten many a Rails developer, for example.
oacgnol 15y ago
I'm curious as to specific code examples where the author is having problems. I'm thinking about using Play! or Lift for a pet web app using Scala. Does anyone have experience using either?
- djb_hackernews 15y ago
  I use Play! for my hobby projects and Lift for work. Coming from MVC lift is very bizarre. Having html and javascript inside my scala classes gives me a queasy feeling. I also think Lift is dead. The creator of the project left, the documentation isn't great, View first model isn't popular, very little activity in #lift, very little activity in the lift framework google group. Not good signs.
  - SkyMarshal 15y ago
    > Having html and javascript inside my scala classes gives me a queasy feeling. Yeah that's an interesting tradeoff. I like it because it helps keep code completely out of the html templates, which is a design goal of lift. I tend to work with designers who do HTML/CSS only, not javascript, and I do the backend Scala and frontend Javascript, so that separation of roles works. But if your dev team (as most big ones do) consists of frontend HMTL/CSS designers, frontend Javascript UX devs, and backend devs, then that architecture may not be optimal. > I also think Lift is dead. Far from it. > The creator of the project left Not exactly: 1. He's still a core committer, 2. Advised the founders of Lift Co. [1] - commercial support/SLA for lift projects, 3. Is active on the Lift group [2] (the activity takes place there and at Assembla [3], not Twitter) 4. Continues to present about [4], blog about [5][6], and advocate Lift [7]. 5. Even holds personal office hours every week in San Francisco to support Lift devs, for free. He's just not doing direct commercial consulting on Lift anymore, others have grabbed that torch and are running with it, primarily in SF, London, and India. > the documentation isn't great, True, but improving. The new book from Manning, Lift In Action [8] is excellent. You can buy it from Manning, or obtain it by other means. There are completely free options as well [9]. > View first model isn't popular Popular is not necessarily better [10], unfortunately. However, if you grok view first and still believe MVC is better, Lift also includes an MVC version [11] for you. > very little activity in #lift, The meat of the discussion is on the google group [2], not Twitter. (And it's #liftweb anyway, but admittedly not much difference there either). > very little activity in the lift framework google group. Maybe you're comparing to a mega project like Rails, or maybe you accidentally mistook the stickies at the top for the actual group activity, but there's more than 'very little activity' in the group. Granted, Lift isn't without issues. Getting started via Maven is painful (Pro-tip: use SBT + Lifty [12]). It has a non-trivial learning curve (I actually had to learn Haskell in order to grok Scala in order to use Lift - all worth it - though people coming from the ML family may have an easier ramp-up); has to deal with Scala's versioning and dependency issues (which David Pollack ticked off the Scala community by vocally complaining about, and which SBT does a decent job of mitigating), and does most things differently than the norm. However, it's a superb piece of technology more than worth the effort to learn. It's more inherently secure than any other framework out there, enables a simple architecture (3-tier only, web/app/db, no caching layers), is relatively easily scalable (just add more instances to whichever layer you need to scale), does Ajax and Comet better than anything else, is very productive once you know it (minimal code, no testing necessary for classes of errors the type system or compiler catch), and lots of other excellent stuff [13]. It's evolving, maybe not at the pace of Rails, but it's starting with a far stronger technical architecture, runtime, and Java ecosystem interopability. ----------------------- 1. http://liftweb.com/ http://liftweb.com/ 2. http://groups.google.com/forum/?fromgroups#!forum/liftweb http://groups.google.com/forum/?fromgroups#!forum/liftweb 3. http://assembla.com/wiki/show/liftweb/ http://assembla.com/wiki/show/liftweb/ 4. http://www.infoq.com/presentations/Exploring-Composition-and-Functional-Systems-in-the-Cloud http://www.infoq.com/presentations/Exploring-Composition-and... 5. http://lift.la/ http://lift.la/ 6. http://goodstuff.im/ http://goodstuff.im/ 7. http://visi.io/ http://visi.io/ (see comments on Lift) 8. http://manning.com/perrett/ http://manning.com/perrett/ 9. http://www.assembla.com/spaces/liftweb/wiki/Resources http://www.assembla.com/spaces/liftweb/wiki/Resources; http://richard.dallaway.com/lift-cookbook-an-introduction http://richard.dallaway.com/lift-cookbook-an-introduction 10. https://www.assembla.com/wiki/show/liftweb/View_First https://www.assembla.com/wiki/show/liftweb/View_First 11. http://www.assembla.com/spaces/liftweb/wiki/MVC_(if_you_really_want_it) http://www.assembla.com/spaces/liftweb/wiki/MVC_(if_you_real... 12. https://github.com/harrah/xsbt https://github.com/harrah/xsbt; https://github.com/Lifty/lifty https://github.com/Lifty/lifty 13. http://seventhings.liftweb.net/ http://seventhings.liftweb.net/
abuark 15y ago
I looked into Lift. Steep learning curve. It would be ok for a single person, but a large team coming up to speed on Lift/Scala looks hard. Then I decided to stick with what I know best Ruby/Javascript/Node.
drawkbox 15y ago
I think that any platform has some gotchas especially a 1.x version, however in my experiences with it it was fast and less boilerplate than a normal Java project and we didn't have any of these issues rolling out locally and to Google AppEngine. I'd still only choose it if I had to use Java though. If you can roll with Django you can roll with Play. Although, I always prefer a python microframework such as flask nowadays. I also see how Play is now part of typesafe, so that could get better or worse, but it is the right direction for Java web apps to go.
- halvsjur 15y ago
  I've worked quite a lot with both Java and Python and with Play and Django, and before I tried Play I would've agreed with you. The lightweight nature of Play combined with the speed of the jvm (compared to Python), static typing and IDE support, makes it a winner in my book. I like vim, but wherever I click in a Play project (including in routes, property files and templates), I always end up where I need to be.
JohnTitus 15y ago
So what's the best alternative for a Java shop?
- UK-AL 15y ago
  Depends what your doing... I have JEE6 template project which basically set up with everything configured. This can be nearly as productive as django.
  - benmccann 15y ago
    I was doing basically this before moving to Play 2. I just found there was a lot you had to decide for yourself. You had to pick a persistence layer, roll your own xsrf protection, do your own integration of a JS compiler/minifier, etc. I had something pretty good working, but got tired of having to write the code for every new technology integration myself. The thing I like about Play 2 is that I have an entire community helping me out with these things.
- latchkey 15y ago
  I don't know about 'best', but I certainly can tell you what we've done for our latest project, Voost. https://www.voo.st/ https://www.voo.st/ Google App Engine cause we hate doing sysadmin work. Objectify. Cambridge Template Engine with JEXL. RestEasy/HtmlEasy. Jackson. Guice to bind it all together. Front end is heavily CoffeeScript, Handlebars, Jquery, LabJS, customized bootstrap and various other libraries. We've got a credits page full of links to the above projects... https://www.voo.st/about#credits https://www.voo.st/about#credits Overall, I'm pretty happy with this choice. We've had to do some weird and semi-complicated stuff to integrate it all together, but at this point, it works quite well.
- scylla 15y ago
  We're using Apache Wicket and are pretty happy with it.
  - rkalla 15y ago
    Has Wicket changed to not require so much code? I wrote a handful of apps using Wicket 1.2, 1.3 and 1.4 before realizing I was writing thousands of lines of code to update UI models and backend models that shouldn't be taxing me so much. Used Play for a few projects, but don't like that 2.0 is more or less getting rewritten... don't like Spring... not sure what is left (JEE6 and JSF2? God I don't want to use JSF again unless it changed significantly)
RossDM 15y ago
Valid points about bug fixes and outstanding issues. I think the Play 2 announcement was met with a mixture of trepidation and excitement from the community. If support for 1.2.x was to decrease further then I'd be concerned. For what it's worth, I've been developing a Play (now 1.2.4) app for a year now and it's been a blast. Sometimes you can see the framework's immaturity, but I haven't run into any showstoppers like the author.
xinuc 15y ago
cmiiw, but imho play is too similar with others web framework, like rails. i'd prefer scala community to push lift instead. lift has some great ideas, and has many things to improve.
- SomeOtherGuy 15y ago
  >lift has some great ideas Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks. >i'd prefer scala community to push lift instead The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
- SomeOtherGuy3 15y ago
  >lift has some great ideas Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks. >i'd prefer scala community to push lift instead The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
emehrkay 15y ago
Play made it very very easy for me to target a jar from php. The php-java bridge at the time would start and stop the jvm with every request (I dont know how it stands up today). I did some research and was able to stand up a play server whose routes reflected classes/methods in the jar in about 20 mins. Are there other play-like frameworks for java?
- SkyMarshal 15y ago
  Somebody mentioned Stripes in the blog comments, but it hasn't been update in a year: http://www.stripesframework.org/ http://www.stripesframework.org/ http://sourceforge.net/projects/stripes/ http://sourceforge.net/projects/stripes/ And by '...frameworks for java', do you mean Java specifically, or any JVM language. Several good options for the latter.
aaronblohowiak 15y ago
Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
- scottbessler 15y ago
  I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.
  - stcredzero 15y ago
    I'm not if sure the author understands concurrency. EDIT: Author of the blog post.
    - beersigns 15y ago
      I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
      - bad_user 15y ago
        The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread. Threading is hard, lets go shopping.
djb_hackernews 15y ago
I use Play! frequently. Love it. I maybe be misunderstanding her first point, but I am currently running individual unit tests in IntelliJ for one of my play apps on 1.2.4... I can't speak to her other issues, I've never run in to them.
hp 15y ago
"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework." Fair enough, but I wouldn't switch to an inferior framework over it.
- stcredzero 15y ago
  If that shop is stuck with debugging into a method in HashMap, then they aren't qualified to evaluate whether or not it's in the framework. That said, the developer community needs to address the problem though education, if it's user error (most likely) or come up with enough manpower to be more active in support. After having seen their video, I have to say that the Play! framework folks seem very insightful in their design goals. They hit the nail right on the head in terms of the major usability problems of most Java Web AppServer software.
  - burningout 15y ago
    We use play in all our projects and hit some bugs as well. (Like different versions of classes being in jars and in code -> signature mismatch) It's a great project and no software is without bugs.
    - stcredzero 15y ago
      It's a great project and no software is without bugs. What makes or breaks great software is community and culture.
fauigerzigerk 15y ago
This confirms my bias against frameworks in general and in fact against reusing more code than necessary. And no, I would not write an encryption library myself or re-implement the HTTP protocol. But the disparity between what web frameworks actually do for me in any particular application and the amount of layers and dependencies they introduce boggles my mind. [Edit] If you use maven try mvn dependency:tree
- hp 15y ago
  Play is really not a large amount of code though and it's all in one source tree. It generally doesn't have a lot of "layers" compared to even something like Tomcat; the stack just doesn't get as deep. I've had an easy time digging in to the Play source code when needed. Just one experience fwiw. Sure, it's still a framework.
  - benmccann 15y ago
    Agreed. I fixed a handful of bugs in Play 2 while it was still young and immature and didn't have much difficulty tracking them down despite not knowing any Scala.
    - codemonkeyland 15y ago
      Despite the propaganda Scala's pretty easy to read.
  - fauigerzigerk 15y ago
    I just fail to see much in these frameworks that isn't either trivial or unnecessary or both. But I didn't mean to single out Play by any means.
Egregore 15y ago
I'm switching to Play 2.0 (which is yet in RC3, not yet released) and I think it's a great new framework and I understand them wanting to dedicate more resources to the new framework.
cletus 15y ago
I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes). I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts. Play is a very prescriptive framework but only on a couple of choices do I have an issue. The first is about transactions. Each HTTP request is a transaction. Generally I'm fine with this but you need a way to override or control this (IMHO). Second, I like the mixin approach with controllers (@With(...)). I wish there were something similar with models. Third, and this is the biggest, it doesn't integrate with Maven, which is something I'm very tempted to fork it for. There's no reason it can't be a Maven plugin/archetype, use Maven for dependencies (directly, rather than tortuous syntax in dependencies.yml), etc. Some guy has an alpha version of something like this already when I last looked. Fourth, while I don't necessarily mind that controllers are static (as a way of indicating they're stateless it seems), that's actually an issue for parallellizing tests. Play 2.0 is moving even further away from this and using SBT, which I've never used but heard mixed things about. I can't speak to many of the specifics of this post (eg I only use Play on Linux). Whatever (valid) criticisms you can level against Play I'd still far and away prefer to use it over any other Java Web framework I have used or know about.
- fosk 15y ago
  +1 for Maven
- halvsjur 15y ago
  I've had to work with Play lately, and I find it quite delightful. It's butchering java as a language (or at least what's considered good practice), but since it works so well, you tend to overlook that. I'm also a fan of maven. There's nothing better than checking out a huge project with a great deal of dependencies and just have it build perfectly with a couple of keystrokes. Seems like the play developers (Guillaume et co) went for a clean break with legacy java though. And if you want that, you can't depend on maven. Only had a cursory look at 2.0 so far, but moving further into Scala territory and adopting SBT seems like an interesting move to me. Play is becoming a great vehicle for Web developers who want to ease into a Scala future.
stephen 15y ago
I was surprised to see Typesafe throw its weight behind Play. While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me. Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it understand that and accept its imperfections. I'd rather fix Java proper (or use Scala) than have a web framework think that it's their job to somehow fix a lackluster language. Just seems like it'd lead to a lot of bloat/code in the framework that isn't "just serve this webapp as simply as possible". That being said, what Play got right did look really awesome (the compilation error reporting in particular). Anyway, will be interesting to see what the Play 2.x release will look like, given it looks like Typesafe is having some amount of involvement in it?
- noelwelsh 15y ago
  All the byte-code rewriting has been dropped in Play 2.x. In fact Play 2.x is vastly different beast to Play 1.x, and much superior in my opinion. It's very straightforward, non-magic, and gets stuff done.
- halvsjur 15y ago
  > the compilation error reporting in particular All too familiar if you use Eclipse :)
zred 15y ago
A very interesting look at Play can be found in this presentation: http://spinscale.github.com/play-advanced-concepts.html http://spinscale.github.com/play-advanced-concepts.html The author wrote the Play Framework Cookbook and so it's a presentation from someone that can be considered a bit of an authority on Play (and not someone with an axe to grind). However, the presentation covers a bit of what worries me about Play. Play rewrites the bytecode for things like emulating properties and allowing you to pass whatever you want to the templates and have it automatically name the variables based on their local names in the calling method. For me, the reason to use Java over Python or Ruby would be to move away from some of the behavior used in those languages that can make debugging and static analysis harder. I've used Play for some hobby stuff (and kept up on Play 2.0). Play 2.0 seems to remove the former system for passing variables to the templates in favor of a system where templates accept certain parameters with types (a welcome change for me). However, at least the last time I played with it, Eclipse couldn't tell me what variables and types the template was expecting. I guess Play leaves me feeling like it brings the magic to me without as much ease that Python and Ruby offer (or, at least, without as much familiarity). That might be changing - I think that the changes in the templating for 2.0 show a clear move in that direction. I really wish them well since it's always good to have more good options for development and there's a lot of Java already out there to leverage.
orefalo 15y ago
Think I should mention this link https://github.com/playframework/Play20/wiki/Philosophy https://github.com/playframework/Play20/wiki/Philosophy
orefalo 15y ago
Nobody mentioned this link... https://github.com/playframework/Play20/wiki/Philosophy https://github.com/playframework/Play20/wiki/Philosophy
lfischer 15y ago
As someone marginally involved with the Play project, I would like to point out that, for better or for worse, Play 2.0 is a complete reimplementation of the original design, with a new API and a totally new codebase. Play 2.0 core is now written in Scala (but also exposes a Java API) and relies much less on bytecode manipulation.
ww520 15y ago
While OP has met some problems, I don't see how these would drive him away. I'm curious what framework he's moving to. OP is looking for a silver bullet and there ain't one. Play! is an open source project, so the developers didn't have time to deal with his patch and he got upset. People forgot OS devs don't get paid for their work. Be a little bit more appreciative.
electrotype 15y ago
What I really like about Play is the reverse routing feature. Do you know of any other Java web framework with it? http://www.playframework.org/documentation/1.0/templates#Actionsor http://www.playframework.org/documentation/1.0/templates#Act... and http://www.playframework.org/documentation/1.0/routes#reverse http://www.playframework.org/documentation/1.0/routes#revers...
hn_should 15y ago
"Why I'm Moving Away from the Play Framework and you should too"
error 15y ago
Play! is one the best things that has happened to java in the last 10 years! From the post I understood that she was pissed because they did not accept her fix on testing the app from the IDE. The second point was that there is a bug in the framework that they could not find... it seems though as the bug is in their application. (concurrent modification of a Map is a problem in java not Play!) It's a pity to give up such a great framework for silly reasons. Every time I have to switch to another framework (especially jsf) I want to shoot myself. Anyway... good luck finding another good java framework.

118 points by timf 15y ago

I'd be very interested to hear people's responses to this post. I've been considering learning Play as I was very impressed with what I saw.

dkhenry 15y ago
It is a very well written opinion piece that gives his ( valid ) reasons for not using play any more. That being said he doesn't say anything bad about the framework or the idealogy behind it and in fact laments having to move away from its ease of use. He does bring up the point that Play 1.X is essentially out to pasture at this point. Thats not to say typesafe can't come back and once 2.0 is settled and fix the outstanding bugs , but as far as the community is concerned most have moved on to 2.0 or are aren't experiencing these issues. For my part I have never ran into any serious bugs on my Play apps and services. I would note that I don't have any very large scale deployment, mostly just internal applications. I am however using Play 2.0 as the foundation for my next big project and so far even the RC have proven stable and functional.
- stevelosh 15y ago
  s/he/she/ s/his/her/
  - deleted 15y ago
    [deleted]
codemonkeyland 15y ago
Sounds like the author doesn't understand concurrency or how to set up the unit tests from an IDE with a version of play framework which is only weeks away from being completely replaced.

jemeshsu 15y ago

I'm interested to know what alternative framework the author has chosen in place of Play!.

timf 15y ago
She said on Twitter she is looking at Dropwizard: https://github.com/codahale/dropwizard https://github.com/codahale/dropwizard That's focused on RESTful services so presumably also a JS templating tool browser-side or similar.
- hallnoates 15y ago
  DropWizard, huh? I'd be really careful about anything that overly simplifies opening up CRUD functionality via REST. Be sure to spend some of that time you save looking into the security of your service. Easy generation of RESTful services has bitten many a Rails developer, for example.

oacgnol 15y ago

I'm curious as to specific code examples where the author is having problems. I'm thinking about using Play! or Lift for a pet web app using Scala. Does anyone have experience using either?

djb_hackernews 15y ago
I use Play! for my hobby projects and Lift for work. Coming from MVC lift is very bizarre. Having html and javascript inside my scala classes gives me a queasy feeling. I also think Lift is dead. The creator of the project left, the documentation isn't great, View first model isn't popular, very little activity in #lift, very little activity in the lift framework google group. Not good signs.
- SkyMarshal 15y ago
  > Having html and javascript inside my scala classes gives me a queasy feeling. Yeah that's an interesting tradeoff. I like it because it helps keep code completely out of the html templates, which is a design goal of lift. I tend to work with designers who do HTML/CSS only, not javascript, and I do the backend Scala and frontend Javascript, so that separation of roles works. But if your dev team (as most big ones do) consists of frontend HMTL/CSS designers, frontend Javascript UX devs, and backend devs, then that architecture may not be optimal. > I also think Lift is dead. Far from it. > The creator of the project left Not exactly: 1. He's still a core committer, 2. Advised the founders of Lift Co. [1] - commercial support/SLA for lift projects, 3. Is active on the Lift group [2] (the activity takes place there and at Assembla [3], not Twitter) 4. Continues to present about [4], blog about [5][6], and advocate Lift [7]. 5. Even holds personal office hours every week in San Francisco to support Lift devs, for free. He's just not doing direct commercial consulting on Lift anymore, others have grabbed that torch and are running with it, primarily in SF, London, and India. > the documentation isn't great, True, but improving. The new book from Manning, Lift In Action [8] is excellent. You can buy it from Manning, or obtain it by other means. There are completely free options as well [9]. > View first model isn't popular Popular is not necessarily better [10], unfortunately. However, if you grok view first and still believe MVC is better, Lift also includes an MVC version [11] for you. > very little activity in #lift, The meat of the discussion is on the google group [2], not Twitter. (And it's #liftweb anyway, but admittedly not much difference there either). > very little activity in the lift framework google group. Maybe you're comparing to a mega project like Rails, or maybe you accidentally mistook the stickies at the top for the actual group activity, but there's more than 'very little activity' in the group. Granted, Lift isn't without issues. Getting started via Maven is painful (Pro-tip: use SBT + Lifty [12]). It has a non-trivial learning curve (I actually had to learn Haskell in order to grok Scala in order to use Lift - all worth it - though people coming from the ML family may have an easier ramp-up); has to deal with Scala's versioning and dependency issues (which David Pollack ticked off the Scala community by vocally complaining about, and which SBT does a decent job of mitigating), and does most things differently than the norm. However, it's a superb piece of technology more than worth the effort to learn. It's more inherently secure than any other framework out there, enables a simple architecture (3-tier only, web/app/db, no caching layers), is relatively easily scalable (just add more instances to whichever layer you need to scale), does Ajax and Comet better than anything else, is very productive once you know it (minimal code, no testing necessary for classes of errors the type system or compiler catch), and lots of other excellent stuff [13]. It's evolving, maybe not at the pace of Rails, but it's starting with a far stronger technical architecture, runtime, and Java ecosystem interopability. ----------------------- 1. http://liftweb.com/ http://liftweb.com/ 2. http://groups.google.com/forum/?fromgroups#!forum/liftweb http://groups.google.com/forum/?fromgroups#!forum/liftweb 3. http://assembla.com/wiki/show/liftweb/ http://assembla.com/wiki/show/liftweb/ 4. http://www.infoq.com/presentations/Exploring-Composition-and-Functional-Systems-in-the-Cloud http://www.infoq.com/presentations/Exploring-Composition-and... 5. http://lift.la/ http://lift.la/ 6. http://goodstuff.im/ http://goodstuff.im/ 7. http://visi.io/ http://visi.io/ (see comments on Lift) 8. http://manning.com/perrett/ http://manning.com/perrett/ 9. http://www.assembla.com/spaces/liftweb/wiki/Resources http://www.assembla.com/spaces/liftweb/wiki/Resources; http://richard.dallaway.com/lift-cookbook-an-introduction http://richard.dallaway.com/lift-cookbook-an-introduction 10. https://www.assembla.com/wiki/show/liftweb/View_First https://www.assembla.com/wiki/show/liftweb/View_First 11. http://www.assembla.com/spaces/liftweb/wiki/MVC_(if_you_really_want_it) http://www.assembla.com/spaces/liftweb/wiki/MVC_(if_you_real... 12. https://github.com/harrah/xsbt https://github.com/harrah/xsbt; https://github.com/Lifty/lifty https://github.com/Lifty/lifty 13. http://seventhings.liftweb.net/ http://seventhings.liftweb.net/

abuark 15y ago

I looked into Lift. Steep learning curve. It would be ok for a single person, but a large team coming up to speed on Lift/Scala looks hard. Then I decided to stick with what I know best Ruby/Javascript/Node.

drawkbox 15y ago

I think that any platform has some gotchas especially a 1.x version, however in my experiences with it it was fast and less boilerplate than a normal Java project and we didn't have any of these issues rolling out locally and to Google AppEngine. I'd still only choose it if I had to use Java though. If you can roll with Django you can roll with Play. Although, I always prefer a python microframework such as flask nowadays. I also see how Play is now part of typesafe, so that could get better or worse, but it is the right direction for Java web apps to go.

halvsjur 15y ago
I've worked quite a lot with both Java and Python and with Play and Django, and before I tried Play I would've agreed with you. The lightweight nature of Play combined with the speed of the jvm (compared to Python), static typing and IDE support, makes it a winner in my book. I like vim, but wherever I click in a Play project (including in routes, property files and templates), I always end up where I need to be.

JohnTitus 15y ago

So what's the best alternative for a Java shop?

UK-AL 15y ago
Depends what your doing... I have JEE6 template project which basically set up with everything configured. This can be nearly as productive as django.
- benmccann 15y ago
  I was doing basically this before moving to Play 2. I just found there was a lot you had to decide for yourself. You had to pick a persistence layer, roll your own xsrf protection, do your own integration of a JS compiler/minifier, etc. I had something pretty good working, but got tired of having to write the code for every new technology integration myself. The thing I like about Play 2 is that I have an entire community helping me out with these things.
latchkey 15y ago
I don't know about 'best', but I certainly can tell you what we've done for our latest project, Voost. https://www.voo.st/ https://www.voo.st/ Google App Engine cause we hate doing sysadmin work. Objectify. Cambridge Template Engine with JEXL. RestEasy/HtmlEasy. Jackson. Guice to bind it all together. Front end is heavily CoffeeScript, Handlebars, Jquery, LabJS, customized bootstrap and various other libraries. We've got a credits page full of links to the above projects... https://www.voo.st/about#credits https://www.voo.st/about#credits Overall, I'm pretty happy with this choice. We've had to do some weird and semi-complicated stuff to integrate it all together, but at this point, it works quite well.
scylla 15y ago
We're using Apache Wicket and are pretty happy with it.
- rkalla 15y ago
  Has Wicket changed to not require so much code? I wrote a handful of apps using Wicket 1.2, 1.3 and 1.4 before realizing I was writing thousands of lines of code to update UI models and backend models that shouldn't be taxing me so much. Used Play for a few projects, but don't like that 2.0 is more or less getting rewritten... don't like Spring... not sure what is left (JEE6 and JSF2? God I don't want to use JSF again unless it changed significantly)

RossDM 15y ago

Valid points about bug fixes and outstanding issues. I think the Play 2 announcement was met with a mixture of trepidation and excitement from the community. If support for 1.2.x was to decrease further then I'd be concerned. For what it's worth, I've been developing a Play (now 1.2.4) app for a year now and it's been a blast. Sometimes you can see the framework's immaturity, but I haven't run into any showstoppers like the author.

xinuc 15y ago

cmiiw, but imho play is too similar with others web framework, like rails. i'd prefer scala community to push lift instead. lift has some great ideas, and has many things to improve.

SomeOtherGuy 15y ago
>lift has some great ideas Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks. >i'd prefer scala community to push lift instead The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
SomeOtherGuy3 15y ago
>lift has some great ideas Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks. >i'd prefer scala community to push lift instead The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.

emehrkay 15y ago

Play made it very very easy for me to target a jar from php. The php-java bridge at the time would start and stop the jvm with every request (I dont know how it stands up today). I did some research and was able to stand up a play server whose routes reflected classes/methods in the jar in about 20 mins. Are there other play-like frameworks for java?

SkyMarshal 15y ago
Somebody mentioned Stripes in the blog comments, but it hasn't been update in a year: http://www.stripesframework.org/ http://www.stripesframework.org/ http://sourceforge.net/projects/stripes/ http://sourceforge.net/projects/stripes/ And by '...frameworks for java', do you mean Java specifically, or any JVM language. Several good options for the latter.

aaronblohowiak 15y ago

Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...

scottbessler 15y ago
I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.
- stcredzero 15y ago
  I'm not if sure the author understands concurrency. EDIT: Author of the blog post.
  - beersigns 15y ago
    I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own. EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
    - bad_user 15y ago
      The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread. Threading is hard, lets go shopping.

djb_hackernews 15y ago

I use Play! frequently. Love it. I maybe be misunderstanding her first point, but I am currently running individual unit tests in IntelliJ for one of my play apps on 1.2.4... I can't speak to her other issues, I've never run in to them.

hp 15y ago

"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework." Fair enough, but I wouldn't switch to an inferior framework over it.

stcredzero 15y ago
If that shop is stuck with debugging into a method in HashMap, then they aren't qualified to evaluate whether or not it's in the framework. That said, the developer community needs to address the problem though education, if it's user error (most likely) or come up with enough manpower to be more active in support. After having seen their video, I have to say that the Play! framework folks seem very insightful in their design goals. They hit the nail right on the head in terms of the major usability problems of most Java Web AppServer software.
- burningout 15y ago
  We use play in all our projects and hit some bugs as well. (Like different versions of classes being in jars and in code -> signature mismatch) It's a great project and no software is without bugs.
  - stcredzero 15y ago
    It's a great project and no software is without bugs. What makes or breaks great software is community and culture.

fauigerzigerk 15y ago

This confirms my bias against frameworks in general and in fact against reusing more code than necessary. And no, I would not write an encryption library myself or re-implement the HTTP protocol. But the disparity between what web frameworks actually do for me in any particular application and the amount of layers and dependencies they introduce boggles my mind. [Edit] If you use maven try mvn dependency:tree

hp 15y ago
Play is really not a large amount of code though and it's all in one source tree. It generally doesn't have a lot of "layers" compared to even something like Tomcat; the stack just doesn't get as deep. I've had an easy time digging in to the Play source code when needed. Just one experience fwiw. Sure, it's still a framework.
- benmccann 15y ago
  Agreed. I fixed a handful of bugs in Play 2 while it was still young and immature and didn't have much difficulty tracking them down despite not knowing any Scala.
  - codemonkeyland 15y ago
    Despite the propaganda Scala's pretty easy to read.
- fauigerzigerk 15y ago
  I just fail to see much in these frameworks that isn't either trivial or unnecessary or both. But I didn't mean to single out Play by any means.

Egregore 15y ago

I'm switching to Play 2.0 (which is yet in RC3, not yet released) and I think it's a great new framework and I understand them wanting to dedicate more resources to the new framework.

cletus 15y ago

I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes). I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts. Play is a very prescriptive framework but only on a couple of choices do I have an issue. The first is about transactions. Each HTTP request is a transaction. Generally I'm fine with this but you need a way to override or control this (IMHO). Second, I like the mixin approach with controllers (@With(...)). I wish there were something similar with models. Third, and this is the biggest, it doesn't integrate with Maven, which is something I'm very tempted to fork it for. There's no reason it can't be a Maven plugin/archetype, use Maven for dependencies (directly, rather than tortuous syntax in dependencies.yml), etc. Some guy has an alpha version of something like this already when I last looked. Fourth, while I don't necessarily mind that controllers are static (as a way of indicating they're stateless it seems), that's actually an issue for parallellizing tests. Play 2.0 is moving even further away from this and using SBT, which I've never used but heard mixed things about. I can't speak to many of the specifics of this post (eg I only use Play on Linux). Whatever (valid) criticisms you can level against Play I'd still far and away prefer to use it over any other Java Web framework I have used or know about.

fosk 15y ago
+1 for Maven
halvsjur 15y ago
I've had to work with Play lately, and I find it quite delightful. It's butchering java as a language (or at least what's considered good practice), but since it works so well, you tend to overlook that. I'm also a fan of maven. There's nothing better than checking out a huge project with a great deal of dependencies and just have it build perfectly with a couple of keystrokes. Seems like the play developers (Guillaume et co) went for a clean break with legacy java though. And if you want that, you can't depend on maven. Only had a cursory look at 2.0 so far, but moving further into Scala territory and adopting SBT seems like an interesting move to me. Play is becoming a great vehicle for Web developers who want to ease into a Scala future.

stephen 15y ago

I was surprised to see Typesafe throw its weight behind Play. While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me. Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it understand that and accept its imperfections. I'd rather fix Java proper (or use Scala) than have a web framework think that it's their job to somehow fix a lackluster language. Just seems like it'd lead to a lot of bloat/code in the framework that isn't "just serve this webapp as simply as possible". That being said, what Play got right did look really awesome (the compilation error reporting in particular). Anyway, will be interesting to see what the Play 2.x release will look like, given it looks like Typesafe is having some amount of involvement in it?

noelwelsh 15y ago
All the byte-code rewriting has been dropped in Play 2.x. In fact Play 2.x is vastly different beast to Play 1.x, and much superior in my opinion. It's very straightforward, non-magic, and gets stuff done.
halvsjur 15y ago
> the compilation error reporting in particular All too familiar if you use Eclipse :)

zred 15y ago

A very interesting look at Play can be found in this presentation: http://spinscale.github.com/play-advanced-concepts.html http://spinscale.github.com/play-advanced-concepts.html The author wrote the Play Framework Cookbook and so it's a presentation from someone that can be considered a bit of an authority on Play (and not someone with an axe to grind). However, the presentation covers a bit of what worries me about Play. Play rewrites the bytecode for things like emulating properties and allowing you to pass whatever you want to the templates and have it automatically name the variables based on their local names in the calling method. For me, the reason to use Java over Python or Ruby would be to move away from some of the behavior used in those languages that can make debugging and static analysis harder. I've used Play for some hobby stuff (and kept up on Play 2.0). Play 2.0 seems to remove the former system for passing variables to the templates in favor of a system where templates accept certain parameters with types (a welcome change for me). However, at least the last time I played with it, Eclipse couldn't tell me what variables and types the template was expecting. I guess Play leaves me feeling like it brings the magic to me without as much ease that Python and Ruby offer (or, at least, without as much familiarity). That might be changing - I think that the changes in the templating for 2.0 show a clear move in that direction. I really wish them well since it's always good to have more good options for development and there's a lot of Java already out there to leverage.

orefalo 15y ago

Think I should mention this link https://github.com/playframework/Play20/wiki/Philosophy https://github.com/playframework/Play20/wiki/Philosophy

orefalo 15y ago

Nobody mentioned this link... https://github.com/playframework/Play20/wiki/Philosophy https://github.com/playframework/Play20/wiki/Philosophy

lfischer 15y ago

As someone marginally involved with the Play project, I would like to point out that, for better or for worse, Play 2.0 is a complete reimplementation of the original design, with a new API and a totally new codebase. Play 2.0 core is now written in Scala (but also exposes a Java API) and relies much less on bytecode manipulation.

ww520 15y ago

While OP has met some problems, I don't see how these would drive him away. I'm curious what framework he's moving to. OP is looking for a silver bullet and there ain't one. Play! is an open source project, so the developers didn't have time to deal with his patch and he got upset. People forgot OS devs don't get paid for their work. Be a little bit more appreciative.

electrotype 15y ago

What I really like about Play is the reverse routing feature. Do you know of any other Java web framework with it? http://www.playframework.org/documentation/1.0/templates#Actionsor http://www.playframework.org/documentation/1.0/templates#Act... and http://www.playframework.org/documentation/1.0/routes#reverse http://www.playframework.org/documentation/1.0/routes#revers...

hn_should 15y ago

"Why I'm Moving Away from the Play Framework and you should too"

error 15y ago

Play! is one the best things that has happened to java in the last 10 years! From the post I understood that she was pissed because they did not accept her fix on testing the app from the IDE. The second point was that there is a bug in the framework that they could not find... it seems though as the bug is in their application. (concurrent modification of a Map is a problem in java not Play!) It's a pity to give up such a great framework for silly reasons. Every time I have to switch to another framework (especially jsf) I want to shoot myself. Anyway... good luck finding another good java framework.