What’s new in Play 2.2

http://www.playframework.com/documentation/2.2.0/Highlights22

by proxyswapi • 13 years ago

92 43 13 years ago

playframework.com

saryant5• 13 years ago

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.

zeckalpha• 13 years ago

Why use a Rails / Play hybrid? I can understand separating the front- and back-ends, but why not stick to one platform through and through? Momentum? Expertise? Marketing?

saryant5• 13 years ago

The founders wrote the frontend in Rails before I came on board but it does very little work. Really it just handles authentication and captures OAuth tokens.

I imagine we'll move it to Play eventually but right now we're focused on the backend (Play/Akka) because that's where everything really happens.

Nickoladze• 13 years ago

Sorry if I'm being dumb here, I've never heard of Play before. It is a replacement for Tomcat?

russ5193• 13 years ago

Play is a web development framework. It has the capability to run standalone using it's built in http server or it can output a .WAR file that can be run under containers like Tomcat.

http://www.playframework.com/documentation/1.2/deployment

yareally4• 13 years ago

Play 2.0 comes with Netty[1] built into it for making asynchronous requests, websockets and REST easier to handle. Netty is what replaces Tomcat unless you choose to use a third party plugin that builds your Play 2.0 website as a WAR file. Also, with Netty, it builds the entire site into a self contained module that you can run with one click anywhere you have the JVM installed (and the dependencies such as the DB if not using the built in H2). I found it useful for quick presentations or portability.

[1] http://en.wikipedia.org/wiki/Netty_%28software%29

lmm• 13 years ago

No, it's mostly replacement for the spring-web/struts/jersey/etc. layer (though it also has its own templating layer to replace JSP or whaever). You can run it under tomcat if you want to.

vassvdm3• 13 years ago

Also using Play at a start-up, but as a customer-facing web app. It's great for productivity - getting both compile- and runtime errors in the browser kind of means that you have the advantages of Scala/statically-typed languages combined with those of dynamically typed languages. If you're ready to go fully stateless and (mostly) asynchronous/non-blocking, this is the framework for you.

I agree that documentation is still lackluster. I would add that although I love the Scala templates, the support for html forms in Scala is a bit clunky. Also there are still a few too many changes requiring code refactoring on minor releases, but I accept those as a byproduct of quick iterations/improvements.

stingraycharles• 13 years ago

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.

kev009• 13 years ago

It's optional; nothing forces you to use them vs doing the AJAX du jour.

Play templates are particularly speedy though, they get compiled into JVM bytecode. I actually prefer doing things that way and keeping markup and JS to a minimum. It 'feels' faster and more robust to me.

saryant5• 13 years ago

We use the templates to render email messages on the server primarily.

Note that Play doesn't force you to use the templates, you can plug in your own very easily or forgo them entirely and just push JSON out for client-side rendering.

We use that for monitoring our backend Akka cluster: Play streams JSON using server-sent events to the client for rendering Mustache.js templates.

I don't know the exact motivation for including compiled templates (we love them) but in practice Play is perfectly happy either way.

nek4life• 13 years ago

If you have an application that doesn't need to be indexed by search engines, yes. If you have a content heavy website the preferable method is still to render templates on the server. It still varies depending on your use case. I wouldn't say that is the status quo at all.

virtualwhys2• 13 years ago

I don't know, maybe type safety?

Don't forget about Play's truly excellent form generation/validation, and yes, raw speed of jvm byte code.

Rails truly (DHH) made a blog post on why they switched to generating html server-side: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

nostromo• 13 years ago

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.

SkyMarshal• 13 years ago

Definitely not status quo. One big example is when Twitter moved away from that back to server side rendering for performance reasons [1].

There are basically three aspects of website performance - server performance, network performance, and client performance. You can control server performance and network latency (CDN), but you can't control what's going on on your users computers.

For example, if they're tab-abusers (guilty as charged) with 50+ non-trivial tabs open, plus other apps open and stuff running in the background, then your beautiful high-performance UI could start chugging (as many do on my abused laptop).

So you really have to think about what your main userbase will be and whether you need to put the rendering chunk of your app's CPU usage on your own servers or on your client's desktops/laptops/tablets/phones.

[1] https://blog.twitter.com/2012/improving-performance-twitterc...

- http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-R...

eropple6• 13 years ago

Fully agreed on a most of this; when Play does something well, it does something really well. I personally just wish the build system wasn't such a mess and so antithetical to good development practices--it's extremely hard to have something like a shared domain library among multiple projects (with hot reloading, i.e. if you need to iterate on it while you develop) without making a fake Play project with a conf directory and all of that. It feels built for independent systems/applications rather than ones that play (ha) nicely with each other.

(Also, using the Flyway module has made life a lot easier. play-evolutions is a bit wonky.)

saryant5• 13 years ago

You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine.

That's how we do it anyways.

virtualwhys2• 13 years ago

This is true, although I'd replace "multiple projects" with "multiple applications" as you can most definitely create highly modular applications using SBT sub projects.

The dirty *nix hack for this is to symlink the shared library; otherwise, converting the lib to a plugin is one way toward creating reusable cross-application libraries.

russ5193• 13 years ago

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.

yareally4• 13 years ago

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.

russ5193• 13 years ago

Awesome, thanks for the info!

haimez• 13 years ago

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.

taeric2• 13 years ago

When considering the verbosity, are you comparing to the modern frameworks such as Jersey?

vassvdm3• 13 years ago

I agree with the above. As a Java and Scala programmer I've tried both and Play! 2 Scala is a joy to use if you're fond of idiomatic Scala and functional programmming.

I use Eclipse with the Scala IDE plugin and although I write all of my code in Scala, I do have a couple of dependencies to Java libraries (the interop works perfectly, but of course you should be careful when mixing immutable code with potential sources of mutability). The Intellij plugin is probably still the more stable of the two, but as mentioned by yareally the Scala IDE is the officially maintained one so you can expect new features to come to Eclipse before Intellij.

eropple6• 13 years ago

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

It doesn't sound like you're really familiar with other Java frameworks. While I'm not really a fan of it, Ninja (as just one example) has none of that, and also doesn't have the torture chamber that is Play's (non-standard, custom, even more undocumented) flavor of sbt--easily the worst not-Maven Maven tool I have had the displeasure of working with.

I want to like Play because I love a ton of what they do, but just having to deal with sbt and the non-standard, doesn't-play-nice build system that they enforce has driven me away from it.

vassvdm3• 13 years ago

BTW if you're interested, Martin Odersky and others will host a brand new Coursera class focusing on Reactive programming starting in November:

https://www.coursera.org/course/reactive

It doesn't say so explicitly in the course description, but I guess we will be using Play and Akka during assignments. If it's half as good as his introduction to Functional Programming in Scala, it will be a treat.

namelezz• 13 years ago

Scala no doubt for its expressiveness power. Extractor, case class/object, pattern matching, first class function, curry function, partially applied functions, implicit, trait and more are so powerful. Use them with caution or you will hate Scala. Rofl!

ejain• 13 years ago

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.

What’s new in Play 2.2

Related Stories