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

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

开发者_高级运维 Improve this question

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?

---

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.

---

I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.

Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.

---

After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.

Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.

Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.

That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.

---

I like it, I'm using it for small projects and so far it looks perfect for the job. However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model": http://www.playframework.org/documentation/1.0.1/model

but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...

However, many thumbs up for: development speed, code cleanness, and in the end... fun!

---

I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.

I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)

---

Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.

---

I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...

---

I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.

---

I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.

Regards, Uilian.