Comparing Lift with Play2
I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.
Yesterday I read "Scala for the impatient" and I really enjoy the language.
Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.
But for me it is hard to tell what the main differences are. I think both frameworks are great.
The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor. (I have not much experience, this is just my first impression)
For the security I don't think that is the job of the framework.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Both frameworks are able to compile after you press F5. I like this feature a lot.
Both frameworks are using sbt
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience) Edit There is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
- What are the strengths of each framework?
Answer
Posting this after spending a week or two with Lift doesn't really serve anybody's interests. However, I want to spend some time correcting some mistakes and mis-perceptions.
- For the security I don't think that is the job of the framework.
You're dead wrong. Security is the job of the framework. It's critical that security is done by default rather than relying on each developer to understand every security vulnerability and make sure every line of code takes that into account.
All we have to do is look at what happened to GitHub to understand that even the best coders using well known technology can make a critical mistake.
Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc. but the developer can dig down as deep as he wants to the HTTP request and deal with the bytes on the wire.
- Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Lift is very clear about where you need state and where you don't. Lift can support stateless, partially stateful, and completely stateful apps. On a page-by-page and request-by-request basis, a Lift app can be stateful or stateless (for example, in Foursquare, the venue pages are stateless for search engine crawls, but stateful for browsers that are logged in.) For more on the design decisions around state, please see Lift, State, and Scaling.
- Both frameworks are using sbt
Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment and about the deploy environment (Java EE container, Netty, whatever). This is important because it make Lift easier to integrate with the rest of your environment.
- Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.
- Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web framework because, among other things, it multiplexes all the "push" requests on a page through a single request to the server which avoids connection starvation. How Lift does async is a whole lot less important because one of the core philosophies with Lift is that we remove the plumbing from the developer so the developer can focus on business logic.
But for those who care, Lift has the best and lightest weight actors of any framework in Scala-land. We were the first to break away from the Scala Actor's library and worked to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors to flourish.
- Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
This is part of Lift's commitment to security. It's important.
- Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
Lift apps can be as stateful or as stateless as you want. It's your choice and Lift makes very clear how to make the decision.
Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out how to serialize state in a secure, scalable, performant way (because virtually every request on a web app that recognizes specific users is stateful) should be done in a predictable, secure way by the framework with reasonable overrides for the developers.
Parting note
Play is a lot like Rails: it's quick to get a site knocked together and it's based on MVC, so a lot of developers understand it. But Play lacks the depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you want quick, easy MVC, then go with Rails and JRuby and write your back end in Scala (they work together extraordinarily well.)
Lift is a different beast. There's a significant unlearning curve (stop thinking MVC and start thinking about user experience first that flows to business logic.) But once you're up the unlearning curve, Lift sites are more secure, highly scalable, super-interactive, and much easier to maintain over time.