1. Lift goes further in enabling convention over configuration for common AJAX tasks that are part of normal workflows, so there is less boilerplate to write.

1. Lift goes further in enabling convention over configuration for common AJAX tasks that are part of normal workflows, so there is less boilerplate to write. 2. Parallel rendering means you can move to a SOA where different components on the UI are served by different backend services. This can be great if you have a recommendation service, a shopping cart and main content areas that are all served by different systems that may have different performance characteristics.. It also parallelizes the loading of the different parts of the page, which should decrease page load time. 3. Is there good comet support in existing frameworks out of the box? How would you easily update a partial in a rendered page when an object changes in rails or django? With Lift, you can hook up the rendered page (and its events) to server-side Actors... without any boilerplate code. This helps the productivity of development and (AFAIK) is still a rare feature. 4. You do have complete control, it is merely a matter of style. Lift does more things server-side. 5. One of the differences is that you don't need to have "partials", which could be more designer-friendly. I agree that this isn't a huge win. 6. yep. 7. I don't think the "No Direct Object Reference" security principle is taken care of by any other major web framework. It is a pretty big win for security -- because all of your exposed ids are session-specific, whole classes of problems just "go away". I'm not saying that Lift is to Rails/Django what Rails/Django was to PHP, but it does have some interesting features that set it apart. Note: I have a bias.