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?
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.
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.
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.
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 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.
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.
This is part of Lift’s commitment to security. It’s important.
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.