What I love and hate about Play 1

Overview

Play 2 has been announced a few weeks ago.

I am currently working on a project based on version 1 of this framework, as I am envisaging a migration, I decided to write two blog posts about this experience. The text below contains my personal thoughts on Play 1, I’ll try at a later stage to hunt for some time to use this as a comparison point for my feed-back on Play 2 and the migration process (if I confirm it should happen…)

Here are some major characteristics of Play (just check their online docs for more details, that is not the point of this post):

• Web framework for Java and/or Scala
• Not based on servlet, although a project can be converted to a war package
• No server-side session
• Java controller methods are public static void

Pros

Hot reload
This is the major selling point of Play: change some java class in your IDE, save and you directly get the result on the browser. Actually, the whole process is so fast that the critical factor now is the speed at which you are able to save then switch to the browser and hit refresh!

This also works when only editing javascripts of CSS files, so fine tuning the layout of the page get much easier than it used to be. Play is not the only one in the Java ecosystem offering this functionality nowadays (Grails and JRebel  are two famous examples), this will probably become the norm at some point in the future.

Smoothest debugging experience I’ve seen

Play is so good at providing useful feedback about problems during the development phase that you have to be careful not developing the habit of doing everything by trial and error. Here are the three sources of information I’ve been using :

• Errors displayed on the browser: Play shows you directly in the browser the source code where the exception happened, together with the error message (see the illustration in Play online doc). This is extremelly useful.

• For rare cases when this is not enough or not working, connecting the Eclipse debugger is just two mouse clicks away and does not require any restart or redeployment of the application. It takes just a few seconds in order to start or stop following the execution process and inspecting variable values from the Eclipse debugger.

•  Unrelated to Play: the above is nicely completed by the Chrome DevTools which allows you to inspect CSS/javascript/HTML and networks activity on browser side at runtime.

Clean navigation

Play implements by default the Post-Redirect-Get pattern for form submission, it provides an easy way to map Java controller methods to URL and to redirect requests from one controller to another, it lets you define quickly what is submitted with an HTTP POST or a GET,… This all lets you design a website where all pages are nicely bookmarkable and where the browser back and refresh buttons work correctly.

No browser-side mess

Play does not interfere with browser-side development. Besides, Play provides non intrusive jQuery hooks in order to directly POST or GET data to server side Java methods and receive HTML or JSON or anything back in response. My previous experience with JSF was much more difficult at that level.

Easy

Play in general is very easy to use and to learn, the documentation is not the most complete I’ve see but still very acceptable and the forum is very active.

Cons

Those advantages are very strong and are the reasons I am a fan of Play. Now one must be aware that not many things come for free…

Play is an isolated OVNI!

Rejecting the old servlet standard (plus a lot of hard work, I guess) was apparently necessary to achieve the above great results but it also makes the integration with 3rd party libraries or framework more difficult than we are used to.  It even gives at times a vendor locking feeling. In particular here a few unexpected pain points I went through:

• Spring integration: given that Spring is currently used in so many existing applications, I was surprised it is not supported by default and requires a community provided module. This modules lets us benefit from the hot-reload functionality with Spring beans, but I have not yet been able to let it recognize the great Spring MongoDB Repositories.
• Cloudfoundry: the feature I love the most about CF is the ability to “instantiate” and bind services (like DB instances, queueing servers, …) to your application with two simple VMC command lines plus one line in the Spring application context. I finally could successfully deploy my Play application to Cloudfoundry but it required more investigations and hacking than I expected. These efforts defeated a bit the point of using CF.
• Maven support. Now given that Play takes a revolutionary approach to deployment and packaging, friction with Maven comes as no surprise. Still, am I now supposed to resolve my dependencies manually? There’s a community provided module that takes care of integrating with Maven for this, developed against an outdated version of Play. As mentioned in the comment from @RossDM below, Play actually does provide a mechanism based on Ivy for dependency resolution, see more info in the Play dependency management page and in this blog post.

Play is young

• Tooling is limited: Eclipse support exists but code completion is almost inexistent. I understand plugins for TextMate and emacs seem to be better, I have not tried them.
• As mentioned above, Play 2 is coming… and is not going to be backward compatible with Play 1. I am very excited about Play 2 and the whole inclusion inside the Typesafe stack, however if I had recommended Play 1 to a client 6 months ago, I’m not sure I’d be able to explain him how “cool” the whole migration process would be…

Conclusion

Sometimes I feel that us IT guys are more subject to fashion than teenage girls!  A lot of what has been written over REST vs SOAP, NOSQL, Oracle, Apple, Scala, dynamically typed languages… were more of the emotional and “I defend my land” category than a rational inspection of things.  While I have to confess I am usually part of the enthusiastic crowd myself, back to real life, in most of the situations I encounter in my day time job, recommending to my clients to keep a somehow conservative stance toward the technology hype is usually the approach that makes most sense.

Standard and innovation are two very noble but opposite goals that both bring huge value to technology. Play clearly took party of the second one: it shakes the Java Web world in a positive way and brings new benefits to web development ease, but like any innovation, it is a fast moving target.

No matter how much I love Play 1, I would definitely not recommend any big company (especially non-IT only companies) involved in a long internal project to bet on it. IT-only company or motivated IT groups could however definitely get big benefits and pleasure from it. Even if the productivity boost is a bit reduced because of unusual difficulties in 3^rd party integration, it is still a very fast and sexy Web development framework.