> Further, this book will not explore persistence.
To me this is one of the more important parts of a web framework. Otherwise, they all provide similar features for organizing code: you link some sort of a "view" to some sort of a URL. They may add a template language, or an admin system or a caching framework. They may be event-loop based, or process based or thread based or some mixture of all of the above, but if you have no state, your code will look awesome in all of them. The big issue is "how do you deal with state?"
Persistence IMHO doesn't have to be a very important feature in a framework, since a good one should be able to be pluggable. I use Django, but in some projects I don't use their ORM (or any ORM).
Your view is not a simple string template in Lift. In most frameworks, you handle the controller first, gather all your data and pass it to a string template. In Lift, the View is parsed and then all (there are frequently many) of the required "controllers" are invoked to fulfill the view. This is somewhat, kind-of, almost like custom tags in JSP, but about a thousand times keener, because it is all parallelized and so forth. Because of this, Lift can do things like trivially bind html to changing Actors (in the erlang sense) so that when the Actor changes, the html changes in all the browsers that viewed it.
Supporting this all is non-trivial. "Persistence" usually boils down to serialize, deserialize and transactions... which are ultimately not unique to Lift, so I don't see a huge need to focus on it.
It looks like less than half of the tutorial is written, it's mostly an outline.
I saw something about guids halfway through the article which scares the pants off of me. Guids are a major part of the evil of Windows programming; the proliferation of opaque identifiers makes it hard to understand what you're looking at. Worse than that, some programmers are tempted to make up their own guids rather than making them the way you're supposed to make them... I eventually quit working at a place where there was this old guy who'd start screaming and turn red because I told him that
var guid=new Guid("0000-...");
was't a guid because it wasn't globally unique.
Guids certainly have a place in distributed systems, but oversized keys can really destroy the performance of a database, quite literally by a factor of 5 or more. They're great for hardware vendors that want to sell you an oversized machine, great for expensive enterprise apps and clunky intranets where you can complain about a page taking 20 seconds to load but but nobody listens, but not acceptable for internet apps that have to compete for time and attention.
UUIDs have great characteristics as well: they don't leak information about the size of your data (or the rate it changes,) they are easily masked, you can have clients generate stable ids (which you hint at in distributed systems.) The db performance degradations you mention are highly implementation-dependent.
It's also worth noting that GUIDs in this case have nothing to do with persistence but rather with associating urls with behaviour in much the same way as the fnids you'll see on various urls (like flag) on hacker news.
I spent a few minutes trying to figure out what Lift is but didn't get enough information scent from the introduction to persevere. I did pick up that Lift is not too interested in solving any persistence problems.
For what I'm working on (multiplayer, offline/online web application) persistence has taken the most work to get right. It has to be done at the framework level. An offline web app has to deal with synchronization (backporting of data, client-side data loss or corruption, client-side clock issues, GBs of data per user, multiple users sharing the same data), client-side and server-side migrations (code, data, schema), browser-side database (indexing, memory usage) etc.
Partition-tolerant persistence is almost exactly what I'd want a web app framework (as opposed to web site framework) to be tackling. I'm not aware of any frameworks (including Backbone, Lift, Rails etc.) that do.
I think that this is common to any expressive language in a business setting. Small, expressive code is easier to read/write/maintain for the person who originally created it, as it matches their brain and way of thinking. However, once you encounter an ever-changing set of people who may want to consume or modify your code, you need to give people a look into how your mind works. Narratives are often much longer than normal quick remarks in comments.
Furthermore, this source is intended for educating :-)
Scala code is more verbose than Haskell or Scheme but its still pretty terse for many things, so you tend to get much more done with much less code (especially if you compare it to Java).
To me this is one of the more important parts of a web framework. Otherwise, they all provide similar features for organizing code: you link some sort of a "view" to some sort of a URL. They may add a template language, or an admin system or a caching framework. They may be event-loop based, or process based or thread based or some mixture of all of the above, but if you have no state, your code will look awesome in all of them. The big issue is "how do you deal with state?"