There are several MVC frameworks for developing WEB applications, and perhaps you may be asking yourself why should you learn a new one. The main motivation is to try to use a tool that will make you worry with nothing more than your business rules.
“Play” already comes with many infrastructure decisions taken on by you. For example:
Note that all of this infrastructure alone is useless; the project development team spends several hours assembling such infrastructure project after project. With this part entirely ready, the developers may be mostly concerned with just writing business rules related to the application, which will probably be much more profitable for the company.
In order to provide much more than competitors, Play had to make a bold architectural decision. The specifications governing the development of Java web applications were not designed to provide the features offered by the framework. In order to avoid workarounds, Play decided not to follow the specifications of JavaEE. At first it may seem that you lose much, as it is now strongly coupled to it, but stop and think for a second. How often do you keep switching the implementation? How many times has a project in which you were participating had to change the JPA implementation? Or implementation of the JAX-WS specification? The one that handles the creation and use of Web services.
Based on that, the Play team decided not to give much importance to the specification. Going the other way, they managed to create a framework that offers you several technologies for the different layers of your application and with everything already integrated. These types of frameworks are known in the market as Full Stack and have been proving to be more productive than those of competitors. Examples already well-established are Rails, written in Ruby, and Django, written in Phyton.
Another bad characteristic of web application development in Java is the famous mandatory reload that the application has to suffer when a class is changed. Think about how many times you have been waiting for Tomcat’s hot deploy after any change. And think about when you were with a logged-in user and the same was lost after the change. This is a recurring problem that makes developers lose precious minutes to inactivity. Therefore, many developers develop in debug mode all the time to try to minimize this waiting time. However, what about when a configuration file is changed, for example, some .properties or the persistence.xml of your application using JPA? There is no way for these examples; you have to wait for the redeploy until changes are shown.
As everything in Play is integrated, this problem has also been solved. Any file that you change in your application is automatically reloaded by Play, much like what happens during development using scripting languages like Ruby and Php. Programmers coming from .NET platform are also used to it due to the high level of integration between the platform frameworks and the IDE for development.
One last point I want to discuss in order to convince you to devour this book as if your project depended on it is the power of scalability of Play. Even today, the most common solution to scale an application is to add more servers and then balance the load between them. This is a solution that will eventually have to be taken, but what you mostly want is to delay an increase in design complexity due to this decision. If your application is installed on several different servers, how will it handle data of the session user? This is just one example of added complexity.
Seeking to improve this aspect, Play uses a server called Netty, which was built already prepared for dealing with requests completely asynchronously. And it goes further, since it is of no use for your server to have this support if its APIs do not have the same principle. The core of Play is based on the Scala language, which runs over the JVM and has a strong concern with concurrence and parallelism. Moreover, the Akka project was implemented, which is the main project of the Java world nowadays when speaking about these characteristics. Therefore, everything within the framework happens in a non-blocking way, which greatly increases the scalability of just one instance of your application.
And if you still need to scale the application horizontally, including more servers, Play turns this into a trivial task. It was designed not to maintain any state, being stateless. Without a state, there is no reason to worry about in which server the request will fall. Your load balancing will be used at full capacity.
If the above arguments have sharpened your curiosity, start reading the book now! In the next chapter you will already have a "Hello World" built in a matter of minutes. And enjoy!