Why Did I Fall in Love with Play! Framework?
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,
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)