Here s my list, of course, with some duplications

• breaks backward compatibility (it s a rewrite from scratch)

• core programmed in scala vs java (got to learn scala to collaborate)

• scala for templates (but work is being done on groovy templates as a module, to ease migration), so you have to specify the type of each parameter

• sbt console instead of python scripts

• sbt for solving dependencies instead of built-in solution (play dependencies command)

• modules availability, it will obviously take some time to migrate them all...

• for java, it favours ebean in place of hibernate (but you ll be able to use hibernate)

• for scala, comes with anorm (but you l be able to use other libraries)

• more modular, easier to pick other components

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

• better performance

• typesafe support, it s part of typesafe stack

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

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

• different controller API (more verbose, IMHO) you can compare a simple play 1.x crud controller with a similar play 2.0 one

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

• hot recompiling is slower (it s still on beta, let s hope they solve it)

• scala IDE support is not as mature as java s (but it s evolving nicely)

• async support delegated to akka

• better prepared for different kinds of datasources, like nosql dbs

For more info have a look at play 2.0 page (spanish translation available here) and the RC1 documentation

Anyway, I think the main difference is that play 1.x tried to build it s own stack while escaping away from j2ee, now they are part of a new and alternative stack, based on scala, akka, sbt and with the support of a company like typesafe...

I find the following point important. Some are pros some are contras. You must see by yourselves what version you prefer.

• The core is written in Scala, so if you aren t a Scala developer you can t fix easily a bug by yourself. This was a strength of play 1.2. Furthermore if the documentation is not very good you are lost. In play 1.2 you can simply look into the code. With eclipse you had an IDE to easily search for reference. I m unsure if it exists a comparable IDE for Scala. I heard that eclipse an intellij works fine with it, but haven t own experiences.

• The components are more loosely coupled in 2.0. In play 2.0 you can choose easily your preferred template engine or persistence layer. In 1.2 it was more difficult to choose something except JPA for persistance.

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

• The dependencies to other frameworks are higher. For example they now need Scala and Akka. Both are nice, but complex. So you can run into big trouble if there are errors in one of these frameworks. In play 1.2 I only see such risk for Hibernate.

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

• Changing Python to SBT implies that you need much more memory on your development machine. I mean that Scala compiler needs at least 512 MB RAM. That can be a problem on a continuous-build server.

Of course there are a lot of small details as mentioned by Codemwnci.

Your list is a very good start. My list looks similar with a few extras.

• Templates have moved from Groovy to Scala.
• Scala becomes a first class citizen, rather than an optional plugin
• Stronger focus on type-safety, especially in templates
• Python to SBT
• Hibernate to Ebean
• Akka to supplement the asynchronous features in Play 1.x, rather than Akka as a module
• Anorm available in the core (rather than scala plugin)
• Performance improvements in production due to less dynamic elements and more compiled
• Integrated into the TypeSafe stack

There are duplications between our lists as you would expect. Also caveated that this list is as of November 2011, while play 2 is still in Beta.

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

In-Browser-Reporting: Play 2 reports on errors in Javascript ( Using google s closure compiler) and CSS files in the browser as well and not only Java/Scala files. This is really cool.

Deployment as WAR: Play 2 doesn t still officially support deployment or export as a WAR. A plug-in exists that is supposed to provide such support, but is in beta with some known issues. Complete support of all Play 2 features is not really possible without Servlets 3.1 containers, which will take at least half a year, probably more.

Plug-ins: For now, there are still many more for play 1, if you are depending on some plug in, make sure it exists for play 2 as well.

IDE support: IntelliJ 12 should come with built-in support for play 2. You can already get the EAP ( I ran out of allowed hyper links so you will have to google).

Subjective opinion: I feel as if Play 2 sacrificed some simplicity for support for more advanced features and more complete type-safety. I m not saying Play 2 is hard or not intuitive, just less so than Play 1.

Play 1 was a web framework for web developers by web developers. Play 2 is a forward looking web framework for web developers by web developers.

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

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

Summarizing from this article:

• Asset pipeline for direct use of Google Closure Compiler, CoffeScript and LESS
• Everything is compiled, even the routes file
• Low memory footprint for a running app
• Async/reactive programming with Iteratee/Enumerator
• As you mentioned, Scala, Akka, ...