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.
Why I'm Moving Away from the Play Framework
71–80 of 88 posts
Re: Why I'm Moving Away from the Play Framework
#72I'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.
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.
-----------------------
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...
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
Re: Why I'm Moving Away from the Play Framework
#73I'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…
Buildr is a welcome improvement, at least there is no XML on sight.
Re: Why I'm Moving Away from the Play Framework
#74Earlier 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
Re: Why I'm Moving Away from the Play Framework
#75I'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?
Re: Why I'm Moving Away from the Play Framework
#76OP 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
#77Earlier 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.
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
#78http://www.playframework.org/documentation/1.0/templates#Act... and http://www.playframework.org/documentation/1.0/routes#revers...
Re: Why I'm Moving Away from the Play Framework
#79Earlier 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.