

What’s new in Play 2.2 - proxyswapi
http://www.playframework.com/documentation/2.2.0/Highlights22

======
saryant
We're using Play pretty heavily at our startup though not for our customer-
facing frontend, that's still in Rails.

What we love about Play:

* Async everything, especially the web service library

* JSON macros

* Scala-based templates

* Integration with Akka

* Support for server-sent events (we use this for cluster monitoring)

What we wish was better:

* JSON deserialization performance isn't as good as raw Jackson yet. (Our PR regarding this is actually in 2.2, should be better now)

* Documentation could be much better, we still have to resort to the API to figure out a lot of stuff

I've been using Play ever since the 2.0-RC days and it's definitely made some
huge gains since then. We use Akka very heavily, especially its clustering,
and Play works well in conjunction with that though there are still some
gotchas lurking about.

Our backend is one big Akka cluster right now. We've had a few hiccups but
overall it's been a hugely enjoyable experience.

~~~
stingraycharles
What I never understood is why they embrace rendering templates at the server.
Is it simply a matter of "because we can and it's nice for the people that
want to use it", or is there a real real reason why pushing raw HTML via AJAX
request is better?

I always thought the status quo in the web development world was to use a
framework like Backbone.JS to communicate with your backend and use a client-
side template engine to render the templates.

~~~
nostromo
We push HTML through AJAX to keep all of our templating centralized and
consistent.

For a while we used templates for the container page, and then backbone and js
templating for certain elements on the page. It can become the 2013 equivalent
of spaghetti code if you're not careful.

Now, with HTML via AJAX, you have a clear separation of concerns. For example:
the designer doesn't need a dev to make an HTML change, and the dev knows that
there will be one place that controls how pages are rendered.

------
russ519
For those that have some experience using Play with both Java and Scala, which
Play variant do you enjoy working with the most? It sounds like there are some
API difference between the Java and Scala versions and I'm curious whether
those differences are a factor in deciding whether to go Java or Scala with
Play. I'm a long time Java developer, envious of Ruby, interested in Scala for
its potential in being a hybrid of the two.

~~~
yareally
With Play 2.0 in Java, there's more verbosity (though nothing like any J2EE
framework) in using Java and lack of syntactical sugar features as well as
functional programming features (which are widely used in parts like JSON for
Play). Also, you don't get the benefits of such things as optional parameters
in Java.

Don't get me wrong, the Java version of it is going to be better than any
other Java web framework you ever encountered most likely (especially if
everything else one tried was based in part on J2EE/JSP since Play has none of
those and no XML bs config). However, you do lose some of the Scala niceties
when going that route. You still can still call to Scala bits of the API in
Java and templates themselves are all Scala (Lift templates), but it's still
not quite the same.

If using something like Intellij, you can still mix and match bits of Scala
and Java in the same project (but not within the same class file) without too
much trouble. Not sure how the official Scala IDE that TypeSafe maintains
handles that offhand.

~~~
haimez
Excellent summary. A lot of the API's are definitely built scala-first, then
adapted for Java. Usually this isn't too bad, but it can cause some headaches
around things like the logger interfaces, etc.

We run a fairly complex java system in the same process as play (similar to an
in-process database) for performance reasons, so given the amount of code
already in java and not having the time to learn scala, java interop, AND
build in the web bindings, we went the Java route.

It's definitely easier to use than something like Spring if you're approaching
both for the first time.

~~~
erwanl
It's not that it's "Scala adapted to Java", but more like a choice to do async
and functional programming even in Java. That makes stuff a bit verbose
sometimes because to pass a function you have to pass an anonymous class.

That will become better with Java 8 and lambdas without having to break
compatibility with older Java versions (they will still use anonymous
classes).

------
ejain
Play is an interesting option if 1. you need async request handling (most
people don't), 2. are comfortable with Scala, and 3. don't mind maintaining
your own branch of the framework (or can pay for commercial support).

Otherwise there are better options, given the hard to configure and slow build
process, bloated artifacts, infrequent releases, missing features (in the Java
version) and incomplete/outdated documentation.

