Marketing is hard.  Creating concise messages is super hard.  Having 3 seconds to explain to someone why your product is better and then losing their attention is the way things work.

I've spent a lot of time working out why Lift is better than any other web framework.  I've boiled the list down to Seven Things:

1. Lazy Loading
2. Parallel page rendering
3. Comet and Ajax
4. Wiring -- declare interdepencies between page elements
5. Designer friendly templates
6. Wizard -- multipage input screens with full back-button support
7. Security

Each of the above taken in isolation is something that Lift does that few other web frameworks do (e.g., you can use JBoss Seam instead of Lift's Wizard) and Lift does each one better than any other web framework.  But taken together, they tell a compelling story about why Lift is different.

I've put together http://seventhings.liftweb.net as a way to not only list the Seven Things, but also to give code examples.  Even if you're not a Scala coder, you will be able to see the concise, elegant way that each of the seven things is expressed in Lift.

And as Lift becomes a polyglot framework, as Lift supports JRuby and Java and other languages, there will still be Seven Things that differentiate Lift from all other web frameworks.

I did parliamentary debate in college.  It was a pile of fun traveling to lots of schools in the north east, drinking beer, and debating with some wicked smart and funny people.  One of the things that struck me as strange was the phrase "the loyal opposition."  It was used repeatedly in the course of the debate and it always struck me as odd, but no more.

It's no secret that politics in the US has become much more openly divisive over the last 18 years (or perhaps politics in the US has returned to the divisiveness of the early 1900's).  Gone are the days when disagreements about policy are disagreements about what's doing best for our country.  These disagreements have taken on the tone of hatred and personal derision.  Works like Nazi, Fascist, and Socialist are bandied about casually... these words have taken the place of rational discourse on important policy issues.

As the leader of a community, I see how easily the conversation can deteriorate from a discussion of the issues and priorities into a discussion of personal attributes or particular skills (leadership, coding, etc.)  In order to make sure that the Lift community remains the kind of community that attracts and retains people who care about building great web-based apps, the kind of community that fosters innovation and creative problem solving, the kind of community that is nice to be part of, I've worked hard to ensure the civility of discussion on the Lift list.

Today, I am getting a little more formal about it... today is the beginning of the Loyal Opposition policy:

• Anyone is encouraged to disagree with anyone else about anything in Lift, but do it politely, do it about the policy (not the person stating the policy), and position your opposition in terms of making Lift better.
• Having the common goal of making Lift a better framework is great, but we will disagree on the priorities for achieving that goal.  Because Lift is open source, everyone is as capable as everyone else of making the changes and enhancements in Lift that they think are the top priorities.  Put concretely, if you think something can be done better than the current committers are doing it, you go off and show us.  Write a feature.  Write documentation.  Write a style guide.  Everyone in the community is just as capable as everyone else at impacting priorities by rolling up their sleeves and demonstrating those priorities.  As a corollary to this, if you roll up your sleeves, work hard and don't succeed, be polite to the people that do succeed.  If you roll up your sleeves and mostly succeed, but need a little extra help, you will certainly find it in this community.
  
• If a community member chooses not to roll up their sleeves, then they are asking someone else to do work for them on an unpaid basis.  Please be extra polite when you make these kinds of requests.  If you want someone to change their priorities for you, but you're not willing to put in the time beyond making the request, then frame your request in a way that's likely to maximize the other person's understanding of why your request should change the "doers" priorities.  This includes saying "please."  This includes discussing your project's goals and priorities.  Making global statements, however, does not help advance your position (e.g., bad: "having lots of choices makes Lift hard for newbies to understand", good: "having lots of choices made Lift hard for our 3 new engineers to understand").

In the discourse about Lift and the committer priorities, please keep focused on the goal: making Lift better... better for you and better for a broad and broader audience.  You are encouraged to respectful disagree.  You are encouraged to point out where you see room for improvement in Lift.  You are encouraged to share your perspectives.  But please keep in mind that there are 2,500 perspectives on the Lift mailing list.  Some may be aligned with yours and some may be 180 degrees different.  Your best bet to get your perspectives into reality is to do it yourself.  Lacking that, being polite and positive is your best alternative.

So, please keep in mind that in order to be the Loyal Opposition, part of the group that disagrees with the current direction or some of the current choices, it's your job to keep the discussion civil and about the core issues from your perspective.

