My Experience with Play! Scala

A few months ago I experimented with the Play! framework, which at the time was only available in Java. I had originally intended to do a blog post on Play! but never got around to it.
 
In summary, it wasn’t good. The Java version of Play! actually uses an internal compiler which adds magic to the mix. What looked like Java was actually a close relative to Java using nearly-Java syntax with a few special properties. While I had other issues as well, that property alone was an instant deal-breaker. Use Java or don’t, doing it half-way is a no go.
 
So when I heard that Play! Scala was gaining popularity, I was intrigued.
 
 

What was I Looking For?

 
My exploration of Play! Scala was actually prompted by the Product Owner I am currently working with. He recently took up Ruby on Rails with the intent to be able to do rapid prototyping of concepts for customers. The prototypes help him determine the customer’s real wants/needs so that he can communicate them more easily to his teams, and get a better end product. So far the concept works quite well.
 
So why Rails? Well, our code-base is primarily Java, so non-Java code inhibits the temptation to keep a prototype. Rails also allows very fast prototyping. You can be doing basic CRUD moments after the rubber hits the road, allowing prototypes to even have limited functionality to more fully test user’s expectations.
 
However, as I am a strong proponent of Scala’s extensibility and power, I was curious; why Rails?
 
Is it possible for Scala to provide the same ability to build prototypes extremely quickly?
 
 

What I Found

 
Play! Scala has some real strengths:

• Development lifecycle very similar to a dynamic language – edit, and refresh
• Type-safe code without having to declare types often (type inference)
• Type-safe templates based on the Scala language
• Very fast to go from nothing to running

 
Unfortunately, it’s not ready:

• “Automated Testing” is done by clicking a button in the browser. I want CI.
• Had a hard time getting CRUD running for Scala
• Documentation could use some work 😦

 
Interestingly, CRUD likely would have worked, however I had already tore out the ScalaQuery JDBC implementation in favor of my preferred Squeryl.
 
A more thorough tutorial/example would have likely got my CRUD working before I attempted something like Squeryl.
 
In fact, a good start-to-finish tutorial application (like a basic Blog), complete with CRUD and authentication, could probably mature the basic “rails” (pun totally intended) of Play! Scala to the point that it could directly compete with Ruby on Rails for rapid prototypes.
 
Of course, for scalability Scala has many other options that are almost as fast; I’ll take Lift any day, but I’ve also heard amazing things about Scalatra, Spray, and a few other frameworks.
 
 

Final Thoughts

More/Better Tutorials.
 
Maybe integrate into SBT instead of having a separate executable if Play! Scala is “true” Scala.
 
Deliverable WARs instead of Play Apps to take advantage of a more well-known deployment lifecycle.
 
Easier hooks into testing, with the intent to enable automation for CI.
 
Lots of potential here. Given a little more maturity, Play! Scala may become a real option in my mind. For now, it’s a very interesting project that just has a little further to go.