6 ms·

Play Framework 2.0 Final released

206 points by cobrien 15y ago

mrspeaker 15y ago
It's also now part of the Typesafe stack - here's the release announcement from the typesafe blog: http://blog.typesafe.com/introducing-play-20 http://blog.typesafe.com/introducing-play-20
- tomku 15y ago
  Not much of a fan of the new Typesafe Stack. It doesn't seem to install the scala, play and akka command-line tools like the old versions did. Is there a way to get a straight Scala REPL, or does everything have to go through giter8 and sbt now?
  - saryant 15y ago
    You can get it directly from scala-lang.org: http://www.scala-lang.org/downloads http://www.scala-lang.org/downloads
    - tomku 15y ago
      I was aware of that, but it seems silly to have a separate installation of Scala just for the REPL when the stack includes most of the important stuff already. I guess that I'd be better off just using the individual components instead, for now. With the new version it feels like they've switched from being a fairly plain "distribution" of Scala/Akka to more of an opinionated tool set based on giter8 and sbt. That's a pretty big jump, and I'm hoping that the lack of command-line support tools is something that's fixable once things are settled a bit.
      - eeperson 15y ago
        Then are you just asking how to get a Scala REPL using sbt? If so, you can get one by entering the command 'sbt console' in a project directory. This will give you a scala console with the added bonus that all of the files in your project will be loaded as part of the REPL's classpath.
  - SkyMarshal 15y ago
    The new typesafe-stack deb package also wants to install all of OpenJDK as well, even if you've got Oracle JDK already installed and on the path.
opensas 15y ago
and a shiny new play framework site http://www.playframework.org/ http://www.playframework.org/
latch 15y ago
When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and call instance methods. Static members in static languages make testing a real pain. Second, JSON felt like a 2nd-class citizen. Dealing with JSON in either the request or the response felt barbaric. I don't see that they've improved things. Auto binding from a JSON request to an object should exist without having to write a bunch of custom JSON serializers...doubly so for outputting json. [1] http://www.playframework.org/documentation/2.0/JavaFunctionalTest http://www.playframework.org/documentation/2.0/JavaFunctiona...
- dpratt99 15y ago
  I can't agree more - I've been doing a non-trivial bit of scala work in the past six months, and the part that seems the most lacking to me is JSON support. Every scala JSON library I've used (spray-json, sbjson, lift-json and the like) requires you to define a concrete serializer class for every single type you would like to move across the wire. I really miss the ease of use of reflection-based parsers like Jackson. I've alleviated a bit of this by writing a generic serializer that uses Jackson under the hood, but that requires every class to use a java bean pattern, and not the more elegant scala case class (or frankly plain old scala object) patterns. There's a project called Jerkson that is attempting to fix this, but I'd like to see all the major scala frameworks just settle on something good and simple and go from there.
  - domlebo70 15y ago
    Jerkson works really well. Can convert JSON into case-classes really nicely and handles snake-types.
  - djb_hackernews 15y ago
    You might want to check out lift-json again. It can easily serialize and deserialize case classes. https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ https://github.com/lift/lift/tree/master/framework/lift-base... Also, Play 2.0 includes Jerkson, so whatever Jerkson can do, Play 2.0 can do. They just happened to add some helper utilities that made it very similar to lift-json. So I think the community is settling on something good and simple.
sebcreme 15y ago
and fucking crazy big doc https://github.com/playframework/Play20/wiki https://github.com/playframework/Play20/wiki
wiradikusuma 15y ago
personal wish: this, with CRUD scaffolding and GAE support, will make Play my dream framework. edit: this news announcement from Typesafe explains a bit more about Play 2.0: http://blog.typesafe.com/introducing-play-20 http://blog.typesafe.com/introducing-play-20
gren 15y ago
give Play 2.0 a try guys, it's a fresh new framework, more robust than ever, and with awesome concept for handling Input/Output.
- carterschonwald 15y ago
  That way of handling io is indeed snazzy, and a port of ideas from some Haskell libs, but it's worth pointing out that on the Haskell side there's been a bit of innovation in allowing more direct style Apis for iteratee libraries
cmicali 15y ago
I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?
- soc88 15y ago
  Why would it be bad?
- oacgnol 15y ago
  I think that's the direction that they're already heading. While Java will be supported by nature, I think Scala is a better fit for the growth the framework itself.
