Asset pipeline to use CoffeeScript and LESS directly.
–
Marius SoutierNov 19 '11 at 16:23

3

A very important change: being part of TypeSafe as "official" Scala stack. This will make adoption 'safer' for companies (support, some are paranoid on it) and promote adoption versus other Scala frameworks like Lift.
–
Pere VillegaNov 20 '11 at 20:08

ok, I'll let this question go for a few weeks before picking a winner. You all provided valid points.
–
Olivier RefaloNov 22 '11 at 16:44

1

I just want to mention that there are many of us who miss Play 1. Of course, it still exists but no longer sees active development. It was a simple, opinionated, and very effective Java framework for web development. Play 2 is not simple, not nearly as opinionated, and Java is a second-class citizen. I used to recommend Play 1 to other developers, but I don't recommend Play 2.
–
pents90Feb 25 at 19:57

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.

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.