This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Scala and the fly likes Play vs Lift? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Languages » Scala
Bookmark "Play vs Lift?" Watch "Play vs Lift?" New topic
Author

Play vs Lift?

Qunfeng Wang
Ranch Hand

Joined: Jan 28, 2005
Posts: 426
Why does Scala community choose Play rather than Lift as its de-facto web framewrok? What are the differences between them?


To be or not to be. It's a question.
Peter Hilton
author
Greenhorn

Joined: Jan 31, 2013
Posts: 2
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
Author
Greenhorn

Joined: Jan 24, 2013
Posts: 15
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
Ranch Hand

Joined: Dec 16, 2006
Posts: 47

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
Author
Greenhorn

Joined: Jan 24, 2013
Posts: 15
@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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Play vs Lift?
 
Similar Threads
Extent of Scala expertise for working with Lift
Lift and jQuery
Is Lift a Scala framework like Play?
Scrabble... it only takes a minute...
WA #1.....word association