- chrisbaglieri 15y ago
  I partially disagree, especially with backing from Typesafe. The "engine" benefits from Scala, as a highly concurrent and transactional heavy system. The choice of language for building MVC applications & services on that engine is left up to the developer. The 2.0 mindset, and you see this in everything is very much a best tool for the job balanced with flexibility and choice. It's going to take a little while for a language like Scala (or any JVM based language) to fully penetrate the market. A lot of Java developers are not there yet, and by a lot, I mean most, who are we kidding. I see more shops embracing the JVM as their "stack" and the right language for the job mindset on top of that foundation. It's flexible, conservative, and forward thinking at the same time. Play fits nicely into that space and is something that the core team appears to be mindful of. In fact, if they're smart about it, Play could end up being a bridge for Java developers interested in making the transition to Scala, at a pace that makes sense for them.
  - cmicali 15y ago
    I totally agree that the best case scenario is Play 2 lowering the learning curve and providing a bridge for java devs trying to get up to speed with Scala. I just think it will be hard to justify play2's use in java-heavy organizations if Java support is a second citizen to Scala. I loved Play 1.2.x, I think it is the only framework that really provides a way forward for modern java web dev, and I strongly hope Play 2 keeps things moving.
kanwisher 15y ago
Their beta was incredibly buggy, riddled with compilation performance performance, slow load times, was really not a fun experience. I've heard they finally got development load times in check. I hope they get their deployment process a bit better then creating a zip file and having to run nohup on their start script.
- benmccann 15y ago
  It got to be pretty stable at RC3. I agree the beta was poor in a number of areas, but I've been consistently using the latest from GitHub for months now and would recommend you give it another go with this final release. They deployment story is the same, though I've filed some feature requests around this and I imagine this will be improved by the community as more people start using v2.
lfischer 15y ago
I find that testing has improved quite a bit since actions now return a Result object that you can inspect in your tests. It is true that you cannot inject a mock data repository, for example, but Controllers are meant to be simple HTTP response generators and you might want to make them call some domain object to perform anything complicated. You can then unit test you domain object to your heart’s content.
ghusbands 15y ago
For anyone interested in its claim of being reactive, as I was, the Play framework does not appear to support reactive programming [1]. From their samples and documentation, it looks like an event-driven server without any reactive aspects. I'm fairly sure they're mistakenly calling typical event-driven programming "reactive". This is backed up by the statements of Typesafe's CEO on the subject in an interview [2]. [1] http://en.wikipedia.org/wiki/Reactive_programming http://en.wikipedia.org/wiki/Reactive_programming [2] http://www.infoq.com/news/2011/12/playframework-typesafestack http://www.infoq.com/news/2011/12/playframework-typesafestac...
- eweise 15y ago
  Or just read the play documentation https://github.com/playframework/Play20/wiki/Iteratees https://github.com/playframework/Play20/wiki/Iteratees
  - ghusbands 15y ago
    Which indeed is talking about stream processing. Play's stream processing uses iteratee IO to correct control inversions often suffered by networking libraries. However, Play does not offer automatic facilities for having variables (and interface) update when other variables change, as described in the Wikipedia article. For examples of reactive programming, see Knockout, batman.js and Ember.js (all primarily client-side).
yan 15y ago
Can anyone talk about their experiences of using Play 2.0 and Lift, if they've used both?
- cgislason 15y ago
  Last summer I evaluated Lift vs Play 1.x and was leaning heavily toward Play. I wrote some toy apps in each. We chose Lift only because it turned out that Play was incompatible with our Maven setup. (I have heard it has improved in 2.0 but I have not looked into it myself.) I found Play to be fairly intuitive and it matched my mental model pretty well. It was lightweight compared to Lift and the other Java frameworks I looked at. Play 2.0 seems to have made improvements in the areas I found weak in Play 1.x. i.e. modularity, Scala support (specifically for continuations) Lift is a fairly heavy framework, but you can ignore big parts of it if you need to. In Lift it took me a while to grasp the HTML transforming concept, partly because the documentation seemed to out of date. It felt both cumbersome and elegant at the same time. Sadly I didn't get very far on the project so I have no idea how Lift has changed/improved since then. Today I would choose Play in a heartbeat if it fit the parameters of my project.
lhnn 15y ago
Off topic a bit, but it's a good place to complain: Typesafe, Please don't be a tool. Take your "whitepapers" out from behind an email registration page.
pvillega 15y ago
Sorry for being "rantish", but most of the "negative" comments I'm reading around here are from people who didn't spend a single second reading the manual. Yes, I'm not partial, I'm invested on Play, but I am because it has a wonderful documentation that makes life really easy (that plus StackOverflow). Most of the complains in here come from people with almost no experience in it. No, a small side project of 6 hours is not "experience". You just toyed around. You can't know about the real issues or benefits related to a framework. Please, I know this is "the internet", but in a site like Hacker News, couldn't you try to talk only about things you know?
artist777 15y ago
Cheap viagra http://viagrapedia.com http://viagrapedia.com Thanks for info

