Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
Play! Framework is getting a lot of praise. It is growing in usage and popularity. You can spot presentations about it at conferences, numerous blog posts etc. Even I praised my favorite features of the Play! Framework couple of months ago, My Top 5 Play Framework Features. There is so much positive feedback about it, that I thought it would be a bit refreshing to list the features (um, “un-features”?) that really get on my nerves. Here is my list of Play! un-features that limit my productivity, encourage me to read slashdot.org, and really irk my inner geek…
Application Startup Time Grows with Application Size
If you create a new application in Play! and start your app via
play run then it takes about 2 seconds for the application to start. Basically just the time to switch to your browser and hit refresh. Once your application grows in size the startup time also grows. Our application starts for 28s in development mode (on my MBP with a SSD). This is already enough time to take a quick peek at your Google Reader. Of course the same is true for any JEE application, at first they are blazingly fast but as time goes on the startup times just grows and grows.
Reloading 3rd Party Library Code
Play! Framework applications have support for really quick turnaround because a large part of the application code changes can be reloaded instantly. So you add a method, change params and you don’t need to restart the app. This is all freakin’ awesome, but the moment you happen to develop a library that you are using within your application, you need to make room for restarts. Every code change then requires a restart. Not so happy anymore (let me find my jrebel.jar file!)
Play! Framework templates are quite the memory hog. You might not notice it in the beginning, but once you have some larger pages and more users, then you will see a spike in memory consumption. This is due to the design of sub-templates. The sub-template is read into a String variable on every request that uses it. This will spike memory usage to the effect of the HTML file size. You can bypass this by giving your app more memory, having smaller templates and moving static content into static files instead of templates. There is also a more effective memory usage on the way in the 1.2.x branch.
Fear of Upgrade
Upgrading has been a bumpy ride so far, (the minors not so much) and the leap from 1.0 » 1.2 was quite scary. Our tests started failing left and right once we packaged our application. We stumbled upon quite a few bugs and the choices in the end were to either use our custom build of Play! framework, or downgrade. We chose the first option. Now another major version is looming and a lot has changed again–check out the graphics at the 2.0 page. I’m afraid that our products will need a major overhaul if we want to get on to the next bandwagon. It just scares me.
An Issue Here and There
Play! Framework is guaranteed to surprise you when you least expect it. Just the other day I got a report from a colleague, saying that he got a verify error from Play! code. Ok, great. What can I say, try to reproduce and file a bug report? Or what about these:
- You’re programming some feature and suddenly you start getting ClassCastExceptions. Oh well, I restart and I’m unable to reproduce. Not enough for a bug report, but there seems to be something fishy with Play! Framework reloading and Jobs. Oh well, lets hope it won’t happen again any time soon.
- Everything is super until one of the Jenkins nodes is showing failing tests. You dig for couple of hours and you find there is special handling of a folder with a dot preceding it, finally resolved.
- You find a controller method that produces OutOfMemoryErrors because of the dark bytecode magic that is happening behind the scenes. You’re able to reproduce it, but when submitting a bug report you try to reproduce on an empty application, which just won’t happen. You add a @ByBass to your own method and the problem goes away. Argh!
These small issues that pop up suprisingly end up stealing confidence and time. You start doubting the underlying system and lose the edge that this tool is supposed to give you. Just imagine the problems you will stumble on once Python, Groovy, Ivy is replaced by sbt, Scala, Akka.
So why do I still use Play! Framework?
When writing this piece @ekabanov asked my why on earth are using this framework then? My answer was, well, we would have just as many issues with any framework out there, but the nature of those issues would probably be different. You will always stumble upon bugs, you will always have problems when the application grows in size, and, of course, you will have problems when upgrading your dependencies. So far, there is nothing to be done.
I’d love to hear about your pet peeves with Play! Framework – please leave your comments below!