Hacker News new | ask | show | jobs
by dwhitney 4849 days ago
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
2 comments

> 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 program HTML/JavaScript

Not sure why you say that; I've never gotten this feeling.

> the hostility toward Scala that Lift's creator harbors

Lift has 50 committers now. It's not going anywhere. If dickead maintainers were a real problem, nobody would be using glibc anymore. (I don't have any thoughts on whether DPP is a dickhead; I do think Drepper is, though :-)

One thing you didn't mention is the whole CssSel model combined with the way lift does templating. I think it's awesome, and hopefully I'll never have to work with another style of templating again in my life. (In fact, I wrote an implementation of it in haskell for my personal static site generator, because I love it so much: http://hackage.haskell.org/package/hquery </shamelessplug>).

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)?

[1] http://lift.la/lift-state-and-scaling

State loss is something I've been doing a great deal of thinking about. Right now a page reload is necessary, and I've written code in the past to essentially store any modified fields before running the page reload and restore them when the reload completes.

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.

I don't know much about how Lift works, but would doing something akin to PJAX[1] (reloading the entire page via AJAX) work in your case?

With regards to state loss, the only way I can see it working is if you save everything to a system of reference, just like you'd do in Play. Unfortunately, that's also a major pain in the ass, as we've found out, especially in the case of multi-step forms in Play.

[1] http://pjax.heroku.com/

But we have a system of reference in Lift—CSS selector transforms refer to an element by its location in the DOM, rather than by a given name. I think there's room there for a creative solution.
David doesn't seem to harbor any particular hostility towards Scala. As far as I can tell, he has serious qualms with certain aspects of the way that EPFL and now Typesafe run and have run the Scala community, and have managed the evolution of the language itself, but he loves the language nonetheless. Thus why he has sunk a great deal of time into the Lift community, into keeping it alive, into speaking about it, is currently sinking still more time into the next phases in Lift (Lift 3) and how to push the foundations that Lift 2 laid down even further with that, and why as far as I know it is still his language of choice for many projects, including telegram and Visi.

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.