Why I'm Moving Away from the Play Framework • Hacker News Board

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

#31

Post by eternalban » Fri, Mar 09, 2012, 6:49 PM UTC

rkalla wrote: post #23

scylla wrote: 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…

IFF latency isn't an issue, just chop the front-end and expose services from the Java container (where it shines and makes perfect sense) and use a suitable non-Java front-end tech to create the presentation layer.

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

#32

Post by benmccann » Fri, Mar 09, 2012, 6:50 PM UTC

hp wrote: post #25

fauigerzigerk wrote: post #22

This confirms my bias against frameworks in general and in fact against reusing more code than necessary. And no, I would not write an encryption library myself or re-implement the HTTP protocol. But the disparity between what web frameworks actually do for me in any particular application and the amount of layers and dependencies they introduce boggles my mind. [Edit] If you use maven try mvn dependency:tree

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.

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

#33

Post by beersigns » Fri, Mar 09, 2012, 6:50 PM UTC

stcredzero wrote: post #19

scottbessler wrote: post #14

Earlier quoted context omitted.

I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.

I'm not if sure the author understands concurrency. EDIT: Author of the blog post.

I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own.

EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.

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

#34

Post by burningout » Fri, Mar 09, 2012, 6:50 PM UTC

stcredzero wrote: post #24

hp wrote: post #18

"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework." Fair enough, but I wouldn't switch to an inferior framework over it.

If that shop is stuck with debugging into a method in HashMap, then they aren't qualified to evaluate whether or not it's in the framework. That said, the developer community needs to address the problem though education, if it's user error (most likely) or come up with enough manpower to be more active in support. After having seen their video, I have to say that the Play! framework folks seem very insightful in the…

We use play in all our projects and hit some bugs as well. (Like different versions of classes being in jars and in code -> signature mismatch) It's a great project and no software is without bugs.

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

#35

Post by aaronblohowiak » Fri, Mar 09, 2012, 6:51 PM UTC

stcredzero wrote: post #19

scottbessler wrote: post #14

Earlier quoted context omitted.

I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.

I'm not if sure the author understands concurrency. EDIT: Author of the blog post.

Author of Play or of the blog post?

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

#36

Post by eropple » Fri, Mar 09, 2012, 6:56 PM UTC

oacgnol wrote: post #4

I'm curious as to specific code examples where the author is having problems. I'm thinking about using Play! or Lift for a pet web app using Scala. Does anyone have experience using either?

I would not use Play 1.x for Scala applications; its non-blocking support is complete crap (and I was pretty displeased to hear, when I asked in their IRC channel, that it would never be in 1.x, oh and by the way to use 2.x you'll need to rewrite your app).

I can't speak to 2.x.

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

#37

Post by cletus » Fri, Mar 09, 2012, 6:56 PM UTC

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 only on a couple of choices do I have an issue.

The first is about transactions. Each HTTP request is a transaction. Generally I'm fine with this but you need a way to override or control this (IMHO).

Second, I like the mixin approach with controllers (@With(...)). I wish there were something similar with models.

Third, and this is the biggest, it doesn't integrate with Maven, which is something I'm very tempted to fork it for. There's no reason it can't be a Maven plugin/archetype, use Maven for dependencies (directly, rather than tortuous syntax in dependencies.yml), etc. Some guy has an alpha version of something like this already when I last looked.

Fourth, while I don't necessarily mind that controllers are static (as a way of indicating they're stateless it seems), that's actually an issue for parallellizing tests.

Play 2.0 is moving even further away from this and using SBT, which I've never used but heard mixed things about.

I can't speak to many of the specifics of this post (eg I only use Play on Linux).

Whatever (valid) criticisms you can level against Play I'd still far and away prefer to use it over any other Java Web framework I have used or know about.

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

#38

Post by stcredzero » Fri, Mar 09, 2012, 6:57 PM UTC

burningout wrote: post #34

stcredzero wrote: post #24

Earlier quoted context omitted.

If that shop is stuck with debugging into a method in HashMap, then they aren't qualified to evaluate whether or not it's in the framework. That said, the developer community needs to address the problem though education, if it's user error (most likely) or come up with enough manpower to be more active in support. After having seen their video, I have to say that the Play! framework folks seem very insightful in the…

We use play in all our projects and hit some bugs as well. (Like different versions of classes being in jars and in code -> signature mismatch) It's a great project and no software is without bugs.

It's a great project and no software is without bugs.

What makes or breaks great software is community and culture.

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

#39

Post by benmccann » Fri, Mar 09, 2012, 7:05 PM UTC

eropple wrote: post #36

oacgnol wrote: post #4

I'm curious as to specific code examples where the author is having problems. I'm thinking about using Play! or Lift for a pet web app using Scala. Does anyone have experience using either?

I would not use Play 1.x for Scala applications; its non-blocking support is complete crap (and I was pretty displeased to hear, when I asked in their IRC channel, that it would never be in 1.x, oh and by the way to use 2.x you'll need to rewrite your app). I can't speak to 2.x.

You don't need to totally rewrite your app, but it's not backwards compatible either. The biggest change is that they've switched the default views to be written in Scala instead of Groovy. But if you'd still like to write the views in Groovy or are porting an app from 1.x, there are a couple of guys in the community who have written plugins to support writing your views in Groovy.

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

#40

Post by benmccann » Fri, Mar 09, 2012, 7:12 PM UTC

UK-AL wrote: post #15

JohnTitus wrote: post #8

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

Depends what your doing... I have JEE6 template project which basically set up with everything configured. This can be nearly as productive as django.

I was doing basically this before moving to Play 2. I just found there was a lot you had to decide for yourself. You had to pick a persistence layer, roll your own xsrf protection, do your own integration of a JS compiler/minifier, etc. I had something pretty good working, but got tired of having to write the code for every new technology integration myself. The thing I like about Play 2 is that I have an entire community helping me out with these things.