

Play Framework (full stack Java framework with Scala) v1.2 released - dabeeeenster
http://www.playframework.org/documentation/1.2/releasenotes-1.2

======
robfig
After having chosen Play! for two enterprise projects requiring roughly 1-2
developer years of work, I couldn't be happier with the decision.

 __Play! is by far the best web framework I've ever seen for Java. __

It is as hot as node.js and socket.io combined! I can't really recommend it
highly enough.

======

Strong points:

* A life-changingly fast edit-test loop. (Faster than Django!)

\- Excellent beaning for form parameters (no longer have to mess around with
Integer.parseInt(getParameter("objectId")))

\- Libraries that obviate the crufty old ones, e.g. instead of Apache
WebClient, just use WS.url("google.com ").get(). It has OAuth, Emailers, etc.

\- Support for new technologies, e.g. WebSockets

\- Support for non-blocking IO in imperative-looking code. (e.g. you can
"waitFor()" a Future, which will cause Play! to suspend your request until the
Future is ready, reusing your Thread for another request, and resume where you
left off)

\- Much better interceptor model than J2EE (can apply interceptors to your
entire class, to individual methods by annotating, e.g. @Before, @After,
@Finally)

\- A routes file instead of web.xml

\- Large selection of community modules to do everything from rendering your
template as PDF to inlining CoffeeScript in your page.

\- A framework for running scheduled jobs and for triggering asynchronous jobs
from web requests.

======

Weak points:

\- The default Groovy templates are powerful, but notoriously slow. The
template system is supposed to be pluggable, but I haven't yet found a
templating technology that feels perfect.

\- The heavy use of reflection and bytecode manipulation is what makes things
so convenient, but I can also imagine it being a turn-off for some.

\- The Play! codebase is very light on comments.

======

Give it a shot if you haven't already.

\- Play! Fanboi

~~~
alex_c
I'm trying to choose a framework for a new project, and Play! has really
caught my eye - I'm not really a Java guy, and the whole "enterprise" mindset
is a bit of a turnoff for me, so Play is really tempting.

One of the concerns internally was that it has a much smaller community than
more established frameworks - have you found this to be an issue?

Also, it sounds like you used it for a reasonably large project. How does code
organization and maintainability compare with traditional frameworks?

~~~
robfig
The play-framework Google Group has plenty of activity, and the project
founder (Guillaume Bort) pays attention to it. Check it out at
<https://groups.google.com/forum/#!forum/play-framework>

Code organization is basically up to you. The default organization is the
typical MVC directories, but that's not a requirement for anything (and you
can add other directories / subdirectories as you wish).

The one caveat on code organization is that Play! hot-compiles all code under
its /app directory. My approach to sharing code with other non-Play! projects
is to use "ant" to build a jar, and add that to the classpath of my Play!
project. The end result is that you get hot-compilation of everything specific
to your webapp, but you have to use ant to build code outside of that. I find
it works fine in practice, and if it's a standalone app then you never have to
leave hot-compile land.

Maintainability is great -- Play! makes heavy use of ThreadLocals, so you can
access the current Request, Response, template arguments, etc etc no matter
where you are, without having to pass it all around as method parameters. So
making helper methods is super easy. We created a "helpers" package to put
functionality shared across Controllers and can follow DRY without a problem.

~~~
alex_c
Thanks, that is very helpful.

One more question - you mentioned the Groovy templates are slow, do you mean
as in execution time? Have you run into any performance problems?

------
rkalla
Just another "me too" from a dev who moved to Play! after deciding the choice
between SpringMVC/Struts2/JSF/Wicket made me want to kill myself and go back
to writing ASM.

Play really is as easy/fun to use as people say; rolled out a handful of
simpler apps (few weeks worth of work) and Play! seems to always have some
easy solution to every problem I've run into... never needed to dig deep on
the API to work around or design around anything (I seemed to do this a lot
with JSF and Wicket).

~~~
Cafesolo
Can I ask you specifically what kind of problems you ran into when you tried
Wicket?

------
alec
I tried Play last year and it completely changed the way I thought about Java
- hey, it's actually a nice language if you don't make the libraries so
stuffy.

------
lpolovets
To echo other comments, Play! + Java is awesome and refreshing. However, I
tried Play with Scala a few months ago and found it to be unstable (slower
start-up times and regularly occurring segfaults during code reloading). I'm
hoping v1.2 is a little better in this regard. Has anyone else tried Play with
Scala?

~~~
squidsoup
It would be good to know if Play+Scala will have feature parity with Play+Java
in the future, or if it's always going to be playing catch up. I'm considering
Play for a new project and would prefer to use Scala, but the impression I get
is that the Java version is the primary focus.

------
larrywright
My team has built and released one app built on Play with another about to get
started. It's an excellent choice if you need to deploy on the JVM. It's
everything you love about Rails, but built on Java.

------
mark_l_watson
I am doing some work for a Java EE 6 shop right now, and find Play (on my own
time) to be refreshing. I am not dissing on Java EE 6, but I think that agile
interactive development platforms like Play may end up eating Java EE 6's
lunch.

------
devinfoley
This really sounds great. I can't wait to check it out.

I've been hoping for a Java-based framework that can compete with the Rails
and Djangos for a while. I made the mistake of investing my time in Grails,
and really regret it.

