Grails and Play are excellent open source RAD frameworks based on the JVM, enabling website production. As Hibernate is at the core of these frameworks, we shall look into what makes them different from one another.
Why Grails and Play?
Other frameworks actually do exist (JRuby on Rails, Lift, Spring ROO…). I have decided to focus on these two, because it might be difficult to tell one from the other as they are in the same current MVC framework movement.
This article is not meant to be a comprehensive comparative report. It offers an hindsight at of these two frameworks.
Where it all began
The first official version of Grails (at the time Groovy on Rails) goes back to 2006 and gets its inspiration from Ruby on Rails. SpringSource, buys G2One in 2008, the company in charge of the framework, now in charge of its maintenance.
Zenexity, with the support of Guillaume Bort comes up with a first version of Play, two years later, after previously having gained experience on Grails projects.
The philosophy
These two frameworks promote amongst other things, development efficiency (unlike JEE bricks) but with a different approach:
- Grails is more conventional, reusing classic components (for instance, those of Spring) and fits in perfectly with the JEE world.
- Play is iconoclastic, and hasn’t hesitated to drop some long used JEE bricks, such as servlets. Moreover, its full-stack aspect is more intense which makes it more autonomous and ready to use.
Now let’s get into the thick of it.
Compilation
The first surprise with Play for those used to JEE: the framework doesn’t generate .classfiles, but compiles them directly in bytecode when implemented (via technology used by Eclipse).
Consideration of the modifications on the code
Grails and Play allows you more or less to consider modifications on project files, without server uploading.
For each request, play will run through the concerned Java files and recompile them if need be.
Grails checks every 3 seconds (time that can be set) modifications made on the files. Modifications made on domain objects partially restart the server.
Execution modes
Both frameworks have by default DEV / TEST / PROD modes which correspond to development, staging and production environments.
It will be possible to apply a specific configuration to each of these modes (in particular, connection to database depending on the environment).
Play behaves differently with regards to the compilation mode, especially on DEV and PRODmodes. In PROD mode, the functionality of hot deploy will be de-activated, and a complete compilation (Java source and template) is done when starting the built-in Web server, stopping the latter from starting if the compilation is not possible.
Stateless
Play is a stateless framework, there is no object in memory (except for the configuration, routes…), which makes clustering easier. Consequently, the use of a session is done through a cookie (limited to String, and with a limited size)
Groovy / Scala
The speed of development with a RAD framework hinges on the type of language this framework is based on.
Grails uses the Groovy object-oriented language and static and dynamic typing. It bringsclosures support, low verbosity, facilitates collection manipulations and is compatible with the Java language.
On start up, Play only works with Java. You must wait for the 1.1 framework version which ensures the Scala->http://www.scala-lang.org/] language support. We are dealing at the same time with an object-oriented and functional-orientated language, whilst being typed statically. Although quite hard to master, it is nonetheless possible to run arbitrary code in Scala from Java.
Performance
Right from the start, Play has taken sides with performance by offering:
- its very own API to manage HTTP requests (servlets are considered currently unsuitable for the internet),
- a light HTTP server (JBoss Netty since the 1.1 version) which is capable to manage hundreds of requests per second and also enables long polling requests management.
- a simple architecture allowing to manage requests asynchronously (non-blocking).
Configuration
Grails also uses Groovy for configuration files which:
- brings more flexibility in configuration files writing (direct object manipulation)
- reduces file verbosity
- maintains homogeneity (no XML, no JSON…)
The community
Modules
- 74 modules for Play,
- 586 modules for Grails.
Grails and Play modules allow technical extension of frameworks. Grails has the advantage of offering richer plugins in terms of functionality (especially functionalities improving user interface).
Google Groups
- approximately 24,000 posts for Play / stackOverFlow tags,
- approximately 120,000 posts for Grails with forums per language (English / Chinese / Spanish / Polish / German / Portuguese-Brazilian).
Grails benefits from a much larger community and takes advantage of the Spring community and its international scope.
In conclusion
Where Grails lies in the continuity of the JEE logic, in the sense of “layer piling”, Play goes the opposite way while gaining in performance, but breaking from compatibility with other frameworks.
I blame Play for its “patchwork” side because it mixes different technologies and languages. Grails is more elegant because it uses Groovy evenly within the framework (controller / view / configuration…)
“So, what to choose?”
Personally, i think Grails and Play are relevant in different environments.
Play is well positioned on:
- A startup Website (project from scratch);
- A high performance Website;
- An amateur project (without being pejorative) thanks to the full-stack approach.
However, Grails has more credibility around projects that need an integration to an existing information system, thanks to its multitude of modules.
