Live data from Hacker News

Why I'm Moving Away from the Play Framework

whilefalse.blogspot.com

71–80 of 88 posts

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

#71
post #41
post #3

I'm interested to know what alternative framework the author has chosen in place of Play!.

She said on Twitter she is looking at Dropwizard: https://github.com/codahale/dropwizard That's focused on RESTful services so presumably also a JS templating tool browser-side or similar.

DropWizard, huh? I'd be really careful about anything that overly simplifies opening up CRUD functionality via REST. Be sure to spend some of that time you save looking into the security of your service. Easy generation of RESTful services has bitten many a Rails developer, for example.

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

#72
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 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) consists of frontend HMTL/CSS designers, frontend Javascript UX devs, and backend devs, then that architecture may not be optimal.

> I also think Lift is dead.

Far from it.

> The creator of the project left

Not exactly:

1. He's still a core committer,

2. Advised the founders of Lift Co. [1] - commercial support/SLA for lift projects,

3. Is active on the Lift group [2] (the activity takes place there and at Assembla [3], not Twitter)

4. Continues to present about [4], blog about [5][6], and advocate Lift [7].

5. Even holds personal office hours every week in San Francisco to support Lift devs, for free. He's just not doing direct commercial consulting on Lift anymore, others have grabbed that torch and are running with it, primarily in SF, London, and India.

> the documentation isn't great,

True, but improving. The new book from Manning, Lift In Action [8] is excellent. You can buy it from Manning, or obtain it by other means. There are completely free options as well [9].

> View first model isn't popular

Popular is not necessarily better [10], unfortunately. However, if you grok view first and still believe MVC is better, Lift also includes an MVC version [11] for you.

> very little activity in #lift,

The meat of the discussion is on the google group [2], not Twitter. (And it's #liftweb anyway, but admittedly not much difference there either).

> very little activity in the lift framework google group.

Maybe you're comparing to a mega project like Rails, or maybe you accidentally mistook the stickies at the top for the actual group activity, but there's more than 'very little activity' in the group.

Granted, Lift isn't without issues. Getting started via Maven is painful (Pro-tip: use SBT + Lifty [12]). It has a non-trivial learning curve (I actually had to learn Haskell in order to grok Scala in order to use Lift - all worth it - though people coming from the ML family may have an easier ramp-up); has to deal with Scala's versioning and dependency issues (which David Pollack ticked off the Scala community by vocally complaining about, and which SBT does a decent job of mitigating), and does most things differently than the norm.

However, it's a superb piece of technology more than worth the effort to learn. It's more inherently secure than any other framework out there, enables a simple architecture (3-tier only, web/app/db, no caching layers), is relatively easily scalable (just add more instances to whichever layer you need to scale), does Ajax and Comet better than anything else, is very productive once you know it (minimal code, no testing necessary for classes of errors the type system or compiler catch), and lots of other excellent stuff [13].

It's evolving, maybe not at the pace of Rails, but it's starting with a far stronger technical architecture, runtime, and Java ecosystem interopability.

-----------------------

1. http://liftweb.com/

2. http://groups.google.com/forum/?fromgroups#!forum/liftweb

3. http://assembla.com/wiki/show/liftweb/

4. http://www.infoq.com/presentations/Exploring-Composition-and...

5. http://lift.la/

6. http://goodstuff.im/

7. http://visi.io/ (see comments on Lift)

8. http://manning.com/perrett/

9. http://www.assembla.com/spaces/liftweb/wiki/Resources; http://richard.dallaway.com/lift-cookbook-an-introduction

10. https://www.assembla.com/wiki/show/liftweb/View_First

11. http://www.assembla.com/spaces/liftweb/wiki/MVC_(if_you_real...

12. https://github.com/harrah/xsbt; https://github.com/Lifty/lifty

13. http://seventhings.liftweb.net/

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

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

The only good idea in Maven is the standardized repository layout, the rest is useless ceremony although much of it is because of retarded J2EE application servers.

Buildr is a welcome improvement, at least there is no XML on sight.

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

#74
post #69

Earlier quoted context omitted.

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

Which, fwiw, is a good sign, that the project is self-sustaining enough that the founder can hand off his baby to the community around it.

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

#75
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?

Ask about Lift on the google group. They're honest about advising whether Lift is a good fit for a particular project or not. They want success stories, and tend to advise against Lift for any project that could have serious issues ramping up on Lift:

http://groups.google.com/forum/?fromgroups#!forum/liftweb

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

#76
While OP has met some problems, I don't see how these would drive him away. I'm curious what framework he's moving to.

OP is looking for a silver bullet and there ain't one. Play! is an open source project, so the developers didn't have time to deal with his patch and he got upset. People forgot OS devs don't get paid for their work. Be a little bit more appreciative.

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

#77

Earlier quoted context omitted.

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.

Magic fix: ConcurrentHashMap....better still write your own.

I hope this is a joke. I know plenty of very good Java programmers, but only one or two that I would ever trust to write a concurrent hash map class that matched java.util.concurrent.ConcurrentHashMap's functionality (to say nothing of performance), let alone improve on it.

It's a nasty chunk of code, it's not a simple matter to get this right: http://www.docjar.com/html/api/java/util/concurrent/Concurre...

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

#79

Earlier quoted context omitted.

The fix you're proposing is innadequate for a lot of instances. A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations. This is why this model of threading is hard, because it is not composable. Also, threadsafe data-structures have terrible performance characteristics, unless…

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.
Post reply on HN