This section is reserved for stuff that you probably won't find out of the box in most other web frameworks except Play! 2. As this framework is pretty recent, it has directly embraced all the new stuff that is required for applications willing to stick with cutting-edge technologies, HTML5 being the first one.
HTML5 has defined a bunch of new concepts that aim to ease the work of all developers if their web frameworks allow them or provide APIs to support them. And that's the case for Play! 2 because of its architecture, which is very simple and does not try to abstract too much, that is, Play! 2 doesn't try to hide the fact that we're using HTTP and HTML to deal with a browser or a service. This results in the fact that a developer is able to add the support to a new header without hacking Play! 2, or is able to support a new type of streaming protocol without breaking the others.
The following are a few examples:
- Server-sent events: Part of the HTML5 specification, this concept enables a server to push events to a connected client. This can be enabled in Play! 2 using an open connection and can push data to it.
- WebSocket: This is yet another part of the HTML5 specification, which enables a bi-directional connection between a client and the server. No need to implement it since Play! 2 is already implementing it, and in a reactive fashion. So we've just got to use the dedicated API for that.
- Comet: This is not part of the HTML5 specification, but was the predecessor of SSE for those applications that needed a server push functionality. The same remark was said for WebSocket; everything has been done in the Play! 2 API to enable a developer using Comet easily. No need for a brand new API like it was for the Servlet API. Indeed, a new Servlet API was created back in 2009; it was the third version in order to enable such features.
HTML5 is not the only great support that Play! Framework 2 is providing us. There is also the support of web services. There is a part of the API that is completely dedicated to handle WS calls in a reactive fashion (using the Promise and Iteratee concepts).
By respecting Play! 2's conventions, an application can make excessive usage of external services without suffering extra latency or bad response times for regular requests. This is possible thanks to the asynchronous feature of Play! 2.
Another tool in Play! 2 is the validation of HTML forms on both sides: client and server. Indeed, you can rule the way data is provided to a server at runtime by adding constraints on them. Plenty of constraints are defined in the API but we can also create our own.
More than this runtime validation, a validation can be done at compile time using the power of templates. Indeed, as a form is represented on the server side to match a specific type structure (hey, we're in Java or Scala!), and that the templates will take those forms as parameters to create HTML ones, the compiler will be able to find problems with types.
We can easily create a workflow that deals with validated deep structures, without boilerplates and also without any fear, thanks to the type safety brought both in the templates and in the action.
One of the biggest advantages of this framework is hot reloading! For those used to Java web frameworks, you know how hard and long the path is to go from a line of code to a manual test in a browser.
Most of the frameworks deal with J2EE interfaces that require a specific runtime environment, such as a servlet container or even an application container. These servers need packaging of the code to run it, so developers need to create this package before being able to test it. Or, it can bind an IDE to a running instance to hot swap the code; however, it won't work for changes in interfaces, signatures, and so on.
Play! 2 being out of that world and without those constraints, plus the fact that it has the full control on the environment (as it's a full-stack framework), they took the opportunity to resolve all points by enabling hot swapping of the code, using hot reload of the classpath.
OK, that's not a new feature for Play! 1 developers; however, for others and for Scala ones, it is!
This section is quite similar to the previous one. We already know that Play! Framework 2 is a full stack and is completely integrated for web development. In addition, it has also solved another frequent problem when creating a web application. This problem is the time spent on looking for errors. Are they in the server log, in the application one, or in the console? Or, maybe, nowhere because it misses a configuration file?
The answer to all of these questions is that you don't have to ask them. Everything will be shown in the browser when using it. That's it! You won't have to wonder where are the errors, because they're shining with red lights in front of you.
Moreover, error types span from the server-side code—whatever it is, Java or Scala—to the client code, for both CoffeeScript and LESS CSS files.
And that's why a developer only needs two tools during development: an IDE to write the code (or an editor with syntax highlighting features) and his browser. Actually, there is also the console, but, in development, you'll probably never go to it after you've launched the application (run).