Lift

It's a polyglot world after all January 11, 2011

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.