Lift: 10x more productive than any mvc framework
lift.la
lift.la
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.
Ok, now I just have to give emacs a try.
If so, well played.
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 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.
As for how much, its on a case by case basis. I charge less for non-profits and people who are generally nice people.
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...
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.
Ultra-terse code is rarely helpful in that regard.
Discussion of stateful vs "stateless": http://lift.la/lift-state-and-scaling