206 points by cobrien 15y ago

It's also now part of the Typesafe stack - here's the release announcement from the typesafe blog: http://blog.typesafe.com/introducing-play-20 http://blog.typesafe.com/introducing-play-20

tomku 15y ago
Not much of a fan of the new Typesafe Stack. It doesn't seem to install the scala, play and akka command-line tools like the old versions did. Is there a way to get a straight Scala REPL, or does everything have to go through giter8 and sbt now?
- saryant 15y ago
  You can get it directly from scala-lang.org: http://www.scala-lang.org/downloads http://www.scala-lang.org/downloads
  - tomku 15y ago
    I was aware of that, but it seems silly to have a separate installation of Scala just for the REPL when the stack includes most of the important stuff already. I guess that I'd be better off just using the individual components instead, for now. With the new version it feels like they've switched from being a fairly plain "distribution" of Scala/Akka to more of an opinionated tool set based on giter8 and sbt. That's a pretty big jump, and I'm hoping that the lack of command-line support tools is something that's fixable once things are settled a bit.
    - eeperson 15y ago
      Then are you just asking how to get a Scala REPL using sbt? If so, you can get one by entering the command 'sbt console' in a project directory. This will give you a scala console with the added bonus that all of the files in your project will be loaded as part of the REPL's classpath.
- SkyMarshal 15y ago
  The new typesafe-stack deb package also wants to install all of OpenJDK as well, even if you've got Oracle JDK already installed and on the path.

opensas 15y ago

and a shiny new play framework site http://www.playframework.org/ http://www.playframework.org/

latch 15y ago

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and call instance methods. Static members in static languages make testing a real pain. Second, JSON felt like a 2nd-class citizen. Dealing with JSON in either the request or the response felt barbaric. I don't see that they've improved things. Auto binding from a JSON request to an object should exist without having to write a bunch of custom JSON serializers...doubly so for outputting json. [1] http://www.playframework.org/documentation/2.0/JavaFunctionalTest http://www.playframework.org/documentation/2.0/JavaFunctiona...

dpratt99 15y ago
I can't agree more - I've been doing a non-trivial bit of scala work in the past six months, and the part that seems the most lacking to me is JSON support. Every scala JSON library I've used (spray-json, sbjson, lift-json and the like) requires you to define a concrete serializer class for every single type you would like to move across the wire. I really miss the ease of use of reflection-based parsers like Jackson. I've alleviated a bit of this by writing a generic serializer that uses Jackson under the hood, but that requires every class to use a java bean pattern, and not the more elegant scala case class (or frankly plain old scala object) patterns. There's a project called Jerkson that is attempting to fix this, but I'd like to see all the major scala frameworks just settle on something good and simple and go from there.
- domlebo70 15y ago
  Jerkson works really well. Can convert JSON into case-classes really nicely and handles snake-types.
- djb_hackernews 15y ago
  You might want to check out lift-json again. It can easily serialize and deserialize case classes. https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ https://github.com/lift/lift/tree/master/framework/lift-base... Also, Play 2.0 includes Jerkson, so whatever Jerkson can do, Play 2.0 can do. They just happened to add some helper utilities that made it very similar to lift-json. So I think the community is settling on something good and simple.

sebcreme 15y ago

and fucking crazy big doc https://github.com/playframework/Play20/wiki https://github.com/playframework/Play20/wiki

wiradikusuma 15y ago

personal wish: this, with CRUD scaffolding and GAE support, will make Play my dream framework. edit: this news announcement from Typesafe explains a bit more about Play 2.0: http://blog.typesafe.com/introducing-play-20 http://blog.typesafe.com/introducing-play-20

gren 15y ago

give Play 2.0 a try guys, it's a fresh new framework, more robust than ever, and with awesome concept for handling Input/Output.

carterschonwald 15y ago
That way of handling io is indeed snazzy, and a port of ideas from some Haskell libs, but it's worth pointing out that on the Haskell side there's been a bit of innovation in allowing more direct style Apis for iteratee libraries

cmicali 15y ago

I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?

