Proof of Concept: Play! Framework

We are starting a new project and we have to choose the web framework. Our default choice is grails, because the team already has experience with it, but I decided to give Play! and Scala a chance. Play! has a lot of cool things for which it received many pluses in my evaluation, but in the end we decided to stick with grails. It’s not that grails is perfect and meets all the requirements, but Play! is not sufficiently better to make us switch. Anyway, here’s a list of areas where Play! failed my evaluation. Please correct me if I’ve got something wrong:

• template engine – UI developers were furious with the template engine used in the previous project – freemarker, because it wasn’t null-safe – it blew up each time a chain of invocations had null. Play templates use scala, and so they are not null-safe. Scala has a different approach to nulls – Option, but third party libraries and our core code will be in Java and we’d have to introduce some null-to-Option conversion, and it will get ugly. This question shows a way to handle the case, but the comments make me hesitant to use it. That’s only part of the story – with all my respect and awe for static typing, the UI layer must use a simple scripting language. EL/JSTL is a good example. It doesn’t explode if it doesn’t find some value.
• static assets – this is hard, and I couldn’t find anything about using Play! with a CDN or how to merge multiple assets into one file. Is there an easy way to do that?
• IDE-support – the only was to edit the templates is through the scala editor, but it doesn’t have html support. This is not a deal-breaker, but tooling around the framework is a good thing to have.
• community – there is a good community around Play!, but I viewed it compared to grails. Play! is an older framework, and it has 2.5k questions on stackoverflow, while grails has 7.5k.
• module fragmentation – some of the important modules that I found were only for 1.x without direct replacements in 2.0.

Other factors:

• I won’t be working with it – UI developers will. Although I might be fine with all the type-safety and peculiar scala concepts, UI developers will probably not be.
• scala is ugly – now bash me for that. Yes, I’m not a Scala guy, but this being a highly upvoted answer kind of drove me off. It looks like a low-level programming language, and relevant to the previous point – it definitely doesn’t look OK to our UI developers.
• change of programming model – I mentioned the Option vs null, but there are tons of other things. This is not a problem of scala, of course, it even makes it the cool and good thing that has generated all the hype, but it’s a problem that too many people will have to switch their perspective at the same time
• we have been using Spring and Spring-MVC a lot, and Play’s integration with spring isn’t as smooth as that of Grails (which is built ontop of spring-mvc)
• http://zeroturnaround.com/blog/play-framework-unfeatures-that-irk-my-inner-geek/

As you can see, many of the problems are not universal – they are relevant to our experience and expectations. You may not need to use a CDN, and your UI developers may be scala-gurus instead of groovy developers. And as I said in the beginning, Play! definitely looks good and has a lot of cool things that I omitted here (the list would be long).