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 <sahmed1...@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?
On Thu, Oct 18, 2012 at 1:29 PM, Kevin Lau <kevinyp...@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.
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.
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" <kevinyp...@gmail.com> wrote:
For me, working with Lift seems to make more sense - mainly due to 'View First' as opposed to 'MVC', as well as the general usability of its API and http abstraction.
Conversely Play! 2.x is an MVC framework which ships with some added conveniences glued together. The dev mode recompilation and hot reloading is nice, however as we would not be using most of the shipped libraries, and also using Scalate views instead of the Play! Scala html templates, the fact that it currently only ships as an sbt plugin which pulls in everything that we didn't need made it less attractive than the other arguably better (flexible) MVC frameworks mentioned above. In fact, as of Play! 2.0.3, I have not been able to incorporate a Play! project as a subproject in a standard sbt build. Even using a standard sbt project directory structure is a small pain!
Personally for most projects I would select Lift, followed by Unfiltered or Scalatra if looking for a lightweight MVC framework. Play! seems to be somewhere in between - wanting to be a good full stack web application framework, but providing essentially a good MVC component with some baggage. In fact despite coming from a Java only background the only possible reason to use Play! would be to start with a *mainly* Java app and migrate to a *mainly* Scala app, or possibly if I fell for the hype!
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 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? Also, do you have more concrete examples on what Lift has but play hasn'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...
> 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 <javascript:>>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?
On Thu, Nov 29, 2012 at 12:38 PM, Eran Medan <ehrann.meh...@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.
>> 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?
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.
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.
On Tue, Jan 8, 2013 at 4:05 AM, William Billingsley <wbillings...@cantab.net
> wrote:
> 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.
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.
On Tue, Jan 8, 2013 at 9:09 AM, David Pollak
<feeder.of.the.be...@gmail.com>wrote:
> 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.
> On Tue, Jan 8, 2013 at 4:05 AM, William Billingsley <
> wbillings...@cantab.net> wrote:
>> 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.
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.
On Wed, Jan 9, 2013 at 3:24 AM, William Billingsley <wbillings...@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.
> 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.
