Grails or Play! for an ex-RoR developer?

Question

I plan to start learning a Java web framework (I love the Java API) I have already used Rails and Django.

I want something close to Java but without all the complexity of J2EE.

I've found 2 frameworks that could be good for me:

Grails

Grails looks great, it uses Groovy which is better than Java for web application (I think..) but it's slower than pure-java based frameworks (Hibernate, Strut, Spring) It looks pretty simple to deploy (send .war and it's ok!), the GSP is great! It's a bit harder to debug (need to restart the server at each modification and stacktraces contain a mix of Java and Groovy traces which is not always the easiest to understand)

Play!

This framework also looks great; it's faster than Grails (It uses Java) but I don't really like how it uses Java, it modifies the source code to transform the property calls as setXXX/getXXX, I do not like that... The framework also has a caching function that Grails does not have. I don't really like the Template Engine. It's also easer to debug (no need to restart the server, stacktraces are clearer)

What do you recommend? I am looking for something easy to learn (I have a lot of Ruby experience, not so much Java experience but I love the Java API), fully featured (That's no a problem with all the Java Library available, but if it's bundle and integrated I prefer), has good scalability and is not too slow (faster than Ruby) Ideally I would like to use a framework with a decent community to easily find support.

PS: I am not interested in JRuby on Rails

Moffat

I found an extensive comparison based on personal experience j2eespot.blogspot.com/2011/10/… – Premarital

Answer 1

I'd suggest Grails. It has a bigger community than the play framework does (~350 plugins covering pretty much every basic need). Also, grails is written almost completely in Java, it just lets you use Groovy for your domain specific implementation.

If you do run into a performance issue where the groovy pages that you've created are the bottleneck, you can always just switch to a Java implementation. Then you're in the same boat that you would have been with the Play framework all the time. You've optimized your development time by putting off the coding of things in Java till you know that you actually need to do it (which, in my experience is very rare).

I'm also not sure where you heard that you need to restart your server for each modification, but that's actually not true. Grails supports reloading of controllers/gsps/services/domain objects, etc without restarting your server.

The mixed stacktraces can get a little long, but tool vendors (like Intellij) have made some recent improvements that strip out all the stacktrace portions that you don't care about.

I've been using grails since the .5 days and have been very happy with the platform.

Sale

Thanks for reply :) The strange thing about Grails is there is no possibility of output stream caching likes the rails cache_page, cache_action and cache_fragment, and on rails, when we don't cache, we get really slow performance, but if grails is natively faster than rails I don't know if that will be an issue for now. But when the website begin to grow, how can I do output caching ? (if possible distributed caching with something like memcached) – Moffat

You can cache page fragments with the Spring Cache plugin (grails.org/plugin/springcache) and you should also look at this: adhockery.blogspot.com/2010/02/… – Marpet

There are a few different solutions for speeding up grails output. The UI Performance plugin handles client side browser cache stuff like versioning images, setting appropriate headers, gathering up css/js files and packing/gzipping them for quick transport. grails.org/plugin/ui-performance The springcache plugin does more of the page/fragement caching. Underneath it uses the terracota ehcache-web implementation. grails.org/plugin/springcache You can also do distributed caching with terracotta's solutions as well. – Sale

Hmm okay, thank you, that looks harder than the rails automatic caching, but I'll try to use that ;) – Moffat

I haven't used Grails much personally, but one of my best buds switched over to it, and the way he extols its virtues, I think his wife may need to worry! ;) – Pronouncement

I have to wonder if the Grails community is bigger after seeing the Google trend. – Kakalina

@mattblang It's not "Groovy on Grails", just Grails :-) The average for me seems higher for Grails. – Guidon

Answer 2

I switched from Grails to Play and I never looked back. My biggest problem with Grails was overall robustness and developer usability. Most of the time I got bitten by the fact that Grails glues together the usual stack of Spring MVC and Hibernate while trying to hide this fact and giving you a Rails-like API (personal opinion of mine). The problem with this is, once something goes beyond the trivial samples, it easily broke and didnt work for me. Developing with it was like walking on eggs (for me). Whenever I googled for documentation of a feature I needed, I was not redirected to samples, tutorials, blogs, but to the Grails JIRA explaining me why the feature wouldnt work for my use case and that the bug was unresolved since two versions before the one I was using.

While that may not be the overall experience for every developer (I am not writing this to bash Grails, but to give my experiences with it here), I needed something that helped me and would not stand in my way or break down on me when I needed it the most. Thats when I found Play and I have quickly migrated my app to it after I found out about it (around the ~1.0 release).

So far it has been a great ride and for the first time in my web development career, I have stopped looking at other frameworks trying to find something that I would like better.

If I had to close with one thing that Play did better than Grails - at least for me - it would be the fact the Play is built from the ground up with developer usability in mind. It does not sacrifice ease of use for enterprise buzzwords. It has the guts to throw away what does not fit into this paradigm (e.g. ditchting Servlet-based runtimes during development for faster turnaround). It is willing to make compromises in order to guarantee awesomeness. And that is something I have only seen in communities like Rails or Django before I found Play.

Paolo

This sounds like you had a lot of Grails experience and are still in your honeymoon period with Play – Scopp

Actually the changes made in Play2 has definitely killed that honeymoon-feeling. – Paolo

2013 update? Are you happily using Play2 or did you resume the search for something better? – Coloquintida

I am still using Play1 for my applications in production and have not migrated them. For new applications I have not used Play2 so far, as I personally dont like the changes of Play2. I have used Django and Flask as alternatives, because if Play2 forces me to use Scala, I might as well just switch to Python. – Paolo

Answer 3

Take note that the Play! framework now supports using Scala as of 1.1

Goosefish

Answer 4

From my experience with Play it's a great framework. My favorite features are the cool controller system and the template system - both are simple but feature-rich and powerful.

However the most important benefit of Play is definitely the rapid development cycle, where virtually no reloading is needed on code changes. But if you're not careful, this greatness won't last much, and slowness will eventually creep into your code.

Why is that? With Play there is common use of some plugins with pretty heavy initialization, notably EJB (Hibernate) and Spring. The initialization of these plugins is re-run on every code change before the new code is loaded. As a result of this, as your model and your system configuration grow, this heavy initialization starts to seriously slow down your development. In the system I used 20 seconds were a typical startup time on a virtual machine running on a kickass laptop.

What you can do to avoid this depends on your application, e.g. if you're building a NoSQL application then then EJB plugin should not give you trouble. Spring can be replaced with a custom hard-coded Java plugin, which IMHO is also easier to maintain, or run a Groovy script if scriptability is that important. In any case, watch out for these problems and kill them while the're young - and be sure not to be running your own bulky initializations on every refresh.

Garibaldi

Answer 5

If you have used Ruby and Python before, you will probably enjoy Grails better than Play. It very hard to get back to Java once you are used to these dynamic languages.

Megalomania

Answer 6

There is also Lift on Scala.
Imho scala is the best static typed language and lift is a pretty nice framework (for a static typed language).

Merrythought

I took a look, I'm not really fan of the Scala language (functional part, and the syntax) and Lift looks really too young, there is no real user guide and the documentation is very poor :( – Moffat