Play Framework 2.0 Final released

http://www.playframework.org/#

by cobrien • 14 years ago

206 59 14 years ago

mrspeaker• 14 years 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

tomku2• 14 years 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?

saryant2• 14 years ago

You can get it directly from scala-lang.org:

http://www.scala-lang.org/downloads

SkyMarshal• 14 years 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• 14 years ago

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

latch4• 14 years 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/JavaFunctiona...

dpratt99• 14 years 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• 14 years ago

Jerkson works really well. Can convert JSON into case-classes really nicely and handles snake-types.

djb_hackernews• 14 years 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...

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.

johnx123-up• 14 years ago

Probably Xitrum? https://github.com/ngocdaothanh/xitrum

eloisant• 14 years ago

I disagree on the fact that JSON is a second-class citizen. A lot of effort went into good support of JSON. But obviously, Scala and Java being statically typed languages, you can't expect to use JSON in those languages like you use them in Javascript.

The reason why everyone encourage you to do so is because typeclass serialization is much more robust that introspection. With introspection you may have runtime exceptions, but with typeclass serialization you know at compile time when something is wrong.

Also, Jerkson is included in Play 2 (that's what we use as base for the Json lib) so you can use it directly if you want introspection.

But if you choose typeclass serialization, you can still define serializers easily, in one line, without losing the type-safety: https://github.com/playframework/Play20/blob/master/framewor...

philipDS• 14 years ago

I agree about the testing. It is also really annoying that you can't run a test as a "single, isolated test". I read a few articles on Play 2.0 and Scala, but haven't come across any additions on testing. Without decent testing integrated, this framework has no real production use. I agree that it all looks nice and shiny though.

ekoontz• 14 years ago

Some interesting criticism of Play here - seems similar to what's been said about the lack of unit tests.

http://whilefalse.blogspot.com/2012/03/why-im-moving-away-fr...

pk115• 14 years ago

in play 2.0 (using computer-database java sample app):

  $ play
  [computer-database] $ test-only ModelTest

  or from the command line:
  $ play "test-only ModelTest"

mercurial• 14 years ago

I don't understand why you would want static methods everywhere in this age of dependency injection everywhere.

rufugee2• 14 years ago

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

latch4• 14 years ago

This is the first controller I opened from their samples[1] :

  public class Forums extends Application {
    public static void index() {
      List forums = Forum.findAll();
      long topicsCount = Topic.count();
      long postsCount = Post.count();
      render(forums, topicsCount, postsCount);
    }
  ...
  }

You can't mock out Forum, Topic or Post. You can't inject some type of "FormRepository" or whatever pattern you want to gain some type of control. In Ruby, or most dynamic languages, this wouldn't be a problem, since a class method can (and should) be mocked. Even if a static language allows for that sort of trickery (for example, there are a couple ways to test the above in C#), it's the wrong approach. Dependencies should be injected and thus controlled. I guess you could inject using static setters, but that's just a bad workaround to what, in my opinion, is a fundamental misunderstanding of how to write testable code.

[1] https://github.com/playframework/play/blob/master/samples-an...

eweise2• 14 years ago

Can't you mock out the calls with something like http://code.google.com/p/powermock/? Or introduce an intermediate object? Or use Spring? Or test using groovy which i think you can redefine methods.

riffraff• 14 years ago

"resort to another framework to reach a goal that I expect to be easy"

is a perfectly good reason to state something is a "serious annoyance".

sebcreme• 14 years ago

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

wiradikusuma2• 14 years 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

gren• 14 years 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• 14 years 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

cmicali2• 14 years 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?

soc882• 14 years ago

Why would it be bad?

oacgnol• 14 years 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• 14 years 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.

cmicali2• 14 years 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.

eta_carinae2• 14 years ago

> It's going to take a little while for a language like Scala (or any JVM based language) to fully penetrate the market.

By a wide margin, the overall consensus in the JVM community seems to be that Scala will probably never be more popular than it is today, which means, it will never become mainstream. Hopefully, one of Ceylon or Kotlin will succeed where Scala failed.

With that in mind, Play betting on Scala is quite a risky direction indeed.

benmccann2• 14 years ago

There's at least as many Java developers in the Play community. The devs would certainly hear about it if any feature were supported only in Scala and I imagine you'd see community members submitting patches, etc. to remedy the situation.

pk115• 14 years ago

No need to be worried, the Java API is here to stay. We love Java (as well as Scala).

kanwisher• 14 years 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.

benmccann2• 14 years 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• 14 years 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.

ghusbands2• 14 years 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 [2] http://www.infoq.com/news/2011/12/playframework-typesafestac...

eweise2• 14 years ago

Or just read the play documentation https://github.com/playframework/Play20/wiki/Iteratees

ghusbands2• 14 years 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• 14 years ago

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

cgislason• 14 years 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• 14 years 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• 14 years 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?

Play Framework 2.0 Final released

Related Stories