Live data from Hacker News

What’s new in Play 2.2

playframework.com

11–20 of 44 posts

Re: What’s new in Play 2.2

#11
post #2

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

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

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

Re: What’s new in Play 2.2

#12
post #2

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

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.

Re: What’s new in Play 2.2

#13
post #4
post #3

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…

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 e…

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

Re: What’s new in Play 2.2

#14
post #2

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

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?

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.

Re: What’s new in Play 2.2

#15
post #8

Earlier quoted context omitted.

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

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

Your link is to the old 1.x branch, here are deployment instructions for 2.2:

http://www.playframework.com/documentation/2.2.x/Production

Re: What’s new in Play 2.2

#16
post #13
post #4

Earlier quoted context omitted.

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 e…

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

Never used Jersey so cannot comment on ease of use at the code level. It may be similar, but it'll likely not have other nice features that Play has that sets it apart from other Java Frameworks.

I was comparing against any Java Framework that depends on J2EE and JSP though as that comes with an excessive amount of baggage that's really hard to get rid of totally (like excessive use of XML tooling/configuration). If one's reason for never touching Java on the web is because of the XML nightmare it generally brings, then Play is the framework one has been searching for. There's no use of XML anywhere that is required and templating/views are similar to what one would do in any scripting language since they're really Scala (Lift) templates and not kludgy JSP that reminds me of ColdFusion.

Also, being built on Scala shapes Play 2.0 in ways that other Java Frameworks are not by design, since Scala is generally against excessive verbosity and it's a Java habit that dies hard for some even when trying to avoid it.

I'll admit I'm biased against excessive XML tooling and configuration, since I come from a PHP & Python background in web development, but I dislike all that boilerplate. I realize it's sort of a common part of almost everything Java, but it's also why I stay away from Java on the web as much as possible.

Edit: Jersey does make use of JSP[1] (Java Server Pages). Some may not find that to be bad thing if they're used to it from prior experience, but I would avoid it personally. If coming from a dynamic programming background on the web (Node.js, PHP, Python, Ruby, etc), JSP is not a fun time.

[1] https://github.com/jersey/jersey/tree/2.3/examples/bookstore...

Re: What’s new in Play 2.2

#17
post #2

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

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.

Re: What’s new in Play 2.2

#18
post #4
post #3

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…

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 e…

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.

Re: What’s new in Play 2.2

#19
post #2

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

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 engi…

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.

Re: What’s new in Play 2.2

#20
post #2

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

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 engi…

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.

Post reply on HN