Why Did I Fall in Love with Play! Framework?
Some time ago, I was the tech lead for a few very large deployments on the Real Estate market for companies like Fannie Mae, Freddie Mac, Foreclosure.com and HUD. We were running that traditional enterprise Java stack you are probably familiar with—Spring, Hibernate, Solr, etc. It took a few years but we had built a very nice system; it performed well but deep inside I felt development wasn’t as productive as it should have been. I also noticed that the whole dev process wasn’t as fun as it used to be. Of course, I had heard a lot of great stories about Rails, Django and, more recently, Node.js; there were actually some compelling stories surrounding those technologies. I ended up spending a fair amount of my spare time working on those technologies, and I actually had a really great time building some small apps and prototypes with them. But then I would wake up the next morning, go to work, face another big important project and go right back into my tried and true: Java.
One of those projects was an online offer management system for Fannie Mae which was to receive a billion dollars in offers in its first month. In my mind, there was no way I would introduce a brand new language—especially a scripting language like Python or Ruby—to the team for such an important project. From personal experience, I feel it’s difficult to manage a large project without type checking. I was basically between a rock and a hard place because I wasn’t very excited about the options in the Java space, and I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc. At the same time, I wasn’t about to give up on Java as a language, especially on the JVM which I grew to trust because of its reliability. Then I ran into Play; it was love at first sight for me. (I’d love to tell you how I ran into Play … just follow me on Twitter—[@_felipera] so I can beat Justin “Beaver”‘s Klout score!) Once I decided to take it for a ride, I was up and running right away! With a simple command, “play new”, the whole application structure was defined. Follow that with another simple command, “play run”, and I was ready to get the party started! I felt instant relief because I didn’t need to come up with all those XML files, Spring’s applicationContext.xml, the web.xml, Hibernate’s HBM files, and THEN figure out how to wire them all together! Even after years working on those technologies, I still had to copy and paste them from somewhere; I could never remember all that syntax.
Another obvious compelling point for me was Play’s ability to reload classes on the fly without having to re-deploy the entire application or restart the server. I think we all know what it’s like to be working on an application, make a change to a class, execute maven or ant deploy … wait until a war is packaged … copied to a deploy directory … wait for the servlet context to get destroyed … then wait some more for the application to be deployed. And THEN … once the application is FINALLY deployed, we open the browser, hit our development environment and THERE’S A BUG! The problem could be as simple as a single character misplaced somewhere. It doesn’t matter what the problem is, we still need to go over that entire process all over again. By the third or fourth time that happens, the developer zones off on Slashdot, Hacker News or whatever his/her favorite website is. Play handles class reloading beautifully; you really don’t have to restart your server!
I was also attracted to Play’s Stateless model, that “Share Nothing” HTTP architecture. Many of us were unfortunate enough to have developed, and even worse, supported J2EE-based applications that were built on a Stateful model. It was really hard managing state, cluster-safe cache objects, HTTP sessions, especially for those Enterprise Java Beans (EJBs) and that whole concept of attached objects. Play doesn’t share state between each node which simplifies the management of your cluster, and it provides a cluster-aware and cluster-safe caching solution.
Man, I could go on and on all night but I’ll spare you from all my craziness! In a nutshell, Play is a full stack framework for modern Web applications with a NIO-based development and production servers, full support for MVC, a persistence engine, a fully integrated testing framework (unit testing and functional testing), a powerful async Web Service client, an async-based job manager, multiple extensions are available through modules, support for full customization on the framework behavior through its plugin mechanism, dependency management, validation framework and even more advanced features such as WebSockets.
I don’t know if you guys know this but I’m an old man; I’ve been developing Web applications for 15 or so years now. And for the most part, with undying passion. But Play has rejuvenated my love for developing Web applications all over again.
This is—more than anything—a declaration of love,
Felipe Oliveira
From http://geeks.aretotally.in/why-did-i-fall-in-love-with-play-framework.
Published at DZone with permission of Felipe Oliveira, author and DZone MVB.One of those projects was an online offer management system for Fannie Mae which was to receive a billion dollars in offers in its first month. In my mind, there was no way I would introduce a brand new language—especially a scripting language like Python or Ruby—to the team for such an important project. From personal experience, I feel it’s difficult to manage a large project without type checking. I was basically between a rock and a hard place because I wasn’t very excited about the options in the Java space, and I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc. At the same time, I wasn’t about to give up on Java as a language, especially on the JVM which I grew to trust because of its reliability. Then I ran into Play; it was love at first sight for me. (I’d love to tell you how I ran into Play … just follow me on Twitter—[@_felipera] so I can beat Justin “Beaver”‘s Klout score!) Once I decided to take it for a ride, I was up and running right away! With a simple command, “play new”, the whole application structure was defined. Follow that with another simple command, “play run”, and I was ready to get the party started! I felt instant relief because I didn’t need to come up with all those XML files, Spring’s applicationContext.xml, the web.xml, Hibernate’s HBM files, and THEN figure out how to wire them all together! Even after years working on those technologies, I still had to copy and paste them from somewhere; I could never remember all that syntax.
Another obvious compelling point for me was Play’s ability to reload classes on the fly without having to re-deploy the entire application or restart the server. I think we all know what it’s like to be working on an application, make a change to a class, execute maven or ant deploy … wait until a war is packaged … copied to a deploy directory … wait for the servlet context to get destroyed … then wait some more for the application to be deployed. And THEN … once the application is FINALLY deployed, we open the browser, hit our development environment and THERE’S A BUG! The problem could be as simple as a single character misplaced somewhere. It doesn’t matter what the problem is, we still need to go over that entire process all over again. By the third or fourth time that happens, the developer zones off on Slashdot, Hacker News or whatever his/her favorite website is. Play handles class reloading beautifully; you really don’t have to restart your server!
I was also attracted to Play’s Stateless model, that “Share Nothing” HTTP architecture. Many of us were unfortunate enough to have developed, and even worse, supported J2EE-based applications that were built on a Stateful model. It was really hard managing state, cluster-safe cache objects, HTTP sessions, especially for those Enterprise Java Beans (EJBs) and that whole concept of attached objects. Play doesn’t share state between each node which simplifies the management of your cluster, and it provides a cluster-aware and cluster-safe caching solution.
Man, I could go on and on all night but I’ll spare you from all my craziness! In a nutshell, Play is a full stack framework for modern Web applications with a NIO-based development and production servers, full support for MVC, a persistence engine, a fully integrated testing framework (unit testing and functional testing), a powerful async Web Service client, an async-based job manager, multiple extensions are available through modules, support for full customization on the framework behavior through its plugin mechanism, dependency management, validation framework and even more advanced features such as WebSockets.
I don’t know if you guys know this but I’m an old man; I’ve been developing Web applications for 15 or so years now. And for the most part, with undying passion. But Play has rejuvenated my love for developing Web applications all over again.
This is—more than anything—a declaration of love,
Felipe Oliveira
From http://geeks.aretotally.in/why-did-i-fall-in-love-with-play-framework.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:






