Guillaume Bort and Sadek Drobi made two big announcements last Wednesday, 16th November at the Devoxx 2011 conference. First off, Play! 2.0 is available in beta form for download on the Play! Framework web site. Within hours, there were over 4,000 downloads (see Twitter here).
Secondly is that Play Framework is now the official web stack of the Typesafe products, Typesafe being the company created by Martin Odersky, creator of Scala. And last but not least, Guillaume Bort is joining the company’s Advisory Board, alongside James Gosling and Doug Lea.
Nice, hey?
But let’s back to the Devoxx presentation and what I thought of it. I’ll try to not be too enthusiastic, but this will be hard (as I am a Play Framework evangelist as part of my daily work).
Sadek Drobi is Zenexity’s CTO. Guillaume Bort is the co-founder of the company, and the original author of Play! Framework. As Sadek explained, Play! was born because of internals needs for their company, as a secret weapon to rapidly develop Java applications. The framework has been open-source as of the end of 2008. But right from the beginning, it’s was a framework designed for « real-life projects » for « real-life customers ». Not as a project you use to solve non-existant problems.
(Sadek with its hat and Guillaume)
I remember when Play! Framework was presented at a BOF at Devoxx 2009. 2 years later, there’s 3 conferences at Devoxx and one BOF. I’m looking at Devoxx 2011’s schedule, I don’t see any other web framework that had such exposure this week. This makes some of my friends cringe, but it definitely shows the interest the community has for this framework.
Why Play 2.0 ?
Since the beginning, Zenexity worked closely with the community. Play 1.x is now a very popular web framework, being simple and productive. However, adding functionalities is like creating a mega sandwich (or burger… or whatever) : that is, it becomes less maintainable and harder to patch. Plus, there’s a lot of “magic” going on in the core of Play 1.x (Maybe a little too much).
Second point is that meanwhile, the Web is evolving. People, especially in the Java community, are discovering a new world where a stateful approach might not be the only way to build web applications. Sadek and Guillaume say that we can really feel that architectures are changing, and this will have an impact on web frameworks. The very first Web frameworks were based on a static page approach. A single page generated by Perl, PHP or simple Java techniques. And this is still OK… if your content is static.
Web architectures on the server side needed to adapt to be able to work asynchronously with web clients. For instance, Ajax and related techniques like partial page refreshes gave birth to great web applications such as GMail. From a static page view, we moved to a dynamic approach on the server. Web frameworks were proud of this… especially JSF folks. One needs to understand that when usages changes, all web frameworks are impacted. Some are good for AJAX, some suck… I won’t give any names, but you see what I mean.
Today in 2011, the new challenge is easy web service integration and asynchronous processing. On a lot of web applications, you have to be able to link and reuse APIs such as Facebook API, Twitter OAuth, Google OpenID, or maybe your company SSO system that cost a tank… We know that to build a modern web application, the web framework has to be able to glue all these services together. And it has to be able to handle huge amounts of data, and the huge amount of things that can go wrong. Maybe tomorrow, a really good Web Developer will be the person that has a strong knowledge on Web APIs (OAuth, Github API, OpenID), and that is able to create value-added services from these external APIs.
From a technical point of view, Sadek explains that the Java Servlet API is very limited. We hope that Java EE 7 will propose a more modern approach. Java Servlet is just too… low-level. One important issue is that it’s impossible to split a task and configure threads, memory and CPU in a Web application. If you visit a page, you go through a Servlet. If you upload a file, another Servlet. Wouldn’t it be interesting to route the content in your application (and not in a crappy “web.xml”) and really focus on the business part ? It’s not normal that your application’s home page can blow up if someone else starts uploading a large file in another part of your application.
Web frameworks have been created to be the central point of the architecture, whereas Sadek and Guillaume think that being Client-focused (as in, clients of your application) and having an adaptive server are more important.
Basically, “server” should be written with a lower-case “s” and “Client” with an upper-case “C”.
What is also important to keep in mind is that the amount of data and the flow of data between Clients (browsers, other web apps, your iPhone…) and the server are evolving at a very fast pace. It’s not at all easy to write concurrent code, and this was something that Play 1.x was not designed for. Play 2.0 is not here as an evolution or replacement of Play 1.x. It’s here because we’re moving forward, baby. We have to adapt and be ready for these new kinds of applications we haven’t thought of before. You see what I mean ?
Sadek Drobi goes on to say that when a Java developer creates an application for the Web, he tends to have a sort of “automatic behaviours”. The first one, regarding the datastore, is to pick an ORM. And this is stupid. What for ? Because you can forget SQL ? ORM are a perfect tool… when you need it. And no, you don’t need an ORM every time, every where.
Take a look at your application. First, do you use honestly use advanced relational mapping in the database ? Yes ? And is it really useful ? How much time did you lose on Play 1.x with @OneToMany, @ManyToOne, @MaybeOneOrTwoToTooMany annotations ?
On the client side, especially in the browser, we have also new web technologies that ease the web app development. Personally (and I usually blog about this in French), I think that if you (yes, you there in the back) don’t want to learn HTML/CSS/HTTP, then you are in serious trouble. OK, let me be honest : you suck. Either learn basic web stuff or go back to your Cobol stuff.
Now, back to the presentation. So we have these new tools such as Sass, CoffeeScript, Less or jQuery. Guillaume explains that it would be also interesting to integrate these tools in Play 2.0 so that you get compilation and validation for CoffeeScript or Sass, for instance.
In a sense, Play 2.0 was born because they (Sadek and Guillaume) wanted to create not a v2 of Play, but a v2011 version of it. Something that is more mature, less magic, more type-safe, more solid. Something that is able to handle all the new use cases they talked about.
This is important point : Play 2.0 is more of a whole new framework that just an evolution of Play 1.x.
When we explain what is Play! Framework to someone for the very first time, especially to Java developers, we present it as a full-stack framework. You write java code in your editor, you switch to your web browser, hit refresh, and it works.
Java developer : No more console and maven hell. Play 1.x relies on Eclipse’s IDT compiler, the one we’ve been using for years : it just works.
Java developer : No more crappy logs in a console Play 1.x reports errors in the web browser. If there’s a compilation error, well, you see it in the browser. Forget about looking at logs files like a teenager with an adult magazine : no more logs.
What is also important is that Play 1.x is not a stateless web framework, but a « framework sans état conversationnel du côté serveur » wich translate into English as « a framework that respects web standard, has no conversation, thus no state on the server, as HTTP is from the beginning… »
The code editor and a web browser. That is all you need to work. Even better, you can use VI/Emacs/TextMate or any basic text editor, since all the work is done by Play! Framework. However I recommend IntelliJ for its good web support (JS/HTML/CSS/Java/bla bla bla).
Guillaume worked really hard to keep exactly the same spirit in Play 2.0 : productive, simple, no logs for dummies, no maven/gradle stuff, no xml… just being productive (and having fun, but that is another story).
Play 2.0 is a web framework that is able to compile, deploy, download dependencies, launch asynchronous jobs, runs tests, send emails and even (but we’re not 100% sure about this feature) prepare a good coffee if you need it.
Démonstration
Guillaume did a good demonstration of Play 2.0. Firstly : no more Python for the tooling and no more Groovy for the templating (compared to Play 1.x). Play 2.0’s engine is Scala. But hold on… don’t run away… no, you won’t have to learn Scala. You can write your code in Java or Scala, Play doesn’t care. The template language is Scala. But it’s very simple and there’s only a few tags to learn. It took me 1 day to understand how it works. And I’m happy to be able to do advanced stuff with Scala, when needed, in the view.
For Java, Guillaume removed Hibernate and took Avajé EBean. It’s a lightweight stateless ORM, that is less powerful than Hibernate. But it’s perfect for Play, it’s JPA compatible if I’m remember correctly. For the Scala part, Sadek implemented a simple SQL engine called Anorm. I started to use Anorm in May, spent some time with Sadek in August to fix some bugs, and I like it. Simple, easy to learn, not too much « scaletist » and just fine for a Scala beginner like me. You can also use some other Scala/SQL libraries such as ScalaQuery : it’s very easy to flip from one lib to another.
The very first characteristic of Play 2.0 is that it’s based on SBT, Simple Build Tool. As you can imagine, SBT is now the one in charge of dependencies, incremental compilation, tests, packaging, documentation and maybe (but not sure about this one) preparing a good coffee. It’s even easy to launch SBT and import Play commands into SBT. You also get tooling support for Eclipse and IntelliJ with SBT.
The template engine is new in Play 2.0. This is maybe the biggest difference between the 2 versions of the framework. I know that one of the Play core developer is working on porting the Groovy engine to Play 2.0. It will work, but does it makes sense ? Not sure about that.
Templates are HTML files with very little Scala code in them. Everything is strongly typed. Less errors, more validation at compile time, and maybe fewer tests since there’s less dynamic in the code. Each page declares the list of parameters, everything is transformed to Scala then compiled to byte-code. In terms of performance, the new template engine is 15 times faster than the previous one.
One important point : in order to write a view page with Play 2.0’s new template language, you don’t have to be a Scala Jedi Master. The syntax is easy to learn, and you have access to the power of Scala when needed. I also think that this is a good way to discover and learn Scala, if you only use Java for the controller side.
I had a really nice use-case recently, where Scala was really powerful. I wrote a Contact application. There’s a web page with a list of people ordered by last name. Here is an extract of one of my templates for Play 2.0 :
Play 2.0 in details
Sadek and Guillaume then go on and explain what is really new in Play 2.0. First, existing solutions in the Java world suffers from a very low-level approach. Let’s say you want to implement a file upload functionality. With the traditional approach, based on java.io.InputStream, it’s very complex to correctly write an application that does not block on I/O. The read() method in InputStream reads one byte after another. This is OK if the server is able to handle the reception of the byte stream. However, it tends to create resource deadlocks, where the server hangs and does not respond to incoming requests anymore. Sadek, who is also a very good Haskell developer, explains that they decided to adapt the Enumerator and Iteratee pattern in Play 2.0
Play 2.0 has a completely new approach, it applies inversion of control on the way the controller and the client exchange information. What is really awesome is the way it handles an incoming request. First, in the connection layer, Play 2.0 is like Play 1.x : a single thread listens for and dispatches any incoming requests (just like Node.JS, for instance). The request is then dispatched to either a limited pool of workers. If you annotate a part of your code in the controller with the @Asynchronous annotation, Play is then able to suspend your request, thus freeing one thread, while an asynchronous activity does something. Enumerator and Iteratee is a nice pattern where the asynchronous task tells the Enumerator when it completes its work, and that it can resume. It is much more efficient than the classical Future + Pooling approach we had in Play 1.x. And this is also why you now understand that Play 2.0 doesn’t care about the Servlet API, it just wouldn’t be able to work like this.
An Enumerator sends data to an Iteratee. The Iteratee executes a function, does something, and sends a signal back to the Enumerator with a status. See also the Continuation passing style » that is explained in Haskell documentation.
Well, you may say : why is this interesting ? Why should I care ? Well my friend, now you can start to write asynchronous web servers « à la Node.JS » (this is French) but with Scala or Java. Play 2.0 is much more functional. The code is easier to read, it’s also easy to split up long processing operations to speed-up your server.
To orchestrate everything, Guillaume and Sadek decided to use Akka. It’s a very powerful and simple Actor-based framework. I wrote an application for a startup, where we had to post-process uploaded images and generate PDFs : Akka is great. The code is easy to test, there’s no middleware stuff, ant it’s simple and very easy to develop in.
Akka is a powerful tool that lets you write asynchronous code very easily in your application. What I particularly like about it is that the thread pool and all the general fine-tuning is managed outside of your code. If there’s a new framework you need to look at, definitely check out Akka. Great tool.
Here is a sample from Play 2.0 that Guillaume showed at Devoxx. The search function receive a keyword. The AsyncResult is interesting because it tells Play to handle the code as an asynchronous function. While the search operation is done, the server frees up the resource and let the system handles another request. The Iteratee pattern is then used : when the search result is available, the html.results template is executed to generate the HTML response. The double-bang (!!) means : send the « keywords » to the searchInternet’s Actor. As you can see, the searchInternet could be anything, there’s no functional code here.
def search(keywords: String) = Action {
AsyncResult {
(searchInternet !! keywords).map{
found => Ok(html.results(found))
}
}
}
Sadek talked also a little about the data layer in Play 2.0 : either a relational database or NoSQL databases like MongoDB, etc. Play 2.0 does not try to hide the fact that there’s a data layer in your application. If you want to use Neo4J or PostgresSQL, well you can.
In Play 2.0, Guillaume decided to drop Hibernate 3 in favour of EBean. Why ? Well, Hibernate is a great tool and all, but it’s just too powerful for what we usually need for Play. It was really hard to set up the asynchronous part with Hibernate sessions. On the other hand, the java community really wants an ORM in Play for the Java part. EBean is simple to use, and offers good compatibility. There’s also some Spring 3 in Play 2.0 for the Bean binding and JSR-303. So EBean is simpler and better-adapted to Play 2.0.
For Scala, Sadek wrote Anorm (An Not ORM). Based on Scala’s complex parser, it’s a very simple parser technology that removes the JDBC boilerplate and offers a nice match/case engine. But if you don’t like Anorm, you can use ScalaQuery or whatever your favorite Scala technology is.
Guillaume also demonstrated that Play 2.0 is bundled with support for client-side tools such as CoffeeScript, Less or SASS. Play is a full stack framework. So it will compiles your CoffeeScript to Javascript. And last but not least, it is also capable of reporting errors in a CoffeeScript page for instance. This is just great.
With regards to “Cloud computing” support, Play 2.0 works on Heroku and soon, will also work on CloudBees.
Thanks to Akka, it will also be easy to distribute a work on multiple Play Servers. For instance, it will be possible to have a Play server as some sort of Front controller, that dispatches to another Play Server the « Image resize » operation (for example), and to another server the « Generate a PDF »… I don’t know if you realize how powerful this is. It will be easy to split up and create a flexible architecture. Something Java J2EE tried to sell 8 years ago.
The actual Play 2.0 core is not very complex. I spent a day with Guillaume and was able to understand how it works. In fact, there’s x4 less code. It’s thus easier to find your way around in your code.
On the performance side, Play 2.0 is 2 to 3 times faster than Play 1.x. On a MacBook Pro with an i7 processor with 8 cores, a simple Apache bench command shows that Play 2.0 manages just fine 40 000 requests per seconds. The network stack is JBoss Netty, one of the most powerful stacks for Asynchronous NIO in Java.
On the memory footprint side, their tests show that after a full GC, the heap is back to 2 MB…
Personally, if I have a negative feedback to give, it’s that the compilation is much slower with Scala. You lose the very quick turn-around/compilation experience we had with Play 1.x. Yes, it’s slower. Scala being more complex, it takes more time to generate the code and compile it.
Type safe
Play 2.0 also brings strong typing to the HTML template part. The first reflex is : damn, I prefer the groovy way. But bit by bit, I moved to Scala and started to really appreciate the type safe template engine.
The « routes » file is also compiled. Everything is compiled in Play 2.0. This is less error-prone. If you update a function in your controller and you forget to rename it in the “routes” file, Play will properly report the error. No more « 404 What the hell » exception.
To wrap things up, Guillaume did a nice presentation of the 3 applications they wrote in September. You have a complete CRUD application, an advanced HelloWorld and a complete application with authentication. I was happy to see that Guillaume took into consideration a suggestion I had back in September : don’t bother to give a stupid helloworld example. Give me a real application so that I can start to learn the framework, see how to set-up authentication, start to read some nice code… And please : no pet-store and no stupid hotel booking application.
By the way, dear reader, did you know that the Pet-store was actually a joke ? The idea to create a Petstore was suggested by a guy at 4:00 am after too many beers at SUN. Stop and think about this for a minute : would you really buy a bird on the Internet and have it shipped in a little box ? Come on… You can’t be serious… But apparently nobody was really surprised and we still believe that we can buy birds with a J2EE application… Ah ah ah.
What you won’t like in Play 2.0
Now my friends, let’s me be honest : Play 2.0 is not for dummies. A lot of people want to port their code and every day, they post a bunch of questions about migration patches and yada yada yada on the mailing-list. The question is : do you really need to migrate ? Do you really need to use Play 2.0 ? Maybe ya do, maybe ya don’t.
The templates are different, but it’s not too hard to port your code. The controller side is completely new. You can write it in Java or Scala. So don’t be scared : you don’t have to be a Scala developer (yet).
Play 2.0 was created to solve new issues and new architecture patterns. It’s more like a cousin than the little brother of Play 1.x.
However, and please read this carefully : Play 1.x is a community project and will be maintained by its core contributors (Guillaume Bort, Nicolas Leroux from Lunatech, Peter Hausel, Morten Kjetland, Erwan Loisant, Peter Hilton…). Zenexity has a lot of customers with live apps in production using Play 1.x. So Play 1.x is here to stay and is still a very interesting solution to look at.
If you want to learn Scala, Play 2.0 is really a great tool. I started to learn Scala in May with Play 1.x and play-scala, and it took me one month to start, maybe 2 months to really understand Scala and appreciate the language. As a Java developer with no functional background, I really like this language. Less verbose and not that hard to learn. Don’t be afraid of the fact that there’s are some hippie-guru-functional-heretics that talk about Scala like it’s their girlfriend. If you’re just a java developer, trust me : it’s easy to learn and to work with. Don’t give a shit about people that try to look smart with « Monad or higher-order function ». Soon you will be writing more Scala code than those pseudo-evangelists ever have…
One important point is that Play 2.0 is more like a new framework. If you want to write rock-solid applications and you need asynchronous/flexibility, then Play 2.0 is your guy.
I talked with Guillaume and at one point, I suggested that they change its name of the Framework to Play2 ([plèy square]).
But we will keep Play 2.0, that’s already a big evolution.
Other interesting and great resources:
– Play 2.0 official web site
– Another great article by Matt Raible. I hope to see him in Paris for Devoxx France 2012
– James Ward also wrote great articles about Scala, Play and Heroku
– Play! Framework also has a Twitter account : @PlayFramework
This article was reviewed by Roland MALAPRADE (@rmalaprade).
Nicolas Martignole is a freelance developer. He lives in France, in Paris. He is a Play evangelist. He created the eXpress-Board, a job board for enthusiastic developers, with Play 1.2. He is also a member of the Paris JUG team and he’s one of the 4 crazy geeks that decided to organize Devoxx France, a conference for developers created by freelance developers, from the 18th to the 20th of April 2012. You can follow him on Twitter @nmartignole.
Original article in French here.
0 no like
Nice job.
All the things one interested in Play 2.0 should know..Thank u for this great article about a great framework!
Hi,
I like Scala as much as any other person however seeing Scala embedded in html made me cringe. God knows that I have seen my share of ugly JSP peppered with Java code and now Play’s template kinda reminded me of old school JSPs. Can we please keep the presentation clean and simple and not go back to bad old days of JSPs
@Ashraf : It does indeed look like JSP… But is there any other technology that would allow type safe templates? I am just curious.
I found the discussion about I/O a bit confusing.
They seem to say that the problem is InputStream.read().
There is nothing wrong with « streams ».
The problem in classic servlet container is rather the one-to-one association between threads and socket streams.
That’s why an async servlet API has been created…
(It would not be an issue if thread stacks were not statically allocated.)
It’s rare that you can do something that improve both simplicity and performance.
I have worked with lift until now. I will try play 2.0, but I have to say, that the templating looks very designer unfriendly. What do you do with @ in the browser. Is it not possible to make it cleaner?
I would really like to see a side by side comparison with lift. e.g the security of lift against replay attaks (unique ids for each element etc..) vs play2.0.
Ashraf > A few months ago I would have agreed with you, but after all what’s the point of using things like taglib when a langage provides everything you need ? As long as you don’t right business login in the view, I don’t see the problem.
I just finished a midsize webapp with Asp.net mvc3, where the templating engine is named razor but you still use c# as a language.
In pseudo code it would look like that (in the view) :
@model com.acme.model.Album
@Model.Title – @string.Join(« , », Model.Artists.Select(x=>x.Name))
@foreach(var v in Model.Tracks)
{
@v.Title @v.Duration – @string.Join(« , », v.Composers)
}
It’s just pragmatic.
taglib (let’s say jstl in java) gives the illusion of a separation of concerns but forces to use/learn another stuff and cannot beat the builtin capabilities of the language itself (java, scala, c#, etc…), which also provide compile-time checking.
erratum : « As long as you don’t write business logic ». Must be late…