soc88 15y ago
Why would it be bad?
oacgnol 15y ago
I think that's the direction that they're already heading. While Java will be supported by nature, I think Scala is a better fit for the growth the framework itself.
chrisbaglieri 15y ago
I partially disagree, especially with backing from Typesafe. The "engine" benefits from Scala, as a highly concurrent and transactional heavy system. The choice of language for building MVC applications & services on that engine is left up to the developer. The 2.0 mindset, and you see this in everything is very much a best tool for the job balanced with flexibility and choice. It's going to take a little while for a language like Scala (or any JVM based language) to fully penetrate the market. A lot of Java developers are not there yet, and by a lot, I mean most, who are we kidding. I see more shops embracing the JVM as their "stack" and the right language for the job mindset on top of that foundation. It's flexible, conservative, and forward thinking at the same time. Play fits nicely into that space and is something that the core team appears to be mindful of. In fact, if they're smart about it, Play could end up being a bridge for Java developers interested in making the transition to Scala, at a pace that makes sense for them.
- cmicali 15y ago
  I totally agree that the best case scenario is Play 2 lowering the learning curve and providing a bridge for java devs trying to get up to speed with Scala. I just think it will be hard to justify play2's use in java-heavy organizations if Java support is a second citizen to Scala. I loved Play 1.2.x, I think it is the only framework that really provides a way forward for modern java web dev, and I strongly hope Play 2 keeps things moving.

kanwisher 15y ago

Their beta was incredibly buggy, riddled with compilation performance performance, slow load times, was really not a fun experience. I've heard they finally got development load times in check. I hope they get their deployment process a bit better then creating a zip file and having to run nohup on their start script.

benmccann 15y ago
It got to be pretty stable at RC3. I agree the beta was poor in a number of areas, but I've been consistently using the latest from GitHub for months now and would recommend you give it another go with this final release. They deployment story is the same, though I've filed some feature requests around this and I imagine this will be improved by the community as more people start using v2.

lfischer 15y ago

I find that testing has improved quite a bit since actions now return a Result object that you can inspect in your tests. It is true that you cannot inject a mock data repository, for example, but Controllers are meant to be simple HTTP response generators and you might want to make them call some domain object to perform anything complicated. You can then unit test you domain object to your heart’s content.

ghusbands 15y ago

For anyone interested in its claim of being reactive, as I was, the Play framework does not appear to support reactive programming [1]. From their samples and documentation, it looks like an event-driven server without any reactive aspects. I'm fairly sure they're mistakenly calling typical event-driven programming "reactive". This is backed up by the statements of Typesafe's CEO on the subject in an interview [2]. [1] http://en.wikipedia.org/wiki/Reactive_programming http://en.wikipedia.org/wiki/Reactive_programming [2] http://www.infoq.com/news/2011/12/playframework-typesafestack http://www.infoq.com/news/2011/12/playframework-typesafestac...

eweise 15y ago
Or just read the play documentation https://github.com/playframework/Play20/wiki/Iteratees https://github.com/playframework/Play20/wiki/Iteratees
- ghusbands 15y ago
  Which indeed is talking about stream processing. Play's stream processing uses iteratee IO to correct control inversions often suffered by networking libraries. However, Play does not offer automatic facilities for having variables (and interface) update when other variables change, as described in the Wikipedia article. For examples of reactive programming, see Knockout, batman.js and Ember.js (all primarily client-side).

yan 15y ago

Can anyone talk about their experiences of using Play 2.0 and Lift, if they've used both?

cgislason 15y ago
Last summer I evaluated Lift vs Play 1.x and was leaning heavily toward Play. I wrote some toy apps in each. We chose Lift only because it turned out that Play was incompatible with our Maven setup. (I have heard it has improved in 2.0 but I have not looked into it myself.) I found Play to be fairly intuitive and it matched my mental model pretty well. It was lightweight compared to Lift and the other Java frameworks I looked at. Play 2.0 seems to have made improvements in the areas I found weak in Play 1.x. i.e. modularity, Scala support (specifically for continuations) Lift is a fairly heavy framework, but you can ignore big parts of it if you need to. In Lift it took me a while to grasp the HTML transforming concept, partly because the documentation seemed to out of date. It felt both cumbersome and elegant at the same time. Sadly I didn't get very far on the project so I have no idea how Lift has changed/improved since then. Today I would choose Play in a heartbeat if it fit the parameters of my project.

lhnn 15y ago

Off topic a bit, but it's a good place to complain: Typesafe, Please don't be a tool. Take your "whitepapers" out from behind an email registration page.

pvillega 15y ago

Sorry for being "rantish", but most of the "negative" comments I'm reading around here are from people who didn't spend a single second reading the manual. Yes, I'm not partial, I'm invested on Play, but I am because it has a wonderful documentation that makes life really easy (that plus StackOverflow). Most of the complains in here come from people with almost no experience in it. No, a small side project of 6 hours is not "experience". You just toyed around. You can't know about the real issues or benefits related to a framework. Please, I know this is "the internet", but in a site like Hacker News, couldn't you try to talk only about things you know?

artist777 15y ago

Cheap viagra http://viagrapedia.com http://viagrapedia.com Thanks for info