Playing with Play Framework for Java
Recently I’ve been playing more seriously with the Play-Framework. Play is a newer rapid development web stack for developing web applications. My impressions in short: this is a very nicely framework for write applications, with much potential but which is at the very beginning. This means there aren’t awfully many features available (compare with Lift, also a recent framework for Scala on the JVM).
Good parts
The good parts I’ve found are:
- Java (JVM) based
- Aims for fun for developers
- Fast turnaround, automatically reloads Java classes, templates etc. which is one of the main gripes I have with Java, as stated in my “Java dead?” post:
Rapid development and rapid turnaround. Java still falls flat, even with JRebel which allows seamless reloading of classes, RAD web frameworks like Wicket and splendid IDEs. Rails, Django and PHP are better and have a faster turn around. Period. Java is lacking here, and reloading changes look to be the biggest problem with Java development today.
- Real world developer oriented, not power oriented or hacker oriented. For example errors are shown in a nice way with the corresponding code in the browser.
- Interesting modules available (Guice, Sass, GAE, OAuth), more Rails oriented than classic Java (which is a good thing!)
- No need to write getters and setters, they are automatically added. Another one of the gripes I have with Java
- Based on JPA, but other persistence like Siena supported
- Scala possible (Shorter, even nicer). Downside: Not as nice integrated as Lift, e.g. Option usage in Lift, composable attributes for domain classes
- Integrates Unit, Functional and Selenium (often aceptance tests) tests in one web page. Different testing styles can be used, e.g. JUnit with asserts, JUnit with should, Spec style and more.
class SpecStyle extends UnitTest with FlatSpec with ShouldMatchers { val name = "Hello World" "'Hello World'" should "not contain the X letter" in { name should not include ("X") } it should "have 11 chars" in { name should have length (11) } }
The things I don’t like so much
There were some parts during my playing around, which I didn’t like with Play:
- I would prefer the Lift (or StringTemplate) way of templating, with no code in templates (or the RIFE way)
- Not on the NoSQL bandwagon – NoSQL really is the future for some web apps I believe
- Wish it would use a build system, not for building, but for dependency managment, packaging etc (Gradle for example, or at least Maven).
- Not yet a big community, modules limited, high risk bet
- Minor one: Bazar? Wouldn’t have thought this is needed with Git and Mercurial, don’t want to learn a third competing DVCS
Overall an interesting new comer, which brings new ideas to the Java table. Definitely something to watch.
You can leave a Reply here. Of course, you should follow me on twitter here.
hi stephan,
1) there are a few templating solutions available at the moment:
- the standard groovy one
-scalate (ssp,scaml)
-japid
that means four options to choose from (if I add scala xml literals that means 5)
2) it provides support for siena and GAE. Both CRUD and Fixtures under refactoring in order to suppor new, NOSQL model types
3) the reason why you do not need a build system, because you just do not need to build/compile the project in the traditional java sense. Play compiles the classes for you, on the fly (unless you want to precompile for production in order to avoid the compilation warm-up hit at the first request).
Even though you can package applications as war files, the majority of the sites in production are not using a standard servlet container *at all*. They are just using play as the platform.
4) it’s a new framework, so yeah the community is not as big as for older frameworks but it is growing rapidly. not sure what you mean by limited modules. Considering other framework, play’s module repository is huge.
5) bazaar is only used for the core lib. Anything else is on github. This topic is coming up time to time. So hopefully it will be changed in the future.
HTH