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?
What’s new in Play 2.2
11–20 of 44 posts
Re: What’s new in Play 2.2
#12We'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.…
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
#13For 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…
Re: What’s new in Play 2.2
#14We'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?
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
#15Earlier 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
Re: What’s new in Play 2.2
#16Earlier 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?
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
#17We'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.…
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
#18For 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 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
#19We'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…
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
#20We'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…
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.