Comparing Lift with Play2 [closed]

Question

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?

Gourmand

May I suggest you remove the part about what you want to do? You could still open a second question for the "which is good for me?" and keep the "what are the differences?", as the latter seems more interesting as a reference for others. – Mikaelamikal

Answer 1

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.

Nemeth

Thanks this is a very good read and it cleared some false information. – Gourmand

Lift is indeed a different beast, which may be why TypeSafe...adopted Play, and Slick instead of Mapper and so on. Play like Rails is an open gate, everyone "gets" it, and unlike Rails, Play is blazing fast, scalable, intuitive and plain awesome. Pidgin holing Play into the simple MVC (with implied not for the complex) viewpoint, cobble it together with Rails/JRuby/Scala instead -- is plain ole' FUD – Rola

No, Typesafe adopted Play because I decided that it's better not to work with Typesafe and have rejected their offers to join forces. Play is their only real alternative and it's a weak one. – Nemeth

Robin, David said many times and in many places that he has not "left" the Lift. He is still committing code and answering in the Google groups. Actually, it is only a plus that such giant brain is engaged in multiple projects / multiple languages. Every project only benefits from it - because David can always compare/add things/hacks and his experience from different communities/projects. – Bordiuk

@RobinGreen: Lift also has a Java API. If it could use more development it's only a reflection of lack of demand. – Spawn

@Meglio: He "said"? Just look at the lift mailing list, or github! :) I don't think think his participation in Lift has gone down noticeably at all (may be my memory of course). Also he's not just involved in visi.io, also telegr.am (though the latter is "in" Lift I suppose) – Spawn

@RobinGreen Don't spread lies. I never "left" the Lift community. Yes, I have other project and work in different languages. What I did was cease to be Lift's benevolent dictator for life. Lift has grown way beyond one person and the fact that the 2.5-M4 release was done without me is a strength, not a weakness. There are a ton of great brains in the Lift community... I am simply one of many people that make Lift what it is. But I actively code Lift and actively participate in the Lift community. – Nemeth

@DavidPollak, I apologise for inaccurately characterising what had happened, and for not going back to check my understanding before writing that comment. I had assumed that because you had founded this new project, Visio, that you would be devoting the majority of your time to it, and therefore your participation in Lift would be minimal from that point on. Clearly, that was not the case. – Prado

Why is it better to not work with them?, do you have a post about it or something? – Albric

@DavidPollak I am not extreme hands on play and haven't touched lift at all. But going by your explainations, how you made it equivalent to Rails totally? when you yourself admitted that it can have state, plus it has async support while I believe Rails out of the box has not. Second does that also implies Lift has nothing to do with MVC? If not, then what does Lift says? Is it more like a "make your own framework" approach? – Abbeyabbi

@DavidPollak Hi David. I am a novice about to try your framework. The phrase "It's better not to work with Typesafe"... "rejected their offers" makes you sound kind of egotistical. Even if you are right, you don't want to sound egotistical. – Torp

Lift documentation is poor and very hard for a newbie to get into it. Maybe that was the reason. Has that ever occurred to anyone? – Michelson

This reads like an ad. There is helpful information in there but it feels very biased. Maybe there should be a disclaimer at the top. – Lacteal

Answer 2

To see what can be done with Play (it can be cool), have a look at the TypeSafe Console

To get going quick with Lift, use a template project.

For a sample of using Mongo with Play, look at Factile.

In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).

Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.

For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.

Alexio

For the record, I have all the main parts of Lift (including mapper) building on 2.10 M7 at github.com/lift/framework/tree/nafg_wip_scala210, and I personally use it in production. I haven't run most tests yet though, so I can't guarantee its use. – Spawn

Play is just a pain, they introduce breaking changes so often that if you upgrade even a minor version you site is broken. – Ilarrold