English 中文(简体)
What are the major differences between Play Framework 1.0 and 2.0?
原标题:

With the recent release of Play Framework 2.0, I would like to know if anyone could summarize ,from a high level standpoint, the major differences between Play Framework 1 & 2.

I already compiled a few (play 1.0 -> play 2.0):

  • Template engine: Groovy Pages -> Scala Templates
  • Persistance: Hibernate -> Ebean
  • Language support: Java -> Scala, Java
  • Dynamic compilation: byte code injection -> dynamic compilation via SBT
  • Build system: n/a -> SBT
  • Extensibility: Modules, Plugins -> SubProjects, Plugins, SBT plugin

What else ? Akka?

最佳回答

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, ...




相关问题
Manage dependencies in a Play Framework app

I m trying to figure out the proper tools for managing dependencies between JARs. I have a Play Framework app, which imports a JAR (based on another project I m writing). This JAR imports other JARs, ...

Deploy Play! application as executable jar

Is it possible to bundle Play! web application to executable jar instead of war? Could it just be run on localhost at some port just like when using "play run" command? (without the need of installing ...

JPA: Store fileAttachment into the database

I would like to know if there is any way I can store a fileAttachment directly into the database with JPA. I have an attribute: public fileAttachement logo; I have tried to change it to: @Lob ...

Java Web Development and Automatic Feedback

I ve been having a (ironic) play around with the Play Framework and have been impressed thus far. I was just curious as to what other Java frameworks are out there that have a similar feature to Play ...

Java web frameworks

I was looking around to see if there is an equivalent to django/RoR in java. I found: Play Framework Grails Does anyone have ever tried those frameworks, or do you know any other? Are they faster ...

热门标签