Over the last few weeks, I've had some really excellent interactions with Lift users, some on the Lift list and some privately (mainly because Lift users were exchanging proprietary code with me.)

We all want to improve Lift.  We use it, we give feedback, and we improve Lift... the code base, the documentation and most importantly, the Lift community.  The Lift community's primary point for interaction is the Lift Google group: https://groups.google.com/forum/#!forum/liftweb  That's the best place to ask questions, give feedback, learn and stay connected with the other awesome folks who make up the community.

Recently, a Lift user sent what I consider to be the prototypically ideal request for help: https://groups.google.com/d/topic/liftweb/KNhdu-IqVy4/discussion

He had a non-trivial task that was some Scala and some Lift.  He framed his question by clearly stating his goal.  He put together an example project and posted his question.  He took the extra time to frame his question in both words and code so that it was understandable.

I was able to look at his question, pull and run his project, and answer his question in about 20 minutes, and this is less time than it typically takes me to read and respond to much more trivial questions.  The Lift community now has another example of taking non-trivial data and mapping it into a display.  Thanks Diego.

Another excellent interaction came from Bufferine: https://groups.google.com/d/topic/liftweb/E3ynTtW7fKM/discussion Her request was in the form of "when I apply this CSS Selector Transform, I expect both rules to apply, but only one rule is applied" along with a simple example.  Her post was also a clearly defined use case that underscored the value of the change she was asking for.  Her post led to an enhancement the way the CSS Selector Transforms work and helped evolve this feature in Lift.

Lift users have also shared the source of their projects with me so I can see how the whole project hangs together as well as seeing patterns in code that can be made more concise with APIs.  It's also an opportunity for me to see excellent coding styles and learn new Lift tricks myself.  If you have a Lift application in production and want to share the code with me, please contact me privately to show me how you've built a production app.

I highly these interactions because they are examples of folks interacting with the Lift community to make Lift better.

Further, asking questions helps you get answers, but also helps the whole community and the Lift committers learn about the challenges facing developers.  This allows us to:

• Improve documentation to highlight common usage patterns.
• Add new features that turn frequently used patterns into simpler patterns.

And if you ask a "how do I" question, you might learn a pattern that others developed that you might not otherwise see.

I also want to point out some mechanisms that are most likely not to get a desired result (a question being answered, an improvement to Lift):

• Tweeting about it.  Twitter is great for a lot of things, but if you've got a suggestion or improvement to Lift or a question, bring it to the Lift google group so the whole community can share in a rich discussion.
• Not answering a question posed in response to your question.  We may ask about the Lift version you're using, your operating system, JVM version, etc.  It turns out that these things often make a difference.  If you want help with something and the person volunteering to help asks a question in furtherance of answering your question, then please answer the question.  If you want help from someone, then helping them give you help will only make the process faster and easier.
• Not putting together example code when asked will pretty much disqualify you from getting an answer from me.  If you're going to push the work of putting together a running example onto me, then you're trading your time for my time and I'm already offering to give you my time for free.  Put another way, you're telling me that my volunteer time is worthless... and if it's worthless to you, then I won't spend any more on you.
• Copping an attitude.  This includes phrases like "Surely...." "Isn't it obvious..." "I said this once when we were at XXX together..."  Things may be obvious to you and maybe you'll be able to help the rest of the community to see why your approach is better than what's available now.  Further, when I'm on the road, I meet hundreds of people.  While I try to take notes about conversations, I will forget things.  So, unless we've discussed something on the Lift group and it results in a ticket being opened, please do not expect it to be part of Lift.

To put the above another way, we are working together to improve Lift.  We're all volunteering our time to the effort.  In order to maximize the value of our collective time and effort, there are mechanisms for communicating and for sharing the burden of making Lift itself and each Lift-based application the best that can be.

When you show that you think you question is important enough to write a little extra example code, the community will value giving you a better response more.  When you work a little harder, the whole community will work a little harder to help you.  When you're a little more polite, the community will be a little more polite.  But the opposite is also true.  So, let's all go the extra step to communicate in a way that improves the results for all of us.

This is the fourth release candidate in the 2.2-RC* series following up on Lift 2.2-RC1, Lift 2.2-RC2 and Lift 2.2-RC3.

We are getting even closer! And you know the drill -- please test this and help us identify bugs so that we can make the final Lift 2.2 awesome!