Last week, I had a bunch of really excellent conversations with folks about Lift, Scala, fabric computing, scalable storage, etc.  One of the big take-aways from the conversation was that any system, web framework, fabric computing infrastructure, etc. cannot be Scala-only.  While Scala is a tremendously powerful and excellent language, it is too much of barrier to entry for many folks to switch to Scala just to adopt the likes of Lift.

With those ideas rumbling around in my brain, I had coffee with @KirinDave and the San Francisco BankSimple folks.  Our conversation quickly traversed 5 different languages.  The BankSimple folks are clearly top 1% developers and they are a polyglot shot... they choose the best language for the particular task.  Following the coffee, I got a a conference call with one of my clients (my first non-Scala project in over 2 years.)  During the call, it struck me light a bolt of lightening... it'll be 10+ years before the mainstream corporate developers (and they are the ones with money) adopt Scala... they're currently swallowing Ruby and having a not-great time of it.

I realized Lift had to broaden outside of Scala.

I went home and did a quick research spike on Lift to see how hard it would be to make Lift easily usable from Java.  Well, Lift is marginally usable from Java, but the code is, well, ugly Java code.  Once Java8 supports lambdas, using Lift from Java will be cleaner.

Next, I did a quick research spike in JRuby... and holy cow, with the exception of a few things (symbolic method names, singletons, implicit parameters/CanBuildFrom, and var-args) Lift is reasonably usable from JRuby (except for pattern matching... but we'll get to that issue in a minute).

I spent the last few days working on the JRuby codebase to address the above list of issues and I'm about half way done (see https://github.com/jruby/jruby/tree/scala )

I've also recruited a most awesome hard-core Ruby/Rails developers (Aaron Blohowiak http://twitter.com/#!/aaronblohowiak ) to help design the Lift Ruby APIs... because they have to be different from the Lift Scala APIs.  And where Lift uses a lot of Scala's pattern matching, we will work on a Ruby DSL to achieve the same thing, except in the Ruby Way.

To pro-actively answer some questions:

• No, Lift is not abandoning Scala... the core parts of Lift will always be written in Scala... it's my favorite language and it's a powerful language for expressing the kind of semantics that have made Lift powerful and different.
  
• Why would someone use Lift with JRuby when they can use Rails?  Lift is hands-down the best web framework available today.  It's got better semantics for Comet and Ajax than any other web framework.  It's more secure by default than most other web frameworks.  Lift-based apps scale nicely.  Lift apps are more concise than most other web apps.  Put another way, if you're a Ruby developer looking for a more secure, more scalable web framework that allows you to build more interactive apps, Lift is it.
• What other languages will Lift support? Initially, it'll be JRuby... once we get the JRuby APIs nice and clean, we'll look around for the next language to support.  Maybe it'll be mainstream Java (if we can solve API issues like pattern matching in Ruby, maybe a better answer will come along for Java).  Maybe it'll be Clojure.  But whatever the next language on the Lift polyglot tour, it'll feel native to that language (even if that means annotations in Java... gaaakkk).
• Will this derail the Lift documentation efforts?  No, just the opposite, as we work through the APIs, I plan to document them much more cleanly.

So, what needs to be done on the Lift side to support JRuby:

1. Snippets — invoking a Ruby script
2. Support for box/option (this may be as simple as making Box implement java.lang.Iterable)
   
3. S, SHtml, LiftRules
4. Boot
5. SiteMap
6. SessionVar/Vars
7. Helpers
8. CSS Selector Transforms
9. Alternative to pattern matching

The above is the list of the key parts of Lift that we have to build nice Ruby APIs for.

I look forward to broadening Lift's reach and making the power of Lift available to a broader and broader audience.  I look forward to the Lift community welcoming folks outside the core Scala community.

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 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
• Designer-friendly templates
• Stateless renderingincluding the HTML pipeline
• Support for MVC-style development

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

This is the sixth release candidate in the 2.2-RC* series.

All going well, this would possibly be the last RC before the final Lift 2.2 ships. Unless community testing reveals any serious bug that gets identified, that is.
Looking forward to an awesome Lift 2.2 final later this week!

Thank you, have fun, look forward to a great 2011!
- The Lift team