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.