By Mikhail Gavryuchkov
I like both frameworks. Grails or Groovy on Rails and Play framework which I would call Java on Rails.
I went through both tutorials: Grails Quick Start and Getting Started Book for Grails and Play tutorial.
I developed one application http://managers.internetpolyglot.com/articlemanager in Grails, I haven't developed anything yet in Play. This is middle of October 2011. Which means that if I continue with any of these frameworks I'll add or modify information on this page.
I am a pretty seasoned Java developer with exposure to web technologies and I did my share of Struts, Spring MVC and JSF. I have a website http://www.internetpolyglot.com which is written in AppFuse (thank you Matt Raible for this awesome framework that was the precursor of both Grails and Play) and needs redevelopment very badly. What to choose for the new generation of Internet Polyglot?
As a Java developer I most probably will not go for any of the following - Ruby on Rails, Django (Python), Perl, and even PHP. I want to keep it in the JVM. My recent two projects were using Spring MVC, Spring and Hibernate - a big pain in the butt! I am so tired of configuration xml's. The initial start is much faster in Grails and Play. Grails' language is Groovy, not Java but it's very Java-like. Some times it looks a bit creepy to my Java-used eye but more often than not it's quite intuitive.
If you google for "Grails vs. Play" you'll find many posts - most of them praise Play as a great replacement for Grails and only a couple of them say that they've hit some serious problems on live projects developed on Play.
Below is the matrix of comparison between Grails and Play framework, based on my personal (no doubt limited and subjective) experience.
Plugins/Modules
Grails: Grails has Grails plugins. They are simply amazing. And the way they are organized on the site is also very good. It's very important for me to see the grades. Unfortunately there are no reviews - it would be helpful to read reviews about different plugins. I used at least two plugins - Spring security plugin and Searchable plugin. Spring security worked like a charm although I had to spend some time on adjusting it to the legacy database tables. The Searchable plugin worked so-so. Whatever I did I couldn't customize the search results (or maybe I didn't spend enough time?). I spent at least one evening browsing the plugins directory and thinking "aha, I'll need this plugin some time in the future. And this one too. And that!".
Play: Play framework has a similar concept to plugins - modules. Some of the functionality is already included in core Play and Play modules are quite the same as plugins. Except - the modules directory doesn't show grades or reviews so it's harder to make a choice - you are on your own, take your own risk when choosing this or that module.
Who wins: Grails
Language
Grails: Groovy. Very much Java-like. You can even write Java code instead of Groovy. But Groovy is more concise, which is good and bad. Good because emmm... it's good. But bad because sometimes it becomes less readable, less intuitive. Groovy is a scripting language. Again - good because it allows more freedom and bad because it doesn't check your syntax at the time of development. You will find out whether you made this stupid typo later when you run the app. It sucks, to be honest. It means that to maintain reasonable reliability your project needs a lot of unit- and integration- tests.
Play: Java. Some say that Java is a dying language and there are many signs of it. But I still love it.I love that I can use Eclipse and it helps me so very much - autocomplete, navigation from class to class or from method to method, showing javadoc, etc. And yes, syntax errors are found at compile time.
Scala. I don't know this language. Yet. But it seems I'll do sooner or later because its adoption grows very fast. A couple of things (heard from others): the learning curve is steeper but after that you are in coding heaven. Play recently started supporting Scala.
Who wins: Play
IDE integration
Grails: Eclipse - there is a plugin as a part of SpringSourse Tool Suite. I tried it and I didn't like it. It was highlighting as a syntax error code lines that are perfectly valid. Autocomplete was not working well either.
IntelliJ IDEA - muuuuuch better. There was just one hickup when I was setting up the environment. After that development was much smoother. The downside - it's not free. But to me it's worth it, if I am to go with Grails I will definitely develop in IDEA.
Play: Eclipse works out of the box. Without any plugins or anything else. And works perfectly. Just don't forget to run "play eclipsify" every time you add a module.
Who wins: Play
Search
Grails: Searchable plugin - as I wrote earlier I didn't quite like it. There are a couple more plugins that allow you to make contextual search in your app but anything I tried I didn't like.
Play: I don't know. The tutorial didn't show anything in it. There are a couple of modules that I haven't tried. So I guess it's a tie.
Who wins: Tie
Security
Grails: I used Spring Security plugin and like it very much. I had to do some customizations to make it work on a legacy database tables but eventually it works well providing role-based security.
Play: Mmmmm... Not so good. The Adding authentication tutorial works but provides only admin/non admin authorization. What about other roles? Most of the web applications require role-bases authorization.
Who wins: Grails
Tutorial (Documentation)
Grails: Excellent http://grails.org/Quick+Start and http://www.infoq.com/minibooks/grails-getting-started book.
Who wins: Tie
Persistence
Grails: GORM (Grails Object-Relational Mapping). I love it. It's so simple especially after you come from Hibernate where you have to write every one your freaking finder.
Play: Very good too. Although the syntax sometimes is not as elegant as Grails' GORM. But it's just a matter of taste.
Who wins: Tie
Scaffolding
Grails: Quick scaffolding of an application that provides a basic CRUD functionality.
Play: Scaffolding not so bad either. However out of the box the one-to-many relationship is not provided in scaffolded app. I.e. There is no way to navigate to a child entity from parent entity.
Who wins: Grails
Template engine
Grails: I like the syntax of gsp (Grails Server Pages) better. It resembles ol' good JSTL.
Play: Syntax (ironically) is Groovy-based and sometimes it's quite hard to read. But I guess it's a matter of getting used to.
Who wins: Grails
JQuery/Ajax
Grails: I tried it, it works pretty well.
Play: Haven't tried yet. Modules repository doesn't give much.
Who wins: Grails
Servlet API
Grails: Has it.
Play: Multiple posts about Play praise its creators for their boldness of dumping the Servlet API and making it purely stateless. It's hard to say for sure, but does it mean that I won't be able to access my request or session? Googled a bit more and I see that yes, you can access your request and session, don't worry.
Who wins: Tie
SEO
Grails: Oh yes, we need to have SEO-friendly url. For example instead of http://www.internetpolyglot.com/lessons/es/en I want to have http://www.internetpolyglot.com/lessons-spanish-english . It seems that Grails has it, although I haven't tried myself.
Who wins: Tie
Upgrade
Grails: Upgrade is simple. I had one problem when Grails folks decided to switch from hsqldb to h2 but it was a minor hickup.
Play: Upgrade is not simple. People have fear of upgrade.
Who wins: Grails
Development cycle
Grails: It's related to IDE support, so Grails is not as good at it but Groovy is more concise. But I don't know Groovy well enough :). Also every time you change your model class or controller - you see grails restarting.
Play: It's fast and efficient. The best part - you can develop the whole day without having to restart your server or your server restarting itself.
Who wins: Play
Running in debug mode
Grails: It's very important to me to be able to place a breakpoint in my Eclipse and see the program stop and inspect my variables. I tried it in Grails - it's working but not very reliably, even in IDEA.
Play: http://www.playframework.org/documentation/1.0.1/ide says it should be easy. So let's believe it.
Who wins: Play
Tests
Grails: I didn't like it. That's it. While developing Internet Polyglot Article Manager I knew I had to follow the test-driven development and cover my code with tests. But I don't wanted! I so much wasn't getting a knack while reading the book that I was procrastinating in writing those unit- and integration- tests. So no, there are no tests written for the Article Manager and I am deeply ashamed of it.
Play: Old good JUnit for unit- and integration- tests. Absolutely amazing browser/Selenium based test harness. Easy-to-write Selenium view-level tests. I liked it!
Who wins: Play
Production
Grails: Well thought approach in configuration file. When you build a war file and deploy it on your production it automatically picks up the prod mode and connects to your production database.
Play: You need to change your config file before building your app for production. Not good. I can't comment on whether it's good or not that Play app doesn't deploy in a servlet container - it runs standalone. I don't know - Tomcat gives me so many things for free, I am simply used to it. Maybe it's good to run it without Tomcat - time will tell.
Who wins: Grails
Performance
I didn't do it myself. Others did and posted contradicting benchmarks. Some say Grails is faster, some say Play.
Grails:
Play:
Who wins: Tie
Web services
Grails: It was insultingly easy to enable Web service on a class method. Different plugins allow it with different level of easiness.
Play: This post shows that it's quite easy too.
Who wins: Tie
Industry Momentum
Grails: Reached its plateau and shows signs of wearing out.
Play: Shows stable growth.
Who wins: Play
Backwards Compatibility
Grails: Fully backward compatible, there is no history of incompatibility
Play: Play 2.0 is NOT backward compatible with 1.2
Who wins: Grails
Results
Grails - 8, Play - 6.
Grails is still winning? How come?
Grails is still winning? How come?
A personal advice to Play folks - change your modules repository, allow grades and reviews. It will drive the community-based development, the one that makes Grails' plugins so powerful.
===============================================
Update 2012-06-20
I am working with Scala now. Doing lots of BigData analysis, specifically using Cascading on Hadoop. My experience: Scala is not an easy language - steep learning curve, even for me, a seasoned Java-ist. Java is much easier to start coding with. Yes, more verbose but more readable too.
As a friend of mine once told me "Scala is for writing, not for reading".
There are many people around me who I asked and who expressed a similar opinion.
Do you really need Scala to develop business logic and UI?
Play Framework seems to be more and more about Scala - and Java becomes a second class citizen (you simply cannot provide the best of the class experience in both worlds, you need to focus on something). At the same time Scala developers are more expensive than Java developers. And in high demand. It simply means that your project will incur much higher cost and you'll have harder time finding your developers. So the question remains: d
o you really need Scala to develop business logic and UI?
I used Grails on another new project and I was completely loving it. One thing though - I used Intellij IDEA as IDE. The development is more than just enjoyful - everything simply works and works well. Sometimes I didn't know how to do something in Groovy - so I easily was using Java out of the box. Adding Spring security (one Grails plugin) - one evening, adding User management and self-registration (another Grails plugin) - another evening. Adding login using Facebook or Twitter - yet another evening using another plugin. Try to do the same with Play Framework. A quick google search on "play framework facebook authentication" gave one fbconnect module which supports only Play 1.0! And as usual - I have no idea whether this module is good or not because there are no community grading system for modules.
Also, Play Frameworks creators told us that ORM (Object Relational Mapping) is overrated. They are promoting Anorm - and again it's for Scala, not for Java. And it's not ORM as its name suggests. You can happily write your JDBC queries in your code. Oh not again! Not another holy war of Hibernate against JDBC or iBatis!! For me personally ORM is a great performance improvement - both development performance and database querying performance (considering Hibernate first and second level caching). So going back to the world of JDBC - thank you, no thank you.
Let's run the Google trends seach on grails, play framework :
Hmmm.... Isn't it Play Framework reaching its plateau?
28 comments:
I didn't quite understand why did you say that IDE integration is better for Play! since Grails support in the IDEs is quite mature. In IntelliJIDEA is is super awesome and for Play! it is just the first signs in the EAP build.
So don't really understand the logic why Play! gets the point here.
Otherwise, great post!
Nice post, but Grails hasn't been called Groovy on Rails since 2006.
Your "Development cycle" section refers to older versions of Grails. In 2.0 (RC1 was released today) has full support for reloading Java and Groovy classes as well as all artifacts, using the new agent-based reloading.
In the production point I would like to add that you can make a package of a Play application just with the command: play war in a terminal. It creates a war package that you can upload to a servlet container as tomcat or glassfish or any others (look at: http://www.playframework.org/documentation/1.2.3/deployment).
For the jQuery/AJAX topic, I say that every play application includes in the directory: "/appPlay/public/javascripts/jquery-1.5.2.min.js". But, is not a problem wether you use jQuery or Scriptaculous or Prototype...Is very easy to receive responses using AJAX with one of these libraries. With the methods: renderHTML, renderJSON, render...even in the routes file you can define the format of the response.
For the persistence I say that play is better, because is JPA, so, if you come from a Java background you don't have to learn another framework.
Another thing I would notice is that Play! is more Java-like, you don't need the terminal for everything, just for create the project and run it or make it for your preferred IDE (eclipsify, netbeansify, idealize).
Really interesting post, and I think your ideas about the modules page would make a big difference also. I think it has been raised in the Google Groups, but seeing it in a comparison view like this makes you realise the importance.
There are a few things in here that I think are slightly inaccurate that may be worth clearing up.
Production - Play does not need to have config changed to move to production. It can be done with a start up flag as well as a config change.
Starting play with play run --%prod will run it in production mode
Also, Play can run inside a servlet container. It has a ServletWrapper than allows you to deploy to all major servlet containers (see this link for details - http://www.playframework.org/documentation/1.2.3/deployment)
JQuery/Ajax - this is pretty simple. It comes pre-configured with jquery, and has a few core functions (groovy tags) that assist in calling serverside actions with jquery etc. Again, the Play documentation specifically explains how to use Ajax in Play.
http://www.playframework.org/documentation/1.2.3/ajax
I haven't used Grails a great deal, so I won't pretend to argue if these points above change your view on which framework wins, but wanted to offer some clarification.
Thanks
Wayne
P.S. Glad my post on Stackoverflow helped in the WebService comparison.
Mate why did you even bother to make this post if you know yourself you didn't properly evaluate either of the frameworks
Regarding changing your configuration file for production, that's not true. You can specify configuration items by environment. for example:
%dev.somevariable=100
%prod.somevariable=200
Thanks everyone for your comments! I just want to add a couple of points:
Both Grails and Play are moving targets and they run head-to-head in adding new features. I think it's great because it keeps creators of both of them on the tips of their toes.
@Hans: As I said in my post - this evaluation is subjective and I don't want to pretend that it is uber-comprehensive. If you can properly evaluate the frameworks - please be my guest, you can post it here, it's a free forum :)
@Anton. About IDE support. What I said is I didn't like Grails support in Eclipse (and I've been in Eclipse for ages) and IDEA was pretty good but you need to pay for IDEA. Play works well in Eclipse right from the bat.
@ Burt, even though they don't call themselves Groovy on Rails I call them Groovy on Rails. Why? Because the language is Groovy and their platform is Rails. They can call them whatever they want and I will call them however I want :)
@Mikhail
You don't have to pay for IDEA. The Community Edition comes with Grails and Groovy support out of the box.
I have learned both of these frameworks: Grails and Play. I started with Grails, then Play. After learning Play I would do the next project with it. IMHO, for me, Play seems to be easier and lightweight. But this is just my first impression from both of them, without any practical knowledge with the frameworks.
Also I would go with Play b/c of Scala. At this moment I am still learning it. But I prefer it to Groovy. Scala seems to me more thought-out. Comparing Scala and Groovy I recall James Strachan words (the founder of Groovy): "I can honestly say if someone had shown me the Programming in Scala back in 2003 I'd probably have never created Groovy." (http://en.wikipedia.org/wiki/Groovy_%28programming_language%29)
You should really spend some times learn Play a little bit more. Your analysis is based on what you DID find from various sources, but it doesn't reflect the reality. For example, in Security, you get Grails to win because you think there's no roles in Play secure... while there are and the Play security framework, while not as complete as Spring Security, is by far much easier and less "AOP magic" and thus supports the needs for 99% of web apps.
Ajax support is built-in in Play, development cycle is an order of magnitude faster with Play. Just take a look at Grails reloading dependencies each time you touch a model file...
And for production, Play supports multiple "contexts" in a single configuration file and support deploying in a WAR if you need too.
Please give a try to Play before making such an analysis.
Very good article, it's good that you share you thoughts
I have no experience with grails, but I've done a couple of things with play and I think there are a few things that are not quite accurate:
IDE integration: play also comes with and Eclipse plugin which adds a few more things, more over, IntelliJ Idea play support is comming in version 11, here's a preview and several screencasts http://blogs.jetbrains.com/idea/2011/10/play-with-intellij-idea-eap-build-110187/
Security: you should definitely have a look at deadbolt module that does exactly what you are asking for - http://www.playframework.org/modules/deadbolt-1.4.2/home
Persistence: in fact play uses JPA, with Hibernate as implementation, by default, with a few nice helpers, more over you have several modules for GAE datastore, mongo, and other nosql data sources
Template engine: as you said is a matter of taste, but play also let's you develop performance critic tags in java using fastTags (http://playframework.wordpress.com/2010/11/26/fasttags-in-play/) and you also have other tempalte engines, like japid (http://www.playframework.org/modules/japid) and cambridge (http://code.google.com/p/cambridge/wiki/UsingWithPlayFramework)
Jquery/Ajax: play is pretty agnostic about client side technology, you can use what ever you like. Ajax is quite simple, you just have a simple tag that helps you build the ajax call using the router system (http://www.playframework.org/documentation/latest/ajax)
Production: play has support for several Ids and configuration for each environment, you shouldn't need to change config file for production (http://www.playframework.org/documentation/latest/ids)
Performance: well, it's really odd that you say it's a tie. One of the more obvious advantages of play would be perfomance. In fact, the most critized part of play is the groovy template system, because of it's performance, if you use another template engine, like rapid, play i pretty fast. have a look at this http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/, play bit japid is almost as fast as static content
I would add another item that seems to be more relevant everyday, cloud computing support. Here's a list of play hosting options, which include google application engine, heroku and res hat's openshift. (http://stackoverflow.com/questions/6974265/experiences-on-free-and-low-cost-hosting-for-play-framework-applications and https://github.com/playframework/play/blob/master/documentation/manual/deployment.textile)
On the other hand I would also take into account grails springsource support, the community and the books and documentation available
Saludos
sas
@opensas - thank you for additional thoughts! Very useful!
I am going to do my own performance benchmark for Grails and Play "Quick start" apps. Nothing too comprehensive again, just hitting one page with multiple threads using JMeter.
Cloud ready - I don't think Play is better than Grails in this regard. I am running my Article Manager on Amazon EC2 and quite content with it.
@Joel Grenon - you see, here is the thing: I DON'T want to invest excessive amount of effort to learn a framework before I make a choice. I expect the framework to show itself in the best light to me. It seems that if Play wants to win over Grails on the security criterion - let them change their tutorial and include the role-based authorization. I am not going to dig through tons of undocumented stuff and mailing lists.
My post is for people like me. If your approach is to learn all existing frameworks in and out before making a choice - this evaluation is not for you.
@Joel Grenon - one more correction. You are saying that my evaluation is based on what I found in different sources. Incorrect. 70% of my evaluation is based on my own experience - I wrote it in the beginning of the post that I developed one app using Grails (after going over Grails quick start and its book) and I went through Play tutorial and followed it very thoroughly.
> Cloud ready - I don't think Play is better than Grails in this regard. I am running my Article Manager on Amazon EC2 and quite content with it.
Sorry, I should've been more specific, with Iaas (infrastructure as a service) you can certainly run wathever you want, I meant support for Paas (platform as a service) like, GAE, heroku, cloudbee, cloudfoundry, red hat's openshift, playapss, etc...
You posted this article as a response to a question on Quora that asked for opinions from anyone who has had 'significant experience with both'.
In that context I completely agree with the criticism voiced by Joel.
I came here to read an expert opinion and not a 'tutorial comparison'.
Other than that, thank you for sharing your opinion!
Coming from Grails and wanting to know more about Play, it was an interesting read. I am still looking for that expert opinion though...
@mistaecko - criticism is accepted. I will go and update my post on Quora, specifically saying that this is not an expert comparison.
A note of caution for people looking into Play: The Play developers have embarked in a massive rewrite of the framework for version 2, which is backwards-incompatible with the current version 1.2. The suggestion of Play developers for those asking what the migration path is for current Play apps is that there is no need to migrate, you can just stick with Play 1.2 for current apps - very infuriating. The ORM has changed, the templating engine has changed, the build process has changed, and the core of the framework has been rewritten in Scala - while documentation is pretty good, I find myself digging into the framework code a lot, this will become much harder with the move to Scala.
Regarding Grails, while I have not personally used it yet, I plan to use it for future projects. Groovy is much easier to read and write for a Java developer than Scala, and I doubt that SpringSource would be so cavalier as to introduce a new version of Grails that has no migration path for current Grails apps, or rewrite the core of Grails in Clojure.
@anton
IntelliJ has 'groovy' support in the free community edition, but explicitly no Grails support. If you're doing Grails, I've not found anything close to the level of intellij support. There's still some things they can improve on, but it's far better than anything else I've tried.
Interesting post. Very detailed and not too much information at the same time. It gives and idea of where to start from if you don't know much about both frameworks.
Hi everyone, thanks again for all your thoughts and feedback. I've just added my recent experience with Grails and Play Framework at the end of the original post (Update 2012-06-20). Bottom line - while Play tries to win over Scala community Grails wins over me.
There is going to be a competition!! See Play vs. Grails Smackdown.
Matt Raible - the guy behind AppFuse that I still use in InternetPolyglot is going to work on the hands-on analysis and benchmark of these two frameworks. The heavy artillery arrived! :)
Thanks for the article.
Would be interested to read the same with Grails and Vaadin :)
I have read that we can program with groovy under vaadin, to verify.
I know that Vaadin can be used inside of Grails and there is a plugin: http://grails.org/plugin/vaadin. It has 12 positive reviews so it must be good.
I'm with you. I'm 99% certain that I'm going back to Grails after several months fighting to get Play to do what I wanted, the way that I wanted. It's not worth the aggravation when there are other frameworks that just work. http://www.stupidjavatricks.com/?p=278
Post a Comment