Play Framework

It’s been a week with the play framework. The summary? Play comes from France. The differences from frameworks I’ve used in the past are very significant, and frankly, it feels like I’m driving on the wrong side of the road. Some video comparisons are in order, from the most detailed European cultural guide we have.

First impressions:
Big ben

“Wrong” side of the road. Not sure what’s going on. BTW, yes, I’m aware that this part of the movie is not in France.

After a week (brief nudity. Deal with it):
Oink Oink

In this video, I’m Rusty. Oink oink, my good man.

For the past few years I’ve been using Seam, which is a great framework for Java web development. You get a lot for your time, and the component model really makes complex forms easy. On the negative side, its a pretty heavy weight implementation. Also, a lot is hidden from you, which is good in some ways, but if you have a problem, you could be churning for long periods of time.

One of the best features of Seam is the “Conversation” scope. Once you start using it, you use it pretty much everywhere. Its all kept in Session state, but it tracks a “thread” of pages, so you don’t wind up in that situation where you edit stuff on one page and it screws up what’s on another because they share the session. In all, my experience with Conversation has been great. The idea of moving to a framework without that stuff was a little scary.

Play comes from a completely different direction. Not only is there no “Conversation” scope, there’s no Session scope. That’s a pretty radical departure. For all of its problems, I think pretty much every framework out there includes some form of Session. For all of the bad that the Play people have to say about Session, I’m still not convinced its the root of all evil. It feels a little like throwing the baby out with the bath water.

However, I will admit, the stack is greatly simplified. One of the main reasons I wanted to find a new framework was so I could deploy on distributed services like Heroku and Google app engine. Seam apparently can work on GAE, but with pretty severe restrictions. I doubt anybody has tried Heroku. If we can get most of what we need with Play, or something similar, the trade off may be worth it.

What I really want. Since most of our work now is mobile apps, I want a framework that can talk to mobile apps about as easily as standard web pages. I want to be able to mock up ideas quickly and deploy them without a whole lot of hassle. I’d like to be able to use a service like Heroku, where you just push your app out and you don’t have to worry too much about config and scaling, rather than say renting AWS instances and managing whole Linux installs.

That doesn’t mean that every app would stay on Heroku. In my experience, pretty much every app needs something that you just can’t do on a shared server. Some custom program, or a special database. Whatever. On the flip side, most app ideas get a prototype build, and are then abandoned, with is a good thing. Rather than spending lots of time setting up new server and DB instances, just push and get it live. See how it works.

Play has some interesting things going on, and I’m still learning quite a bit. Some of it worries me. I’m concerned that some of the stuff it does automatically will not be what you really want, but so far, it seems like its been built to do what you really want, by default.

For example, if you have a few data objects in your code, and you want to be able to use them in the view layer, you simply call “render” with those data objects as parameters:

render(userData, shoppingCart);

The template engine actually gets access to those params, by name.

$\{userData.username\} has $\{shoppingCart.countItems\} items

Its a little weird at first, because Play is obviously doing some type of reflection. You’d normally expect to reference those params as “param[0]” and “param[1]”, or something like that, and it certainly opens the door to refactoring issues (renaming the params in Java code), but in all its pretty concise and convenient.

Play also keeps itself “pretty close to the metal” with regards to the HTTP spec. Play does not abstract away too much. It goes out of its way to easily enable a REStful architecture as well. The end result is a framework that doesn’t get too in the way of what you’re trying to do, but doesn’t leave you doing it all manually either. So far, its been a pretty good mix. I have tired MANY web frameworks, and most can not claim anything close to a “good mix”.

One of the big issues with any “roll your own” frameworks is the tendency to do EVERYTHING new. Java has a shocking number of web frameworks, and they all have the same general mission statement:

“We were tired of the bloated frameworks. We wanted something simple and powerful (yada yada)”

What’s funny is that EVERY framework says that, and EVERY one is simple and powerful to the people who build it, and seems bloated to those who use different frameworks. It may be something inherent to web frameworks, because there are so many. I can name 3 people who built their own frameworks because they thought the ones available were all bloated or whatever. Here’s a tip. If you think you need to create a new web framework, don’t. The chance that there isn’t another “lightweight, simple, powerful” framework out there that would be good enough for what you need is basically zero.

I’m rambling. What I was getting to was Play seems to do a good job of rolling their own new code for some things, and reusing or enhancing what’s already done really well. I’m excited that they didn’t reinvent the wheel with ORM and data storage. Instead they use JPA, backed by (I believe) Hibernate. If they had done their own thing, I wouldn’t even have tried Play. Most of the people that write their own web framework are a little unhinged and think pretty much EVERYTHING that’s out there sucks and they’re so brilliant they can make something better, by themselves, in their spare time no less. Using the best of what’s out there is, to me, a sign of practicality that’s critical with these kinds of things.

The negatives of Play. First of all, I’m not convinced that Session scope is the end of the world. I do think if I can get in the Play habit and not need Session, that’ll be nice, but there are times when not having that available with be painful.

The community is growing, but its tiny in comparison to other communities. There are so many web frameworks that I doubt any single one will get major industry attention, unless its something like Seam. Seam is built on top of JSF, so they can play the “Standard” card. Other web frameworks, like Wicket, or the venerable Tapestry, are proprietary, and generally get ignored by IDE makers and major industry people. Grails is a strange exception, which seems to get a lot of attention (or at least it did), but I think that’s because its trying to copy “Rails”, which I never really liked to begin with.

I’ll have to back and edit this later to make sense, but the summary is, so far, Play is great. As a framework that plays well with web and mobile clients, has fast development cycle (no “redeploy”, thank god), and can be installed on shared server farms, its pretty damn nice. There is a level of productivity that I had with Seam that I don’t have with Play, but I suspect that’s a temporary issue.

However, there are some things that may never get to the same level. Try entering a date on a form with Play vs Seam. Perhaps I haven’t found Play’s “date” component or whatever, but with seam (and richfaces), entering a date is a pretty simple situation.

Off for now. More later.

-Kevin