Comments
Nicolas Frankel replied on Fri, 2011/08/26 - 1:13am
Strange: despite all your years, you never realized Eclipse/Tomcat integration (or even better, Eclipse/Glassfish) let you not deploy your application in the painful process you describe. Too bad...
Andrew Spencer replied on Fri, 2011/08/26 - 2:49am
Where I'm sitting, a text edit in a JSP, or a single-line change in Java source (without changes to class structure) requires a restart of Tomcat. Granted, it saves rebuilding the project in Maven every time, but it still costs close to a minute each time on my current project, which leaves plenty of room for improvement.
Anyway, that's off topic. Thanks for the article, Felipe. Something I would like to read is a balanced critique of Play!. It has made many choices that are radically different from standard JEE, and the approach is almost diametrically opposed to Vaadin (the most extreme example I know of hiding the web from developers). I wonder what are the advantages and pitfalls of Play!'s approach.
Otengi Miloskov replied on Fri, 2011/08/26 - 2:46am
Mohan Ambalavanan replied on Fri, 2011/08/26 - 4:01am
Erik Post replied on Fri, 2011/08/26 - 6:20am
Alex Scott replied on Fri, 2011/08/26 - 6:32am
Erik Post replied on Fri, 2011/08/26 - 6:35am
in response to:
Andrew Spencer
Amir Pashazadeh replied on Fri, 2011/08/26 - 5:51pm
Have you used an IDE/Container integration at all?
We are using IDEA/Tomcat, and for changing, JSPs, and most of classes (except for example JPA entities and defining some new components) there is no need to restart the container, just compile the class and reload it. So I don't see the problem you mentioned at all.
In Play you write static methods! Do you believe it as OO? I don't.
And you must use its container, so what about features you get from some more bullet proof containers? Don't tell me that the Play container can give you all the JBoss or WebLogic features.
I looked at Play framework, and its static methods, and its self container were two things that I could not stand.
James Cole replied on Fri, 2011/08/26 - 6:07pm
Jooareall Basterds replied on Tue, 2012/10/16 - 12:31pm
"I had only a very modest level of success with the other alternatives like Grails, Spring Roo, etc"
Could you substantiate this further?
The first advantages of Play that you mention are exactly alike what Grails and Roo have to offer (project bootstrapping).