I’ve heard a ton about the Play framework over the
last few years. It is touted as the go-to framework in
Java these days. What do I think? I think they have spent a ton of money
marketing the framework. Play isn't entirely bad. But, simple tasks tended to be an uphill battle.
A
little background about me. When it comes to web frameworks, I LOVE
rails. Recently though, i’ve begun to thirst to move back to a Java based framework. I wanted to try a new framework, and I have experience with Grails, so I decided to give Play a try.
First off, I decided to try Play with Scala. I immediately ran into a major issue. There is no official ORM. Play uses something called Anorm, Anorm is Not an Object Relational Mapper. Play has some interesting stances on ORM's. They believe, that because you will have raw SQL queries in every project. That all your lookups should be written in SQL. I could not disagree with this more. This slows down development significantly, and in most cases, will have an insignificant effect on performance. I am a strong proponent of avoiding premature optimization. This seems to be a large case of encouraging it.
I wasn't going to build my app without an ORM, so I started looking for some good solutions for Scala. I ended up finding a lot of people recommending Slick. Slick isn't quite an ORM but it seemed better than raw SQL. I added it to my project and began using it. Though, It wasn't long before I came along a major issue for me with Slick. The default projections don't support auto-incrementing values in PostgreSQL. This means, you have to provide a separate projection for each and every one of your models, just so you can use auto incrementation. This was a lot of boilerplate I simply did not want to put up with.
By this point, I had spent several hours trying to get everything configured and working. I finally had a simple CRUD set up, but I hated every minute of it. The worst part is that to get to this spot for a brand new Rails user, it would take them ~30 min. I decided to call it quits on Play with Scala. I was not building a performance critical application, I was building a "my time" critical application.
Next I decided to try out the Java flavor. Generally, this was a much better experience. Play came bundled with a easy to use/understand ORM, EBeans. Everything was pretty much as advertised. I had 2 major issues with Java version. First, everything is very verbose. Second, I hated the Scala templating that is used.
Play isn't to verbose, until you start nesting packages. But, due to the fact that everything is in Java, as soon as you start nesting, things become very long. For example, I had a package structure:
controllers -> dashboard -> VideoController
Normally accessing a routes file inside the controllers folder is as follows.
First off, I decided to try Play with Scala. I immediately ran into a major issue. There is no official ORM. Play uses something called Anorm, Anorm is Not an Object Relational Mapper. Play has some interesting stances on ORM's. They believe, that because you will have raw SQL queries in every project. That all your lookups should be written in SQL. I could not disagree with this more. This slows down development significantly, and in most cases, will have an insignificant effect on performance. I am a strong proponent of avoiding premature optimization. This seems to be a large case of encouraging it.
I wasn't going to build my app without an ORM, so I started looking for some good solutions for Scala. I ended up finding a lot of people recommending Slick. Slick isn't quite an ORM but it seemed better than raw SQL. I added it to my project and began using it. Though, It wasn't long before I came along a major issue for me with Slick. The default projections don't support auto-incrementing values in PostgreSQL. This means, you have to provide a separate projection for each and every one of your models, just so you can use auto incrementation. This was a lot of boilerplate I simply did not want to put up with.
By this point, I had spent several hours trying to get everything configured and working. I finally had a simple CRUD set up, but I hated every minute of it. The worst part is that to get to this spot for a brand new Rails user, it would take them ~30 min. I decided to call it quits on Play with Scala. I was not building a performance critical application, I was building a "my time" critical application.
Next I decided to try out the Java flavor. Generally, this was a much better experience. Play came bundled with a easy to use/understand ORM, EBeans. Everything was pretty much as advertised. I had 2 major issues with Java version. First, everything is very verbose. Second, I hated the Scala templating that is used.
Play isn't to verbose, until you start nesting packages. But, due to the fact that everything is in Java, as soon as you start nesting, things become very long. For example, I had a package structure:
controllers -> dashboard -> VideoController
Normally accessing a routes file inside the controllers folder is as follows.
routes.Application.action
But, this is what needs to happen to get to my nested routes:
controllers.dashboard.routes.VideoController.action
This is bad for two reasons. First, there is an extra 13 characters per reference to a route. Second, this doesn't logically make sense. I am accessing my routes object, but it is 3 deep in the sequence. This syntax seems very backwards to me. This type of very verbose language is used throughout the framework.
The last thing that killed it for me though was the Scala templating. Generally I liked the ideas presented in the templates. But, finding documentation on them seemed to be a huge pain. I simply wanted to know how to assign a variable I could manipulate through the template. And, I ended up on this page. It is a whole discussion on how to create local variables in the template. These type of basic things simply shouldn't be difficult to do.
What did I like about Play?
- It is blazing fast. This is the single reason I didn't quit after trying it with Scala. I wanted this speed right out of the gate.
- Evolutions, these worked amazing with EBeans. Not worrying about writing migrations when you are starting a project is a huge plus.
- Strong Typed - I really enjoy working in strong type languages. It makes changing view parameters and method signatures great. You immediately know when you missed something.
In the end, I would only recommend Play to someone if they needed a very high performance framework. Generally, I felt like this framework was making me do all the work. I think a framework should make me feel like it's doing all the work. Play does have some other strong points that I did not have the need/patience to try out.
If you are looking for a web framework to get you off the ground and running in a short amount of time. Play is not your framework.
