Re: [Lift] how does lift compare with play? what are the major differences?

[David Pollak]

Please see http://seventhings.liftweb.net

Lift is better than play in all ways (security, code conciseness, Ajax support, Comet support, etc.) except that Play has a nice change/reload cycle (you skip the compile/restart cycle) that Lift kinda sorta does okay with JRebel, but the quick turn-around thing is better in Play.

On Thu, Oct 18, 2012 at 7:02 AM, gitted <sahme...@gmail.com> wrote:

When comparing lift with play, what would you say are the major differences between the 2 frameworks?

Are they both general purpose web app frameworks or is one framework better suited for a particular problem domain?

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Kevin Lau]

I never saw a complain like this from Lift-framework. It only implies Play has major development issue to meet their community wants.

https://groups.google.com/forum/?fromgroups#!topicsearchin/play-framework/play$202.0/play-framework/822TVJ8ovx8

[David Pollak]

On Thu, Oct 18, 2012 at 1:29 PM, Kevin Lau <kevin...@gmail.com> wrote:

I never saw a complain like this from Lift-framework. It only implies Play has major development issue to meet their community wants.

https://groups.google.com/forum/?fromgroups#!topicsearchin/play-framework/play$202.0/play-framework/822TVJ8ovx8

Oh... there have been plenty of heated discussions about Lift and the choices in Lift.

