What are the main differences between Play Framework 1.0 and 2.0?

Question

With the recent release of Play Framework 2.0, I would like to know if anyone can maximize the general differences between Play Framework 1 and 2.

I already compiled a few (play 1.0 → play 2.0):

• Template Engine: Groovy Pages → Scala Templates
• Resilience: Sleep → Ebean
• Language Support: Java -> Scala, Java
• Dynamic compilation: pasting byte code -> dynamic compilation via SBT
• Build system: n / a → SBT
• Extensibility: modules, plugins → Subprojects, plugins, SBT plugin

What else? Akka?

Answer 1

Here is my list, of course, with some duplication

• violates backward compatibility (corresponded from scratch)

• The kernel is programmed in scala vs java (to learn how to work with scala)

• scala for templates (but work is done on groovy templates as a module to facilitate porting), so you need to specify the type of each parameter

• sbt console instead of python scripts

• sbt to solve dependencies instead of the built-in solution (replay dependency command)

• obviously, it will take some time to transfer them all ...

• for java, it prefers ebean instead of sleep mode (but you can use sleep mode)

• for scala, comes with an anom (but you can use other libraries)

• more modular, easier to select other components

• more type safety - views and even routes are checked at compile time

• higher performance

• type support, it is part of type types

• less magic, not so much generating bytecode and similar stuff

• more standard, (game projects are just standard sbt projects)

• API of another controller (more detailed, IMHO) you can compare a simple 1.x crud controller with a similar player 2.0 one

• scala is a first class citizen, but java is supported equally (has its own API for each of them)

• hot recompilation is slower (it is still in beta, let it be hoped that they will resolve it)

• scala IDE support is not as mature as java (but it is developing beautifully)

• async support delegated by akka

• better prepared for various types of data sources, for example nosql dbs

For more information see the play 2.0 page (Spanish translation available here ) and the RC1 Documentation

In any case, I believe that the main difference is that the 1.x game tried to create its own stack when it left j2ee, now they are part of a new and alternative stack based on scala, akka, sbt and with the support of such a company like typesafe ...

Answer 2

I consider the following important. Some of them are professionals. You must make sure which version you prefer.

• The kernel is written in Scala, so if you are not a Scala developer, you cannot easily fix the error yourself. This was the forte of game 1.2. Also, if the documentation is not very good, you are lost. In game 1.2, you can just take a look at the code. With eclipse, you had an IDE to easily search for a link. I'm not sure if there is a comparable IDE for Scala. I heard that the eclipse intellij works great with it, but does not have its own experience.

• Components are more loosely coupled in 2.0. In game 2.0, you can easily select your preferred template or save level. In 1.2 it was harder to choose anything other than JPA for resilience.

• Scala is now a first-class citizen, so you have free choice if you want to write your application in Scala or Java.

• Dependencies on other frameworks above. For example, now they need Scala and Akka. Both are good but complex. Thus, you may run into big problems if one of these frames contains errors. In game 1.2, I see only such a risk for Hibernate.

• Everything is now type safe and can be checked by the compiler.

• Changing Python to SBT means you need a lot more memory on your development machine. I mean, the Scala compiler needs at least 512 MB of RAM. This may be a problem on the continuous build server.

Of course, there are many small details that Codemwnci mentioned.

Answer 3

Your list is a very good start. My list is like a few additions.

• Templates have moved from Groovy to Scala.
• Scala becomes a first-class citizen, not an optional plugin
• Greater emphasis on type safety, especially in templates
• Python for SBT
• Hibernate to ebean
• Akka complements asynchronous functions in Play 1.x, not Akka as a module
• Anonymous available in the kernel (not the scala plugin)
• Improved production performance due to smaller dynamic elements and more compiled
• Integrated on TypeSafe stack

There are duplicates between our listings, as you would expect. It was also noted that this list refers to November 2011, while game 2 is still in beta.

Answer 4

There are some very good answers here, I just wanted to add a few small points and provide details that became more clear with time.

In-Browser-Reporting: Listen to 2 bug reports in Javascript (using the google close compiler) and CSS files in the browser, as well as not only Java / Scala files. It's really cool.

Deployment as WAR: Play 2 does not officially support deployment or export as a WAR. There is a plugin that should provide such support, but is in beta with some known issues. Full support for all the features of Play 2 is actually impossible without Servlets 3.1 containers, which take at least six months, possibly more.

Plug-ins: There is still much more for game 1, if you are depending on some plug-ins, make sure it exists for game 2.

IDE support: IntelliJ 12 should have built-in support for playback 2. You can already get EAP (I have run out of valid hyperlinks, so you have to go to Google). p>

Subjective opinion: It seems to me that Play 2 sacrificed some simplicity to support more advanced features and more complete type safety. I'm not saying that Play 2 is tough or not intuitive, but less than Play 1.

Play 1 was a web map for web developers web developers. Play 2 is a promising web platform for web developers web developers.

So to speak, there was a slight shift in focus, ease of use is no longer the main goal, but one of the two main goals. This, of course, is only my opinion, and I know very little.

Answer 5

You can find another related post in the following blog post: http://blog.awfbeat.com/post/22314115684/impressions-of-play-framework-1-2-4-vs-2-0

Answer 6

To summarize from this article :

• Asset console for direct use of the Google Closure compiler, CoffeScript and LESS
• Everything compiled, even the routes file
• Low memory for running application
• Asynchronous / reactive programming with Iteratee / Enumerator
• As you mentioned, Scala, Akka, ...