Thank you, have fun!
- The Lift team

This is the third release candidate in the 2.2-RC* series following up on Lift 2.2-RC1 and Lift 2.2-RC2.

We are getting close! Please test this and help us identify bugs so that we can make Lift 2.2 awesome!

Thank you, have fun!
- The Lift team

When I first caught wind of Matt Raible's spreadsheet comparing different web frameworks, I thought it was a joke.  I still do, but lots of people are taking it seriously (although, others aren't.)

Here are my ratings on Lift (and, yes I'm aware that Matt's scale is 0-1 and my ratings are on Matt's scale, except mine goes to 11).

Developer Productivity: Lift gets a 11, Rails gets a 5, most Java-based frameworks get a 1 or less.  A seasoned Lift developer will be 10 times more productive writing interactive web apps than with MVC frameworks. @HarryH from Foursquare explains part of it in his Lift presentation (see Slide 10).  With Lift, you don't worry about the plumbing, setting up routes, etc.  Thus, Ajax is much, much easier and Comet (server-push) is better than any other framework available.  Sure, writing a green-screen style CRUD app with Lift isn't a major win over other web frameworks, but when it comes to stuff that's hard or impossible in other web frameworks, Lift makes it someplace between super-easy and possible.  For more, see my screencast on building a comet chat app.

Developer Perception: Every web framework gets a 1.  The folks that have gravitated to the framework are going to love it and others are going to deride it.  Oh, and emacs is much better than vi.

Learning Curve: Lift gets a 2 here.  I've seen a number of reports on Lift vs. JSF2/Struts2/GWT/Flash/Spring MVC/Grails done internally by companies and government agencies looking to commit to web framework for various different long-running projects.  While Lift has not been chosen for all the projects, Lift has consistently come in first in terms of smallest lines of code and top developer ratings (and these are generally Java developers who have had prior experience with at least one of the other competing frameworks.)  So, repeatedly, big-business Java developers have been able to pick Lift up and deliver projects more efficiently than with competing technologies in shorter periods of time while learning the framework and the Scala language.  Put another way, one corporate Lift developer recently posted to the Lift list:

Project Health, yeah, Lift is an active and growing project.

Developer Availability, Lift gets a 0.5. Anybody who wants a Lift developer can find one, but probably not in their city.  There are plenty of folks who do Lift consulting if you have a project.

Job Trends, yep, it's zero.

Templating, here again, I've gotta say, Lift gets at least a 3, if not more.  Why?  Well, there are at least 3 different ways to template a Lift app.  You want to use Scalatewhich provides Mustache, Scaml (like Haml) and SSP (Velocity-like), you can use it with Lift.  Lift also supports using Scala XML literals so you can code your templates right in Scala.  Or, you can use Lift's snippet mechanism to have templates that cannot contain any business logic and are developer friendly.  So, for example, if we were to build a table using Lift's snippet mechanism, our view would look like:

And our Scala code would look like:

    val (fieldNames, fieldValues) = DB.runQuery(...)

​

    "#my_th *" #> fieldNames &

    "#my_tr *" #> fieldValues.map(values => "td *" #> values)

So, the designer inserts a "lift:MySnippet" class into an element that has dynamic behavior and the developer binds dynamic content via CSS selectors.  If you can find something that's more concise or more oriented to the way of the web, show it to me.  But I think this is hands-down the best templating system I've ever seen.

Components, Lift gets at least a 4.  Everything, and I mean, everything on a Lift page is a component.  Check out the Lift demo.  You've got 5 components on that page alone.  You've got the menu component and the messages component and the clock component (which updates every 10 seconds based on server push) and the chat component... and let's not forget the main content component.  What Lift doesn't have is something separate or different from Lift that is called a "component system."  Lift is not front-controller, so each snippet on the page is a component.  Each piece of dynamically rendered content is a component.  Yes, the components can interact (see Lift's wiring which allows you define relationships between components and update all dependent components automatically), or they can stand alone.  Lift is also based on Scala which is a functional language, so Lift's components are literally functions that transform template HTML to browser HTML.

Ajax, Lift gets a 5.  Lift's Ajax support (if you include Comet as part of Ajax) is worlds better than any other web framework.  No routing.  Tons of security.  Single lines of code to associate Ajax behavior with code.  Multiple comet components on a page, all sharing a single long poll connection (and yes, once web sockets are standardized, Lift will support them too, with no change in application code.)

Plugins or Add-Ons, I can agree that the number of plugins for Lift is smaller than other web frameworks.

Scalability, Lift scales extraordinarily well.  Foursquare is a prime example.  

Testing, What does this mean?  Does it mean Lift isn't well tested... I beg to differ.  Lift powers sites like Foursquare and Novell Vibe.  You can see the Lift tickets and find all the tickets opened by Novell and Foursquare... not a lot.

Validation, here again, Lift gets at least a 2.  Lift's Screen and Wizard have tremendously powerful validation.  For example: val name = field("Name", "", minLen(2, "Name too short")). 

Quality of document, here I'll give Lift a 0.5.  Lift's documentation is not as good as it could or should be.

REST Support (client and server), here, I'll give Lift a 2.  Lift's REST support is simple and declarative. It's also type-safe, composable (you can easily combine components of a REST service together because all of Lift's REST services are defined as Scala functions), and secure.

So, yes, I see Lift as far better than any other web framework.  This is by design.  I have taken the best ideas that I've found in many of the excellent web frameworks, but also taken the approach of turning the HTTP request/response cycle into plumbing that need only be exposed when your application needs it, otherwise the developer focuses on the business logic.  Lift provides the best Comet and Ajax support of any web framework.  Lift is the most secure web framework around.  And developers are very, very productive writing (and maintaining) Lift apps.

I can go on in greater depth about Lift's use of simple concepts like keeping the page around as well formed XML until it's time to stream it to the browser which radically enhances security and flexibility.  I could talk about the composition of functions as a much more manageable way to build any logic (basically, the promise of OO, except materialized differently.)  But at the end of the day, folks have adopted Lift, despite its differences and those that acknowledge its differences quickly become more productive with Lift than almost any other framework.  Those that embrace its differences change the world.

 

Lift features include:

• Community... the Lift community is 2,400 members strong, super-active and always there to help with questions
• Best Comet (server-push) support that allows the creation of dynamic application such as Novell Vibe
• Super simple Ajax for creating highly interactive web applications without worrying about HTTP plumbing
• Secure by default... Lift apps are resistant to the OWASP top 10 vulnerabilities including XSS, XSRF, and parameter tampering
• Concise and Maintainable... Lift apps typically contain fewer lines of code than corresponding Rails apps, yet are type safe so that many errors are flagged by the compiler
• Scalable... Lift apps scale to millions of users across many servers, yet are highly efficient for single-box implementations
• Compatible... Lift apps can take advantage of any Java library as well as the growing collection of Scala libraries

Lift 2.2-RC1 improvements include:

• HTML5 Support: Lift supports parsing HTML5 input files and rendering HTML5 to the browser in addition to Lift’s XHTML support
• Wiring: Spreadsheets meet web application yielding an automatic mechanism for updating dependent elements on a page, making it even easier to build dynamic apps with Lift
• Wizard and Screen Improvements: Build complex screens more easily with new helper methods for creating form elements and improved life-cycle callbacks
• CSS Selector Transforms Improvements: including appending attributes, multiple selectors applying to a single element, and element lifting
• Support for migratory sessions: ContainerVars provide type-safe, guaranteed serializable session variables that can migrate across application servers in a cluster
• Improved i18n: including per-page localization strings and localization strings and HTML stored in templates rather than Java resource files which makes editing much easier
• Security Improvements: including creation of new sessions on login
• MongoDB Improvements: performance improvements as well as new features
• Support for Scala 2.8.1 as well as 2.8.0 and 2.7.7
• ProtoUser support for Record: Lift’s ProtoUser and CRUDify can be used on Record-based persistence classes as well as Mapper-based persistence classes
• Squeryl integration improvements: Lift is updated to use the latest version of Squeryl

Lift-powered sites include:

• Foursquare: the multi-million user location based service that services millions of check-ins a day on their Lift-powered system
• Novell Vibe: enterprise collaboration software platform based on Google Wave
• Innovation Games: The fun way to do serious business — seriously
• Xerox/XMPie: the leading provider of software for cross-media, variable data one-to-one marketing
• Exchango: The easy and convenient way to give and get free stuff.
• Snapsort: Compare and decide on cameras
• No Fouls: Find pickup basketball games