We spent a fair amount of time evaluating lift, play and other frameworks recently. We ended up choosing Play for these reasons:

Developer Productivity - Having worked with a lot of the major frameworks they are all very comparable. You can say the same things about Play, GWT, you don't worry about the plumbing, setting up routes, ajax, etc. ...

Learning Curve - You really need to know Scala and functional programming to be effective with lift. Even though lift itself might be more productive, easier, etc. none of that matters if you are not experienced in Scala. And becoming truly experienced in Scala takes a fair amount of time.

Play is plain Java and so it took the developers on are team less than a day to become productive with Play, they have a great tutorial that walks through all the major parts of a Play framework.

Developer Perception: Seriously emacs? Textmate is the only way to go.

Developer Availability - Well you might be able to find Lift developers, but they come at a major premium because they know Scala. Java developers are much more common and don't have the major premium. And there are a lot more Java than Scala developers (DP charges a very healthy $250 / hour - http://www.quora.com/What-are-the-going-hourly-contracting-r... )

Templating - Yep most frameworks have them, pretty common.

Plugins - Play has those in the form of modules

In the end I would agree with Raible's findings, there is not a huge difference in frameworks.

I do find one thing curious about all of David Pollak's rants are they always reference Foursquare and Novell.

It's also pretty easy using Scala with Play if you do decide to switch at some point.

Just would like to say that emacs is much better than vi... at giving you carpal tunnel syndrome. Thank you very much.

I heard you could do just about anything in emacs... but using it as a web framework?

Ok, now I just have to give emacs a try.

Anyone here used lift and found a level of productvity over Django/Rails/PHP Framework of choice?

I find most of the things that make money tend to be boring crud applications which really don't require much in the way of fancy features which makes one of the main arguements in the article invalid.

I am itching to learn something new though but wonder if its going to be worth it or should I turn my attentions to something more mainstream.

From what I can see on the presentation that he links to, there's nothing to warrant the 10x more productive claim. Perhaps he's just doing a bad job of explaining the secret sauce, but I mean really? Shit like:

    bind("tip", xhtml,
         "done_checkbox" ->
           ajaxCheckbox(userStatus.equals(Full(TipUserStatus.done)), (b: Boolean) => {
             val currentUser = User.currentUser.open_!
             val evertodo = TipUserBind.find(By(TipUserBind.tipid, this),
                                             By(TipUserBind.userid, currentUser)) match {
               case Full(tub) => tub.delete_!; true
               case _ => false
             }

makes you 10x more productive? The spreadsheet is also just for JVM frameworks, although some of them are probably MVC too, it's hard to tell.

Also, you can really tell that both the parties involved come from heavy corporate backgrounds, with massive tables of features and rating them against each other. A scale of 0, 0.5, 1.0? And then the Lift guy switches to /11? Give me a break...

http://en.wikipedia.org/wiki/Up_to_eleven 11 is a joke.

Yes, I know. It still doesn't make me want to love his web framework though.

All of my backend work is currently in Scala. I evaluated Lift for a while for my frontend, but I was turned off by it for a few (probably stupid) reasons:

1. The documentation is poor compared to other frameworks, and there's not anywhere near as much collective knowledge around it on the web as with kits like Django or Rails. That isn't entirely bad (you don't have to wade through tons of people who have no idea what they're talking about), but it is frustrating to feel like you're the only one who has ever tried to do something with the code.

2. While they're good about keeping their internal libraries well-factored and independently usable (and I do use a few in other projects), overall, I find the project to be downright overwhelming in its scope. There's just a lot there. They've currently got 131 branches going on github. They implement their own json library, their own actors, their own version of Option, etc, etc. This isn't bad, and for many I'm sure it's actually welcome. For me, though, I value feeling like I 'get' a project, that I understand its scope, what it's providing for me, where it's going, and how to extend it safely myself. I never felt that way with Lift.

3. I don't share their vision on state, or at least the vision they had for a long time. I understand that 2.2 is going to be a lot friendlier for stateless development, though, and that might send me back for another look.

What is your strategy for making money with boring crud applications? Consulting? In-house software developer? How much are you earning with this strategy?

Consulting and In-House software. Most of them I can throw together in a few hours using any framework I am slightly familar with.

As for how much, its on a case by case basis. I charge less for non-profits and people who are generally nice people.

Is David Pollak trying to take on DHH for the title of most inflammatory framework creator?

If so, well played.

He certainly does well with agreeing (with himself) that his work is great.

A great possibly purposely-obtuse example from the blog piece:

> Testing, What does this mean? Does it mean Lift isn't well tested... I beg to differ. Lift powers sites like Foursquare and Novell Vibe. You can see the Lift tickets and find all the tickets opened by Novell and Foursquare... not a lot.

Right. When people mention testing in a framework, they must be talking about testing the framework itself and not the framework's ability to help them test their own code. Sheesh, the ego.

I think it's just precious that he does not even understand the question.

On top of that, implying that "not a lot" of tickets must mean that every works hunky dory because you've got a couple of large-scale sites using it is rather naive.

He loves what he made, sure. However, I don't see where he is saying anything particularly inflammatory, especially in comparison to DHH's f-u to enterprises. Further, this post lists specific counter-arguments that are backed with examples. If this is inflammatory, then I would like to see more "inflammatory" posts comparing frameworks that are like this.

I would call made up statistics about the greatness of your framework (11x better!) hilariously inflammatory. In fact the humorous depth of the statements' detachment from reality kinda takes any real power to incite away from them.

I don't see neither this rant nor DHH "f-u to enterprises" (a not very descriptive of the real thing term you coined) as inflammatory.

Writing code is easy. How many developers can't type at least as fast as they think already? Writing something that makes sense later is the hard part; especially if you aren't the one reading it.

Ultra-terse code is rarely helpful in that regard.

I switched to the Play framework for my Java web development earlier this year and it is the first time in my career that I have stopped looking for other Java-based web frameworks.

Why does the font size change randomly throughout the article?

easy skimming.

I wonder if running lift / scala on GAE jvm would be worthwhile; if you could hack it to work with the channel api for all the comet stuff...

The opinion in the community seems to be that GAE is a bad fit for Lift development. Lift takes a statefull approach in order to enable the developer friendly auto-plumbing of forms/ajax/comet/etc., and this breaks down under the GAE restrictions. You might want to take a look at stax.net instead, or just use a vps such as linode.

Discussion of stateful vs "stateless": http://lift.la/lift-state-and-scaling

No lift users out there making a point for it?

I'm usually 10x more productive using frameworks that I wrote.