Play vs. Grails Smackdown at ÜberConf
Play and Grails have been hyped as the most productive JVM Web Frameworks for the last couple of years. That hype has recently grown thanks to both frameworks' 2.0 releases. That's why James Ward and I decided to do a presentation at ÜberConf comparing the two. In April, we proposed the talk to Jay Zimmerman, got accepted and went to work.
How we did it
In the beginning of May, we met at a brewery in LoDo and sketched out the app we wanted to build. We also came up with a schedule for development and a plan for the presentation. We decided to build two different webapps, each with little-to-no Ajax functionality and a few features that we could use to load test and compare the applications.
We started out with the name “Happy Trails” since we both liked trails and happy hours. Later, James found that www.ubertracks.com was available and purchased the domain. We setup the Grails app to be on bike.ubertracks.com and Play/Java to be on hike.ubertracks.com. We managed our source code on GitHub, continuously tested on CloudBees and deployed to Heroku. Two weeks ago, when we were finishing up our apps, we hired a friend (Linsay Shirley) to do QA.
After fixing bugs, I emailed Patrick Lightbody, got some “cloud dollars” for Neustar Web Performance and started running load tests. The Wednesday before last, at 2 in the morning, I recorded a simple browsing regions and routes script and set it to go to 50 users over a 5 minute period and then sustain 50 for another 5 minutes. It was fun to watch the log messages whiz through my console so fast they got blurry. About halfway through testing the Grails app, there was an OOM issue, but it eventually recovered. Limiting db connections to 4 and scaling to 5 Dynos in future tests helped alleviate any issues.
We took our development experience, the load/performance testing data, and a bunch of ecosystem stats and built our smackdown presentation. We used reveal.js, GitHub Files and Google Charts to make things more dynamic.
What we found
We arrived at a number of conclusions after doing our research:
Code
- From a code perspective, Play 2 and Grails 2 are very similar frameworks.
- Code authoring was good in both, but lacking IDE support for Play 2's Scala Templates.
- Grails Plugin Ecosystem is excellent.
- TDD-Style Development is easy with both.
- Type-safety in Play 2 was really useful, especially routes.
Statistical Analysis
- Grails has better support for FEO (YSlow, PageSpeed)
- Grails has less LOC! (6 lines less, but 40% more files)
- 1 Dyno - Grails had 2x transactions!
- Grails experienced OOM about halfway through.
- Apache Benchmark with 10K requests:
- Play: ~10% failed requests, Grails: 0
- Requests per second: {Play: 170, Grails: 198}
- Requests per second: {Play: 251, Grails: 198}
- Load Test with 100 Real Users:
- Grails: 10% more transactions, 0 errors
Ecosystem Analysis
- "Play" is difficult to search for.
- Grails is more mature.
- Play has momentum issues.
- LinkedIn: more people know Grails than Spring MVC.
- Play has 3x user mailing list traffic.
- We had similar experiences with documentation and questions.
- Outdated documentation is a problem for both.
- Play has way more hype!
We figured we spent around 100 hours developing the apps, gathering data and creating the presentation. The good news is it's all open source! This means you can clone the project on GitHub (Grails is in the grails2 branch, Play is in the play2_java branch) and help us improve it. The presentation is in the master branch in the preso directory.
All the data we gathered is open for debate and we’d love to tune our apps to handle more requests per second. In fact, we already had a contributor discover an issue and provide a fix for Play that increases its throughput from 170 req/second to 252 req/second!
Regardless of what the stats and pretty graphs say, we both enjoyed our experiences with Play 2 and Grails 2. If you haven't tried them yourself, we encourage you to do so.