Live data from Hacker News

Why I'm Moving Away from the Play Framework

whilefalse.blogspot.com

61–70 of 88 posts

Re: Why I'm Moving Away from the Play Framework

#61
post #7

I think that any platform has some gotchas especially a 1.x version, however in my experiences with it it was fast and less boilerplate than a normal Java project and we didn't have any of these issues rolling out locally and to Google AppEngine. I'd still only choose it if I had to use Java though. If you can roll with Django you can roll with Play. Although, I always prefer a python microframework such as flask now…

I've worked quite a lot with both Java and Python and with Play and Django, and before I tried Play I would've agreed with you.

The lightweight nature of Play combined with the speed of the jvm (compared to Python), static typing and IDE support, makes it a winner in my book. I like vim, but wherever I click in a Play project (including in routes, property files and templates), I always end up where I need to be.

Re: Why I'm Moving Away from the Play Framework

#62
As someone marginally involved with the Play project, I would like to point out that, for better or for worse, Play 2.0 is a complete reimplementation of the original design, with a new API and a totally new codebase. Play 2.0 core is now written in Scala (but also exposes a Java API) and relies much less on bytecode manipulation.

Re: Why I'm Moving Away from the Play Framework

#63

I'd be very interested to hear people's responses to this post. I've been considering learning Play as I was very impressed with what I saw.

Sounds like the author doesn't understand concurrency or how to set up the unit tests from an IDE with a version of play framework which is only weeks away from being completely replaced.

Re: Why I'm Moving Away from the Play Framework

#64
post #25

Earlier quoted context omitted.

Play is really not a large amount of code though and it's all in one source tree. It generally doesn't have a lot of "layers" compared to even something like Tomcat; the stack just doesn't get as deep. I've had an easy time digging in to the Play source code when needed. Just one experience fwiw. Sure, it's still a framework.

Agreed. I fixed a handful of bugs in Play 2 while it was still young and immature and didn't have much difficulty tracking them down despite not knowing any Scala.

Despite the propaganda Scala's pretty easy to read.

Re: Why I'm Moving Away from the Play Framework

#65

So what's the best alternative for a Java shop?

I've never gotten a chance to try out Play, I'm no longer doing any JVM stuff... but back when I was a Java guy, my favorite java web framework was Stripes: http://www.stripesframework.org/display/stripes/Home

I've never really understood why Stripes hasn't "caught on." It's simplicity is wonderful.

Re: Why I'm Moving Away from the Play Framework

#66
post #23
post #20

Earlier quoted context omitted.

We're using Apache Wicket and are pretty happy with it.

Has Wicket changed to not require so much code? I wrote a handful of apps using Wicket 1.2, 1.3 and 1.4 before realizing I was writing thousands of lines of code to update UI models and backend models that shouldn't be taxing me so much. Used Play for a few projects, but don't like that 2.0 is more or less getting rewritten... don't like Spring... not sure what is left (JEE6 and JSF2? God I don't want to use JSF agai…

Re Wicket: have a look at PropertyModel and CompoundPropertyModel. You'll lose a bit of type safety, but it will seriously cut down on boilerplate code. In particular it helps map wicket:ids to your Java bean hierarchies by following simple conventions.

Somehow I managed to use Wicket for well over a year before realizing the benefit to this approach.

Re: Why I'm Moving Away from the Play Framework

#69

Earlier quoted context omitted.

I use Play! for my hobby projects and Lift for work. Coming from MVC lift is very bizarre. Having html and javascript inside my scala classes gives me a queasy feeling. I also think Lift is dead. The creator of the project left, the documentation isn't great, View first model isn't popular, very little activity in #lift, very little activity in the lift framework google group. Not good signs.

Are you saying that creator of Lift David Pollak left? Can you provide some links?

He stepped down as dictator at least. See "Committer team maturing" here: http://goodstuff.im/happy-5th-birthday-lift

Re: Why I'm Moving Away from the Play Framework

#70
post #37

I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes). I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts. Play is a very prescriptive framework but onl…

In response to your 2nd and 4th points:

- We have had a fine experience not using Play's ORM support at all -- we have a Plugin that handles transactions for us, and we use non-Play-integrated persistence. It still works great.

- All of the Controller member variables are ThreadLocals, which is how Play handles concurrency. It seems like multi-threaded tests should work just as multi-threaded requests do. I'm curious what problem you're having with parallelizing tests?

Post reply on HN