Play vs Lift?

[Qunfeng Wang]

Why does Scala community choose Play rather than Lift as its de-facto web framewrok? What are the differences between them?

[Peter Hilton]

I don’t know much about Lift, but I can comment on Play. Play is a full-stack framework, which makes it a convenient default choice: it includes everything you need build most web applications.

What might also be relevant is that Play’s architecture. Play is an action-based MVC framework, which makes it familiar to Java developers who have used one of the many existing Java-based MVC frameworks, from Struts 1.x to Spring MVC and everything in between. Also, Play is very HTTP centric, which makes it easier to understand if you have done just about any web development, e.g. using Ruby on Rails.

[Josh Suereth]

That's exactly the answer I think.

Play is *stateless* MVC based webframework.

Lift is *stateful* "View-First" component framework.


Lift does a lot with saving "continuations" on the session to execute on later requests. You code components that tie to views and then set up your pages by stringing together a set of HTML components on the page.

Play takes "stateless MVC" to an art-form. It's a very lightweight framework with a set of minimal conventions to get up and running. Play has really good support for asynchronous programming and pulling together a bunch of disparate data and streaming it as a result. It also focuses heavily on *developer experience*, providing their own SBT project defaults, along with a customized plugin that redoes the experience for developing a Play application.

I think they both have compelling use cases. However (opinion warning), with the push of HTML5 and ever faster javascript engines, the web continues to move in the direction of "Heavier clients" where the client does rendering, stores cached data, and controls flow of the application. Heck, in some modern browsers, the page can alter the URL itself (not just the hash) without a page refresh. While Lift has some really neat/compelling features, my concern is that the Javascript/Front-End developers are running the other direction.

Again, it remains to be seen what happens in the long term, but that's my view of things.

[Ivano Pagano]

Josh Suereth wrote:
I think they both have compelling use cases. However (opinion warning), with the push of HTML5 and ever faster javascript engines, the web continues to move in the direction of "Heavier clients" where the client does rendering, stores cached data, and controls flow of the application. Heck, in some modern browsers, the page can alter the URL itself (not just the hash) without a page refresh. While Lift has some really neat/compelling features, my concern is that the Javascript/Front-End developers are running the other direction.

Don't you think that eventually even HTML5/browser-based programming will evolve to something like client-side frameworks, in which the client will crunch and present data in the best way for consumption, in a structured fashion, while the back-end (server side) will become more and more specialized to data manipulation, aggregation, analysis and service intercommunication? Even follow the CQRS example?
I'm thinking like 5 years from now...
I already see a lot of js frameworks going down this path (angular.js, backbone.js, and the everpresent node.js nowadays).

I think that play! is already "playing" well along this line (no pun intended), but I don't know lift enough to make a meaningful comparison.

Would you elaborate on this please, Josh?
And whoever else have something to say on this, too.

Thanks
Ivano

[Josh Suereth]

@Ivano -

That's exactly what I see happening. Lift focuses on server-side owning "state" of a client's experience. The rest of the web is moving the other direction. Right now, if you compare Play vs. Lift I think Play embraces the notion that it is just a data-munger to a greater extent than Lift, hence my concern for Lift.

Lift was highly opinionated, and they met their objectives well. Unfortunately, I haven't seen the general web embrace heavily-server-side frameworks, with GWT being the one that comes to mind as having the most success. It seems there's been a division between programmers who work on the server, and those that work on the client. GWT suffers the "Server side developers love it, because they aren't comfortable in the client side" and "client side developers hate it, because they want access to the browser + javascript". Granted, that's a simplification, but I think the same split will work against Lift in the long run. More and more web-designers are learning Javascript, JQuery, Angular, Backbone, Ember, etc. These frameworks are driving the state of the art for client-side *AND* are more comfortable for web-designers. While Lift/GWT will always have a niche they fill well, I think the more mainstream web development will continue to push for client-side frameworks and servers that data munge. Heck, even PHP tutorials I've seen recently are all about generating JSON which really seems wrong (given how PHP was designed...).

So yeah, I agree with you, the web is moving towards client-side heavy, stateful, powerful apps. Anyone not riding the current will be struggling to stay mainstream, regardless of the merits of their underlying technology.