Preface

We were early adopters of Play and saw it gain popularity among a wide variety of Play developers. Now it’s time for Play to go mainstream.

Play 1.0

When I first tried the Play 1.0 release in 2010, I was struck by how simple it was. Having tried many different web frameworks, it was a refreshing change to find one that used what I already knew about HTTP and HTML (the web) instead of being based on non-web technology. In fact, the developer experience was so good, it felt like cheating.

I was also impressed by how finished Play seemed: this was no early experimental release. Many open-source projects adopt the “release early, release often” philosophy, which means a first public release is a version 0.1 that’s more of a prototype, vision statement, and call for participation. Play, on the other hand, started at version 1.0 and had clearly already been used to build real applications. Zenexity used Play on customer projects for some time before releasing version 1.0, and it wasn’t just Java developers using Play; web developers had been using it too. You could tell.

The idea that Play would be for web developers, not just Java developers, turned out to be the most important of goals because of the consequences for the framework’s design. After years of struggling with frameworks that make it hard to make nice HTTP interfaces—even at the simplest level of building web applications whose URLs weren’t ugly—here was a framework that actually helped. Suddenly we were running with the wind.

At first, we figured that this was a small framework for small applications, which was nice because it meant that we wouldn’t have to use PHP any more for easy problems. What actually happened was that each Play application was bigger or more complex than the last, and was another chance to get away with not using Java EE. We didn’t just get away with using Play; by the time Play 1.2 was released in 2011, we started to get away from having to use Java EE, and JSF in particular, which had become the new JSP for me (only more complex).

At this point, it only seemed fair to help more Java web developers start using Play. And then there was Scala.

Play for Scala

For us, Play 2 came at a time when we were discarding more than just writing web applications with JSP or JSF. We were also starting to use Scala instead of Java. The Play early adopters and the Scala early adopters then found each other, and we realized that the combination is even more compelling.

When we started talking to people about moving on from Java EE, we discovered that people can get upset when you suggest that the technology that they’ve devoted a significant portion of their career to mastering is an architectural dead end, and that it’s time for something new. Moving on is hard, but inevitable if you don’t want to be the next COBOL programmer. You know you’re a junior developer when none of the things on your CV have become legacy yet.

In our business, it’s important to be ready for something new. As with many kinds of beliefs, you’re going to be happier if your technology choices are strong opinions, loosely held. The arrival of Play 2 was clearly not just a new version; it was a challenge to take what we’d been doing to something more mainstream.

At Lunatech, technology adoption follows a kind of progression, starting from a single enthusiast and initial experiments, moving on to low-risk use by a few people, and finally to full adoption on development projects for external customers. At each stage, most technologies are discarded; Play and Scala survived this natural selection in the technology space and are now used by most of us on nearly all of our new projects.

Having made this kind of change before, we understand that switching to Play or switching to Scala can be a big step, especially if you do both at the same time. We were open to the idea that something more than a few blog posts and some documentation was needed, and we came to the surprising conclusion that the world needed another computer book.

Learning from Play

A rewarding aspect of Play is that while you learn it, you can also learn from it. First, Play teaches the value of a good developer experience, largely by making various other frameworks look bad. Then Play teaches you how to do web development right, and also about the future of web applications.

Play’s design teaches us the value and elegance of embracing web architecture as it was intended to be used. It does this by offering an HTTP-centric API for writing stateless web applications with a stateless web tier and REST-style APIs. This is the heart of what we cover in this book and the key to Play’s approach.

Getting beyond the failed vision that more layers and more complexity would somehow be simpler, and discarding the accumulated detritus of the Java Enterprise Edition dystopia will be the least of your worries in the long term. Play’s API also teaches us that in the future you may need to master a new kind of real-time web development: reactive web programming.

But to start with, the challenge is to learn how to build the same kind of web applications that we’ve been building for years in a better way that’s more aligned with how the web works. The difference is that this time it’s going to be more fun, and this book is going to show you how. This time around, work is play.