I've been wanting to use Scala for building web apps, but Lift reminds me of
J2EE all over again. Hopefully Play! with Scala can get it right.

~~~
therockhead
What issues did you have with Grails?

------
emehrkay
I implemented play when a php app that I worked on needed access to a jar.
Play made it very simple to create a rest server that called classes in the
jar. I learned a lot of Java too, it was a good experience. I would recommend
it to anyone, hell of a lot easier to get up and running than spring and
anything dealing with tomcat.

------
petervandijck
Shameless plug: if anyone really enjoys Play and Scala, and wants to work at a
Canadian startup, get in touch. It's what we use, we love it.

jobs at gushhq.com or peter @ gushhq.com. <http://blog.getgush.com> You have
to be in Canada.

------
askedrelic
I found Play when looking for a monitoring dashboard last year, an intern from
Digg released something using the Play framework:
<https://github.com/digg/awacs>

It's been not too bad to use.

------
Toddward
Would anyone recommend Play! over Lift?

~~~
icey
I've spent time with both of these frameworks and the answer is "it depends".

I'd recommend Play! over Lift if:

    
    
      * You just want a data entry / CRUD style app
      * You prefer MVC architecture
          - Play! will feel pretty familiar if you've used Rails
      * You don't know Scala
    

I'd recommend Lift over Play! if:

    
    
      * You already know Scala
      * You want to build more "reactive" apps 
         - Lift has excellent AJAX / Comet support built in
      * You enjoy trying new ways of doing things
         - Lift has many unique features, there aren't many similar frameworks
    

They're both fast, have excellent communities, decent documentation (I think
Play's documentation is better today, but Lift's has been improving fairly
rapidly). You can't go wrong with either one.

I should add - you can do AJAX & Comet in Play!. You can do MVC in Lift! One
framework is just more adept than the other by default in their respective
arenas.

~~~
justwrote
continues...

Lift:

* stateful

* no code in the view

* there is more than one way to use Lift

Play!:

* stateless

* code in view: similar to erb files in rails

pros and cons about code in the view: <http://scalate.fusesource.org/code-in-
view.html>

My experience: Well lets say on my next project I'll give "code in view" a try
:)

------
reactor
I tried most of Java frameworks, Wicket, Structs, Tapestry, (few others too,
pyramid, rails) before I settled down with Play!, its awesome framework which
gives me lot peace of mind. It just works in a right way and I'm really
enjoying working with it. Highly recommends over any other framework. You can
use Japid/Cambridge/Mustache as a template if you feel Groovy is slow (but for
a production site, its really fast enough, and its syntax is very intuitive)

------
peregrine
I've been using the Play framework in my classes when I need to work in groups
of students who only know Java and do not know the web and it has been great!

Its quick and easy to get started on and stays out of your way most of the
time. Luckily it has a 'eclipse mode' otherwise I think that would have never
been a reality.

------
jzoidberg
WebSocket support added - outstanding

------
aneth
I experimented with play prior to 1.0 and loved it, but I went back to rails
because I wanted access to more libraries.

Search stack overflow for java payment gateway library and you will find my
as-yet unanswerred question. The java community seems much more intent on
monetizing libraries and having annoying restrictions - in ruby shit is just
out there.

I actually much prefer Scala as a language (although Play support was not
ready then). Ruby is a dog in many ways and common practices in the ruby world
are completely against my philosophy, but hey, it works and I know it.

I'd definitely recommend checking out Play and Scala.

~~~
rlmw
Can you be more specific about what Java libraries you're missing? Is it just
the payment gateway? I think the following is his question:

[http://stackoverflow.com/questions/2242653/java-payment-
gate...](http://stackoverflow.com/questions/2242653/java-payment-gateway-
library)

~~~
aneth
That is my question. At the time there didn't seem to be any easy API for
processing payments across multiple processors, e.g. Paypal and Google.

The question seems pretty specific:

I'm looking for a Java payment gateway library similar to the Rails
active_merchant or the libraries available on many other platforms. I've been
surprised that I've been unable to find one. I'd like something that supports
the major gateways and providers, like Paypal, Google, Amazon, and some direct
merchant account providers like Authorize.net.

Does such a thing exist in the open source world?

~~~
rudiger
You can consider trying what we did:

Wrap Active Merchant in a lightweight web service which exposes a RESTful API
that Java (or any language) can talk to.

~~~
technomancy
Could try JRuby too.

~~~
aneth
Splintering an application into multiple stacks, languages, wrappers, etc.
just to add pretty simple functionality from a library is not a good solution
for a large number of reasons.

Using JRuby or a REST API to a Rails app is the kind of complication to an app
you desperately want to avoid.

~~~
rudiger
It may seem like "pretty simple functionality", but...

Active Merchant "raison d'être" was Shopify's requirements for a simple and
unified API to access _dozens_ of different payment gateways with very
different internal APIs. Abstracting the APIs for dealing with credit cards
and payment processors was core to Shopify's business, and they open-sourced
what could have easily been kept closed. This abstraction is hard work, not
the kind of work I want to do, and I'd rather use their robust library than
roll my own or use another poorly-tested one.

We package and deploy Active Merchant in a single, stand-alone .jar file. We
don't use Rails (Active Merchant works excellently as a stand-alone library).
It's not as complicated as you think.

