21–30 of 46 posts
Many of the same advantages (and some additional ones, no doubt) hold for the Haskell web frameworks, with the added benefit of using Haskell. I'm in no position to say whether Yesod or Lift is better; I just wish more people would consider Haskell at all--it's a great choice for web programming (among many other things).
Regardless of the technical qualities of Lift, its future is pretty uncertain with 1) dpp leaving the project (in pretty bad terms) a few months ago and 2) Typesafe choosing Play over Lift for its stack. I would definitely not pick Lift today for a new project.
as to why typesafe chose play over lift: they wanted to go with lift but dpp didn't want to work with them - didnt think it a wise decision. his explanation: http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel...
Earlier quoted context omitted.
Came here to say the same. At least they should detect a scroll wheel click and open the link in a new tab. Or they could use the google approach and change the link in the last moment to point to a tracking service.
One more with the same problem. Right click open in a new window, and then 3 tabs with about:blank. That is also because using lift?
Just obnoxious.
Regardless of the technical qualities of Lift, its future is pretty uncertain with 1) dpp leaving the project (in pretty bad terms) a few months ago and 2) Typesafe choosing Play over Lift for its stack. I would definitely not pick Lift today for a new project.
dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. as to why typesafe chose play over lift: they wanted to go with lift but dpp didn't want to work with them - didnt think it a wise decision. his explanation: http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel...
I tried to like Lift, but it's so woefully documented that I can't. At the moment I've gone back to Wicket (which is fantastic on many of these, particularly building a page out of component objects rather than bunging lots of stuff in a page controller, and has an even better way of doing bindings than lift does), even though it doesn't fit perfectly with Scala.
The sever side statefulness of Lift, the fact that it supposes I don't know how to program HTML/JavaScript, and the hostility toward Scala that Lift's creator harbors since negotiations with him joining Typesafe broke down, are all reasons I think it would behoove anyone to avoid the framework. Play, unfiltered, scalatra, and blue eyes are all fantastic
> The sever side statefulness of Lift Having been using lift professionally for the last year or so, this is definitely my biggest complaint. I feel like Lift got it wrong here -- the *Var model is just hard to reason about. Our app has a lot of complicated logic to save and restore state at the appropriate times, and this model is supposedly the Right Way to do things. > the fact that it supposes I don't know how to…
I was reticent about statefulness on the server-side, until I read an article about statefulness in Lift[1], which does mention how having session affinity helps with it.
Mostly, my questions are: does it scale and how do you handle state loss (due to servers catching on fire or other hardware/software failures)?
Earlier quoted context omitted.
> The sever side statefulness of Lift Having been using lift professionally for the last year or so, this is definitely my biggest complaint. I feel like Lift got it wrong here -- the *Var model is just hard to reason about. Our app has a lot of complicated logic to save and restore state at the appropriate times, and this model is supposedly the Right Way to do things. > the fact that it supposes I don't know how to…
Can you elaborate a little more on the server-side statefulness of Lift and the issues you encountered? I was reticent about statefulness on the server-side, until I read an article about statefulness in Lift[1], which does mention how having session affinity helps with it. Mostly, my questions are: does it scale and how do you handle state loss (due to servers catching on fire or other hardware/software failures)? […
However, I'm still working through the conceptual aspects of restoring a page without a reload, over AJAX, provided I can figure out a good way to do it without compromising Lift's basic built-in XSS resistance.
The sever side statefulness of Lift, the fact that it supposes I don't know how to program HTML/JavaScript, and the hostility toward Scala that Lift's creator harbors since negotiations with him joining Typesafe broke down, are all reasons I think it would behoove anyone to avoid the framework. Play, unfiltered, scalatra, and blue eyes are all fantastic
You state "the server side statefulness of Lift" as a reason it would behoove people to avoid Lift, without bothering to explain why that is a reason to avoid Lift (it isn't--see http://lift.la/blog/lift-state-and-scaling). You state the language "supposes [you] don't know how to program HTML/JS" again without explaining how that is the case (it isn't--I am very good at both, and have never felt as much freedom to use those skills unfettered by server side concerns as I have with Lift; that's anecdotal, but if you make some specific complaints, I'll be glad to address them). And last but not least, you argue that David is hostile towards Scala without providing a single shred of evidence to support your statement.
In the future, it would behoove you to provide evidence for your claims.
Regardless of the technical qualities of Lift, its future is pretty uncertain with 1) dpp leaving the project (in pretty bad terms) a few months ago and 2) Typesafe choosing Play over Lift for its stack. I would definitely not pick Lift today for a new project.
dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. as to why typesafe chose play over lift: they wanted to go with lift but dpp didn't want to work with them - didnt think it a wise decision. his explanation: http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel...
Well, this doesn't sound a lot better than him leaving the project.