As said earlier, this version has been built using Scala as the core language, whereas Play! 1 uses the Java language and provides support for Scala.

But that's not all! One of the biggest changes of Play! 2 is its console. Indeed, Play! 1's console was a custom one, using Python to reduce the memory footprint and the need to start a JVM all the time. This has been revoked in Play! 2 because of Simple Build Tool (SBT). This build tool has the disadvantage of starting a JVM but, you'll start it only once! This is because the SBT console is a "real" console as it provides commands, tasks, and so on.

Furthermore, SBT is easily extensible and that's exactly what has been done for Play! to enable or customize specific actions for it (such as run).

In this new version, where Scala was chosen as the core language, the Play! Framework 2 team has also chosen Scala for server-side rendering. This means that they have built a brand new templating system that uses Scala rather than Groovy in the first version.

However, they didn't use Scala as just an empty language to generate HTML (for instance); rather, they integrated the generated page (or data) with Scala. And how did they accomplish that? By producing a regular Scala file that will be compiled. Hence, writing a template is type safe; they can be composed easily and have a steep learning curve.

A web application will always come with assets that are meant to be served as is by the server. However, those assets will be optimized by Play! for us, by precompiling them or by using an HTTP mechanism to reduce the server's work to serve them. One example is to use the ETag header to avoid resending the same thing again and again.

That was for performance, but Play! has been created by web developers, and only they know what other problems they had with assets such as JavaScript and CSS. That's why a new feature that comes for free with Play! 2 is the ability to write compiled assets such as a CoffeeScript file for JavaScript or LESS CSS for CSS, without any configuration or additional tasks when starting to work.

The integration of these languages has been done deeply, so their compilation errors are shown to the developers like it is for a classical "server" code, which is on the browser!