Lift Web Framework is Easy

It's ubiquituously said that the Lift web framework has a steep learning curve.  Hard to believe when

<div class="lift:surround?with=default;at=content" id="real_content">
 <h1>Welcome to your project!</h1>
 <lift:Hello.world />  
</div>

object Hello extends DispatchSnippet {
 val dispatch: DispatchIt = {
  case name => render(name) _
 }
 def render(name: String)(ignore: NodeSeq): NodeSeq = Text("Hello, " + name)
}

LiftRules.snippetDispatch.append {
 case "Hello" => id.openfx.openshop.snippet.Hello
}

simply wraps the page with the template 'default.html' and makes a snippet Hello.world lookup.

Everything in Lift is easy and transparent, I daresay. Most things can be reasoned as you write code, instead of having to read its specification. I can't quite describe it precisely, but I'll give it a shot anyway. Because Scala allows "mix in" of traits, there is, CMIIW, no hidden container-managed proxy code is needed. Let's compare this with CDI used in the JSF framework. To cater to different scopes, a CDI bean can be annotated with @RequestScoped, @SessionScoped, @ConversationScoped, etc. How does it look like when constructed? Honestly I don't know. I only know how it should work thanks to the CDI spec's documentation. But I think the container would have to create a specific proxy for each bean depending on its scope, and inject its proxy dependencies and so on. The proxy might also be different when you add @Stateful to, say, a @ConversationScoped bean.

On the other hand, in Lift, it's much simpler. Snippets are normal methods registered via the LiftRules object during boot. Request and session states are just plain objects extending either RequestVar or SessionVar, used directly by snippets. The separation between controller logic and session/request data is clear here. You know what's happening to your stuff by checking out what's inside what you're extending.