
Why I'm Moving Away from the Play Framework - timf
http://whilefalse.blogspot.com/2012/03/why-im-moving-away-from-play-framework.html
======
cletus
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.

~~~
eta_carinae
Good analysis.

I like Play overall but two things concern me, both related: 1) they are
moving toward Scala and 2) they are adopting sbt.

This looks to me more like a "picking a shiny toy" move than something that is
being done to benefit users (Scala is still quite a marginal language and sbt
is very controversial, even among Scala enthusiasts).

~~~
thebluesky
They support both Java and Scala so not really an issue. In any event their
support for Scala is the very reason I am looking @ play.

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

------
hp
"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
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
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
_It's a great project and no software is without bugs._

What makes or breaks great software is community and culture.

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

------
zred
A very interesting look at Play can be found in this presentation:
<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.

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

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

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

------
kaolinite
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
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
s/he/she/

s/his/her/

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

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

~~~
timf
She said on Twitter she is looking at Dropwizard:
<https://github.com/codahale/dropwizard>

That's focused on RESTful services so presumably also a JS templating tool
browser-side or similar.

~~~
hallnoates
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.

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

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

~~~
Egregore
Are you saying that creator of Lift David Pollak left? Can you provide some
links?

~~~
chillax
He stepped down as dictator at least. See "Committer team maturing" here:
<http://goodstuff.im/happy-5th-birthday-lift>

~~~
SkyMarshal
Which, fwiw, is a good sign, that the project is self-sustaining enough that
the founder can hand off his baby to the community around it.

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

------
electrotype
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#Act...](http://www.playframework.org/documentation/1.0/templates#Actionsor)
and
[http://www.playframework.org/documentation/1.0/routes#revers...](http://www.playframework.org/documentation/1.0/routes#reverse)

------
emehrkay
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
Somebody mentioned Stripes in the blog comments, but it hasn't been update in
a year:

<http://www.stripesframework.org/>

<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
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
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
I'm not if sure the author understands concurrency.

EDIT: Author of the blog post.

~~~
beersigns
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
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.

~~~
hythloday
Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan
memory footprint). Wrapping your HashMap with Collections.synchronizedMap
gives you a blocking threadsafe HashMap.

~~~
runT1ME
ConcurrentHashMap is not lock free, it uses lock striping across multiple
buckets.

~~~
hythloday
I stand corrected.

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

------
fauigerzigerk
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
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
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
Despite the propaganda Scala's pretty easy to read.

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

------
hn_should
"Why I'm Moving Away from the Play Framework _and you should too_ "

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

~~~
mosburger
I've never gotten a chance to try out Play, I'm no longer doing any JVM
stuff... but back when I was a Java guy, my favorite java web framework was
Stripes: <http://www.stripesframework.org/display/stripes/Home>

I've never really understood why Stripes hasn't "caught on." It's simplicity
is wonderful.

~~~
stickfigure
Stripes was pretty much subsumed by JAX-RS. There are a few rough edges
surrounding html rendering (thus microframeworks like Htmleasy) but for the
most part, Stripes is no longer necessary.

Most of the history of Java web frameworks focused on ways to make form
processing easier. Nobody (sane) does html form processing anymore. The
"framework" needs to be little more than a way to render html templates and an
rpc mechanism.

------
orefalo
Nobody mentioned this link...
<https://github.com/playframework/Play20/wiki/Philosophy>

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

