[tych0]

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

[jfim]

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

[shadowfiend]

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.

[jfim]

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/

[shadowfiend]

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.