May 3, 2012

Impressions of Play! Framework 1.2.4 vs 2.0

Unless your a web application developer, what follows won’t be that interesting…

Early on in the development process of, we adopted the 1.2.x branch of the Play! Framework. For those who don’t know, Play! is a Java-based web application development framework that was finally able to provide for the Java community a comparable alternative to Ruby on Rails and Django. Its light-weight, simple, and designed for rapid application development from start-to-finish.

So far we couldn’t be happier with our choice, and have been excited to see support and adoption for Play! increase over the last year, with major hosting platforms like Heroku now supporting it natively in their stack ( and players like LinkedIn taking a serious look at it (

With the recent introduction of Play 2.0 though, there seems to be a large amount of fear, uncertainty, and doubt (FUD) regarding whether new users should use the 1.2.x or the 2.0 branch of Play!. Having recently evaluated 2.0 ourselves, we thought we’d share our initial impressions of 2.0, and how it contrasts to our experience developing against the 1.2.x branch.

Play! 1.2.4 vs 2.0:

Currently, the two main reasons that justify adopting Play 2.0 over 1.2.4 are if:

  1. You want to do development in Scala instead of Java
  2. Your app needs to keep 10,000 or more concurrent connections open for 20 or more minutes, streaming data in real time… without consuming 10,000 threads in the JVM. (This use case is the entire reason for the development of Play 2.0)

Otherwise, Play 1.2.4 seems to be the way to go.

Play 2.0 should really have a new name like Play Scala or Play Safe, as it isn’t an incremental upgrade from the Play 1.x.x branch, but instead a completely new and different framework with its own set of tradeoffs.

As it stands today, Play 1.2.4 is the best light-weight Java Framework we’ve found, where simplicity and rapid application development are a priority, while still providing easy customization and impressive production-level scalability. Play 2.0 on the other hand really isn’t the best of anything today (maybe the best Scala framework), but it also isn’t intended to be. It’s intended to be the best framework around in 2 years… for the types of apps people will increasingly be building in 2 years time.

Here is a further breakdown of the two frameworks:

Play 1.2.4:


  • Written entirely in Java.
  • Its easy, easy, easy!
    • Getting Started - You can pick it up and deploy an app in less than an hour
    • Development - Designed for Rapid Application Development
      • Hot reloading. You don’t have stop and restart you application server each time you make a change. You make a change, save it… and in less than a second you can reload your webpage and see the change in action.
      • Good error reporting if the change you made breaks something
    • Maintenance - Easy to understand, debug, and customize both your application and the framework itself
      • 90% of the code base is easy to understand
      • Creating a custom build of the framework could not be easier. You can build your own version of the framework in seconds, and start developing against it immediately.
  • Tied to JPA/Hibernate for persistence. We’ve found Hibernate easy to use, so this is a “Pro” from our perspective.
  • Stateless. All state info is carried through the URL parameters.
  • Feature complete. Product of 4 or more years of development by an excellent team (Zenexity) and with a large developer community now behind it.


  • Feature complete. New releases will only address bugs, with major features only coming from the larger developer community in the form of Modules.
    • Zenexity (the IT/development team behind Play!) is squarely focused on the the future… Play 2.0.
    • Getting a 1.x.x question answered in the Google Group is noticeably harder now that most core Play! developers are focused on 2.0.
  • Uncertainty. The 1.2.4 vs 2.0 debate is actively raging, with a lot of FUD swirling around.
    • Will this turn away new adopters of Play at what may be a critical point? There is so much love out there for Play 1.x.x we certainly hope not.
  • Long polling requests and extended Jobs take a little bit of time to optimize/figure out.

Play 2.0:


  • Designed for the future of web applications… massively concurrent, prolonged connections with real-time updating, notification etc. Check out this demo as an example: 
  • Zenexity is betting their future on it, and we wouldn’t want to bet against their lead developer, Guillaume Bort. This is based on the success of 1.x.x, and Guillaume and team’s knowledge and dedication to Play! as witnessed in the Play! Google Group and support forums ( was a cloud-based hosting platform for Play!… however was recently deprecated by Zenexity, with the recommendation that users switch to Heroku).
  • Part of the official TypeSafe stack ( This could be important to some larger, corporate organizations going forward.
  • More flexible. Meant to be the do all, be all framework for when you want to use the Java Virtual Machine.
  • Better type safety/error checking especially within templates/views, Routes. With 1.2.4 you won’t notice a template error until you compile and ping the app. This hasn’t been a problem for us though as error reporting is so good once an error arises.


  • Harder to debug, and if you are a non-Scala developer you will encounter code you don’t understand. This is because:
    • Written in Scala. Although it also supports Java API, and you can replace the default Scala components for their Java counterparts (Scala Templating Engine for Groovy, etc.).
    • Increased complexity. Suffers from trying to do everything, best at nothing problem, and in the process loses some of the simplicity that made everyone love the 1.x.x branch.
      • Complexity is evidenced by the size of your apps slug when deployed on Heroku. which uses 1.2.4 has a Heroku slug size of 38MB, whereas the default out-of-the-box 2.0 app uses  77MB of the 100MB slug size offered by Heroku.
  • Code compile time is slower (10 seconds vs essentially instant in 1.2.4). Mainly due to the Scala templating engine (vs Groovy in 1.2.4) and because more code is precompiled vs dynamic. This means:
    • Agile development is slower. A funny quote we came across… “Maybe in America you compile Scala code, but here in Russia Scala code compile you. It hurts!”
    • On the other hand, memory footprint of app in production is supposed to be smaller and the the app more performant particularly in the concurrent user use case.
    • Zenexity has mentioned they are actively focused on bringing this compile time down.
  • Favors Ebean (which we are unfamiliar with) vs Hibernate, but as mentioned above you can switch over to Hibernate if you prefer. This may actually be a Pro, we just aren’t familiar enough with Ebean.
  • It’s new, so suffers from things you would expect:

Using 1.2.x for now:

Over at Awfbeat we care a lot about the Play! framework and get excited to see its adoption increase. From everyone we’ve interacted with in the last year, the 1.x.x branch seems to be universally loved for its simplicity, and for ourselves we’ve been nothing but impressed at how easy it was to pick-up and run with.

As we aren’t looking to make a switch to Scala and the massive concurrency use case isn’t important to us right now, we are holding off on adoption of 2.0. We look forward though to seeing 2.0 evolve and improve over the next year or two, as we are sure it will with such a strong core team behind it. We also hope that Zenexity and team will continue to support 1.2.x branch, as they’ve said they will. With a new release of the 1.2.x branch coming out just two days ago ( it appears they are.

More Info:

For some more info and impressions of Play! 1.2.x vs 2.0 check out the following posts:

Blog comments powered by Disqus