Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

any experience with "Play" java web development framework? [closed]

I've just stumbled upon the following new java web framework: Play

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...

Sounds like the java web development promised land...

has anybody tried it? any real experience with it? do you think it's worth studying it?

like image 947
opensas Avatar asked Oct 20 '09 20:10

opensas


People also ask

Is Play framework still used?

Play is rock-solid and used by hundreds of thousands of Java and Scala developers every month. Play is still extremely relevant to today's application and web development and has a passionate and very capable community around it ensuring that it has many good years left.

Is Play framework better than spring?

Play is a direct competitor to Spring framework and designed to develop and deploy web applications more efficiently and also provides better MVC framework. In terms of getting a web application up and running quickly, play is the best.

What is a Java web Framework?

A Java framework is specific to the Java programming language, used as a platform for developing software applications and Java programs. Java frameworks may include predefined classes and functions used to process, input, and manage hardware devices, as well as interact with system software.

Is play a Java Framework?

Play is a high-productivity web application framework for programming languages whose code is compiled and run on the JVM, mainly Java and Scala.


1 Answers

I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.

One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.

For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.

That being the case, I see where the Play team is coming from.

  1. Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.

  2. I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.

  3. I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.

  4. The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)

  5. I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.

  6. The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.

  7. I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.

I'll report back again later as I dive deeper in.

like image 162
Craig Jones Avatar answered Oct 13 '22 15:10

Craig Jones