Lift has also migrated across designs over the years. We started with pure XHMTL and Helpers.bind() and have migrated to Html5 and CSS Selector Transforms (this still confuses people as the Html5 parser isn't kind to stuff like: <lift:foo/>

I think the core design decisions the Play guys made are wrong (MVC, faux stateless, ignoring security). But that's different from the "we learned a ton of lessons in Play 1.x and are applying those lessons to a new language in Play 2.0."

Also, you'll see some of that "I don't like this new direction" stuff with Lift 3.0... in fact I predict that Andreas (an extremely solid and together developer and Lift committer) will give a lot of feedback on Lift 3.0.

Thanks.

 

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

[Luis Ángel Vicente Sánchez]

Ehm... you should read the whole thread before saying that. The origin of that thread is that java people didn't like play 2 moved towards scala... they want java as first class citizen and scala as an option.

On 18 Oct 2012 21:30, "Kevin Lau" <kevin...@gmail.com> wrote:

I never saw a complain like this from Lift-framework. It only implies Play has major development issue to meet their community wants.

https://groups.google.com/forum/?fromgroups#!topicsearchin/play-framework/play$202.0/play-framework/822TVJ8ovx8

--

[David Pollak]

On Thu, Nov 29, 2012 at 12:38 PM, Eran Medan <ehrann...@gmail.com> wrote:

First, thanks for creating it! congratulations on Foursquare and Openstudy, I got personal recommendations on Lift from Chris

So I tried researching to learn why didn't TypeSafe chose Lift and went for Play instead, and found no clear information 

They invited me to make Lift part of the TypeSafe stack on two occasions and I declined on both. Those are the facts. The reasons behind the facts are not for public discussion.

 

Are you in touch with Martin / TypeSafe? are you in good terms? do you collaborate? Is Lift going to be one day "endorsed" by them? 

Not if I have anything to do with it.

 

Also, do you have more concrete examples on what Lift has but play hasn't?

What is missing from http://seventhings.liftweb.net ? It's a list of 7 things that Lift has that Play and most other frameworks don't.

 

I haven't found a thorough, unbiased article explaining it yet 

Thanks again for sharing Lift with the world, people forget it's open source and you don't owe anything to anyone... 

[William Billingsley]

First, I should of course say I have the greatest respect for both frameworks, and the tremendous efforts their communities have put into open source software.  I do hope this is not treading on toes, but I thought it might be useful to share war stories in one of these threads...

I've written an interactive in-class teaching system, initially in Lift (which I very much enjoyed), but then transitioned it to Play. While others' milage will vary, I actually did end up finding Play to be a better fit for this app.

I think the major difference between the frameworks is that Lift provides ways of abstracting across the request-response cycle -- and some other conventional boundaries (it injects Javascript into HTML from Scala code in many places).  The upside is that there are some things it makes quite easy.  The downside, in my view, is that if you need to use or preserve those conventional boundaries, you may find you're not taking much advantage of what Lift brings to the table.

Play does not abstract across these boundaries, but focuses on working very neatly and efficiently with the common conventions of the web. WebSockets, Iteratees, out-of-the-box CoffeeScript integration, compiler-checked-templates, etc, are among the various offerings that Play advertises

In my case, I found Lift's habit of abstracting across conventional boundaries to be a bit of a blind alley as as my very interactive app grew -- as features were added, there was an increasing need to move RequestVar state to explicit client state. I also hit a number of edge cases around RequestVars, CometActors and other Lift abstractions at the time.  As the client became more stateful, and largely rendered by d3.js, Lift's "seven things" advantages were less compelling.  Play, with good support for CoffeeScript, WebSockets, Iteratees, etc, became a very simple neat fit.

[David Pollak]

Thanks for the feedback, but I think you misunderstand Lift and probably misused the Lift abstractions.

I could debate point-by-point, but I think the following two experiences (along with the sbt coffeescript plugin) pretty much refute your experience:

When I was working on Innovation Games, we had one game (Buy a Feature) that was mostly server state and the server then pushed redraw commands to the client based on state change. We then got a Flash front-end for Buy a Feature (mostly client stateful) and had to rework the CometActor to push data and data deltas if the client was flash but still continue to push redraw commands if the client was HTML (and the client detection was done at runtime). It was about a day's worth of work to implement the changes... and this was before case classes with copy() methods and before lift-json so most of the work was hand-serializing and hand-diffing the case classes that represented state.

When I sat down to do Cappuccino integration (http://frothy.liftweb.net/), it took a few days. Once again, Lift's abstractions helped because asynchronous messages on the server side were simply reified on the client. And asynchronous messages on the client side were simply reified on the server without concern with the transport mechanism. And in both cases, the transport was invisible to the Objective-J code.

I'm not sure where you went wrong with Lift, but you could have wrapped Iteratees around CometActors (we haven't because the world doesn't need yet another Scala Iteratee implementation and Lift 2.x has to support Scala 2.8 and 2.9) in an afternoon or less.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

[David Pollak]

One more comment... Lift is to MVC frameworks as Scala is to OO languages.

The approach is different and for those who get the differences, they can be far more productive. Some people don't get the differences and view the new paradigm as somehow broken. It took me 2+ years to get into the FP side of Scala and it wasn't until I finished writing Beginning Scala that I fully grokked Scala. The Lift learning curve is no different.

[William Billingsley]

Thanks for the response - I hadn't expected anyone to take the time to reply, but perhaps just a few more people like myself to post their comparative experiences.  

Oh, my description of Lift is close to a paraphrase of the overview page on liftweb.net ("Lift at its core seeks to abstract away the HTTP request/response cycle"). Of course I'm happy to take your word for it if I was indeed wrong and that's not a core intent of Lift, but if so it might be worth rewording the overview page.

cheers,

Will

PS. I think you mistook "... are among the various offerings that Play advertises" for suggesting these are things you can't do with sbt CoffeeScript plugins or in other ways in Lift. It wasn't, it's just backing up my take on where their focus lies by examples of some features they advertise.  And if I gave the impression that I'd got stuck in the Lift development, no I hadn't. The next version was a rewrite of the web portion as I iterated on the use case anyway.

[Naftoli Gugenheim]

On Wed, Jan 9, 2013 at 3:24 AM, William Billingsley <wbilli...@cantab.net> wrote:

Thanks for the response - I hadn't expected anyone to take the time to reply, but perhaps just a few more people like myself to post their comparative experiences.  

Oh, my description of Lift is close to a paraphrase of the overview page on liftweb.net ("Lift at its core seeks to abstract away the HTTP request/response cycle"). Of course I'm happy to take your word for it if I was indeed wrong and that's not a core intent of Lift, but if so it might be worth rewording the overview page.

It is a core intent. You haven't really explained how that can be a liability.

cheers,

Will

PS. I think you mistook "... are among the various offerings that Play advertises" for suggesting these are things you can't do with sbt CoffeeScript plugins or in other ways in Lift. It wasn't, it's just backing up my take on where their focus lies by examples of some features they advertise.  And if I gave the impression that I'd got stuck in the Lift development, no I hadn't. The next version was a rewrite of the web portion as I iterated on the use case anyway.