Live data from Hacker News

Why I'm Moving Away from the Play Framework

whilefalse.blogspot.com

81–88 of 88 posts

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

#81

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.

> Having html and javascript inside my scala classes gives me a queasy feeling. Yeah that's an interesting tradeoff. I like it because it helps keep code completely out of the html templates, which is a design goal of lift. I tend to work with designers who do HTML/CSS only, not javascript, and I do the backend Scala and frontend Javascript, so that separation of roles works. But if your dev team (as most big ones do…

Presumably #lift referred to an IRC channel, not Twitter. [I have no dog in this fight, just something I noticed.]

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

#82

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.

Stripes was pretty much subsumed by JAX-RS. There are a few rough edges surrounding html rendering (thus microframeworks like Htmleasy) but for the most part, Stripes is no longer necessary.

Most of the history of Java web frameworks focused on ways to make form processing easier. Nobody (sane) does html form processing anymore. The "framework" needs to be little more than a way to render html templates and an rpc mechanism.

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

#83
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…

Good analysis.

I like Play overall but two things concern me, both related: 1) they are moving toward Scala and 2) they are adopting sbt.

This looks to me more like a "picking a shiny toy" move than something that is being done to benefit users (Scala is still quite a marginal language and sbt is very controversial, even among Scala enthusiasts).

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

#84

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 didn't just leave Lift, he left Scala altogether. He's now working in Haskell. Check his latest blog posts for the details (and the scala-tools.org controversy).

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

#85
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…

Good analysis. I like Play overall but two things concern me, both related: 1) they are moving toward Scala and 2) they are adopting sbt. This looks to me more like a "picking a shiny toy" move than something that is being done to benefit users (Scala is still quite a marginal language and sbt is very controversial, even among Scala enthusiasts).

They support both Java and Scala so not really an issue. In any event their support for Scala is the very reason I am looking @ play.

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

#86
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…

SBT is really just Maven without as much XML boilerplate. The syntax might be a little different but it integrates perfectly with Maven repositories. For my SBT projects I pull in a bunch of maven projects and they interact seamlessly. also it took the huge XML configuration file and replaced it with a few lines of configuration code. The only downside to being a different tool is with some of the plugins. I know maven has a much better plugin landscape then SBT does at this point, but SBT does have the ability to have the same functionality.

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

#87
post #79

Earlier quoted context omitted.

Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.

ConcurrentHashMap is not lock free, it uses lock striping across multiple buckets.

I stand corrected.

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

#88
Play! is one the best things that has happened to java in the last 10 years!

From the post I understood that she was pissed because they did not accept her fix on testing the app from the IDE.

The second point was that there is a bug in the framework that they could not find... it seems though as the bug is in their application. (concurrent modification of a Map is a problem in java not Play!)

It's a pity to give up such a great framework for silly reasons.

Every time I have to switch to another framework (especially jsf) I want to shoot myself.

Anyway... good luck finding another good java framework.

Post reply on HN