
Play Framework 2.0 Final released - cobrien
http://www.playframework.org/#
======
latch
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...](http://www.playframework.org/documentation/2.0/JavaFunctionalTest)

~~~
dpratt99
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.

~~~
djb_hackernews
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...](https://github.com/lift/lift/tree/master/framework/lift-base/lift-
json/)

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.

------
cmicali
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?

~~~
chrisbaglieri
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.

~~~
eta_carinae
> 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.

~~~
saryant
Not saying you're wrong, but says who? Can you point to evidence of this
consensus?

I'm seriously asking, not trying to challenge you.

~~~
eta_carinae
It's just that most of the curves have remained flat. Look on job boards,
language rankings, github stats, or even the Scala reddit, which is a ghost
town.

Taken in isolation, these numbers don't mean much but when you start putting
all the evidence together, it's hard to make a case that Scala is growing at
all.

------
pvillega
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?

------
mrspeaker
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>

~~~
tomku
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
You can get it directly from scala-lang.org:

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

~~~
tomku
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
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.

------
ghusbands
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...](http://www.infoq.com/news/2011/12/playframework-
typesafestack)

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

~~~
ghusbands
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
Can anyone talk about their experiences of using Play 2.0 and Lift, if they've
used both?

~~~
cgislason
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.

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

------
gren
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
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

------
opensas
and a shiny new play framework site <http://www.playframework.org/>

------
sebcreme
and fucking crazy big doc <https://github.com/playframework/Play20/wiki>

------
wiradikusuma
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>

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

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

