Comments on: First impressions of Lift Scala web development framework from a Ruby on Rails developer

By: Eric P

Eric P — Mon, 05 Apr 2010 01:43:31 +0000

My first impression coming from Spring MVC, Grails and Rails is this: Lift is a mess. I don’t think it’s fixable. It may be faster than (G)Rails but speed is not everything.

By: Teena George

Teena George — Mon, 21 Dec 2009 16:58:34 +0000

Ikai, Looking forward to your next series in lift.

Regards,

Teena

By: Philip

Philip — Fri, 20 Nov 2009 14:30:31 +0000

Came across this website after getting frustrated with the Lift framework. I couldn’t agree more with what you have written.

I tried Lift after looking at Apache Click, Apache Wicket, Sprite and a few other frameworks. Lift is, by far, the most (needlessly) complicated framework I have come across.

Perhaps I am stupid, but I had a very difficult time with the documentation.

Lift has such promise – scala is so much faster than Ruby, Groovy etc.. and Lift should have become a dominant framework now (more so that Grails, Rails etc). But the needless complexity due to the fact that the developers have chosen to NOT emphasise simplicity over “cleverness” has resulted in Lift finding very few takers as compared to (G)rails.

I especially liked the line “Sometimes there really is such a thing as too clever.” So true.

By: rickcr

rickcr — Sat, 27 Jun 2009 02:00:05 +0000

Thanks for this write-up. I’m curious, have any of your positions changed since your initial post?

I’m debating about sticking to Groovy & Stripes for a midtier webapplication, or maybe giving Lift a go.

You’re bullet point on “everything relies on state” worries me a bit.

By: Jacklee

Jacklee — Mon, 01 Jun 2009 11:36:34 +0000

I’d hire you in a minute, Aaron Carlino, if I could come up with the money and had the authority. If our college ever loses its current Webmaster or Graphic Arts Specialist, I feel you would be able to do both jobs….amazing talent and time manager. Now, don’t forget about the life balance factor…..enjoy!

By: Rich Apodaca

Rich Apodaca — Fri, 03 Apr 2009 16:19:19 +0000

Ikai, I look forward to the series – it’s a great idea. On the plus side, it looks like at least one Lift book is close to publication:

http://www.apress.com/book/view/1430224215

By: David Pollak

David Pollak — Wed, 04 Mar 2009 14:22:03 +0000

Ikai,

Perhaps the lack of documentation has colored your perspective on SiteMap (the whole Menu, Loc thing).

SiteMap is optional, so you can remove it from your code and manually manage access control to pages and generation of menus and bread-crumbs.

I wrote SiteMap (first for Java https://www.lostlake.org/sitemap.wmv , then for Ruby http://rubyforge.org/projects/sitemap/, now for Lift) because almost every site I ever worked on had dynamic menus and page-level access control rules.

SiteMap encapsulates the following features:
- Dynamic page level access control You define the access control rules as part of the Loc[action] and it can include current state (is the user logged in or not, is the user a super-user) as well as testing to make sure that the request has certain parameters and that the parameters are valid
- Hierarchical (nested) menu support. So you can have sections, subsections, sub-sub sections, etc.
- Page aware menu display. Only the pages that you’re allowed to access will be displayed. For nested menus, you’re shown menus at the levels above you, at the current level, and the menus in the nest just below you (see http://demo.liftweb.net/menu/two )
- Breadcrumbs… the menu nesting that got you to your current page
- URL rewrite and parameter extraction. This is like routes in other systems, but with SiteMap, the parameter extraction is type-safe and is bi-directional so that you can construct URLs from type-safe data, also using SiteMap. Note that you can do the URL rewriting (routing) separately using a lighter weight pattern matching syntax as well… which also reinforces that SiteMap is optional.
- Page title generation
- A few other things that escape me right now. :-)

The “dpp practice” (I won’t call it best practice because my conventions are not always best) is to put Menu/Loc definitions into a domain object singleton and assemble the menus in Boot.scala. You can see this with User.menus. And, if you don’t like Scala’s :: for List item concatenation, there are other ways to build Lists.

Thanks,

David