Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

Interview With Lift Creator - On Foursquare, Scala, and Lift 2.0

  • submit to reddit
Lift is a powerful web framework for Java developers, and more notably one of the few web frameworks for Scala.  Both Lift and Scala have experienced significant growth at major web properties.  You may know that Twitter has changed some of its backend to Scala and Foursquare has rolled its whole website onto Lift.  With the impending release of Lift 2.0, DZone contacted David Pollak, the creator of Lift, to talk about Scala, web development, Foursquare, and what to expect in Lift 2.0

DZone:  Tell me about some of the major new features coming in Lift 2.0.  When can we expect the beta; the final release?

David Pollak:  Lift 2.0 is radically more developer friendly.  The error messages in development mode are much better.

Lift 2.0 contains the Lift JSON package which is high performance and does amazing things serializing Scala's case classses so developers don't need to write any bridge code to serialize/deserialize case classes to/from JSON and XML.

Lift 2.0 contains "Wizard," which is a pure declarative DSL for creating stateful, multi-screen inputs.

Other Lift 2.0 features include CouchDB support, OAuth support (thanks to our friends from FourSquare), OSGi support, LDAP support and much more.
DZone:  Foursquare recently shifted their website on to Lift.  Can you tell us a few of your thoughts and experiences surrounding that high-profile use case?

David:  Yeah... it's a wild experience.  All of a sudden, FourSquare is getting a lot of press, etc.  Then I get a note from HarryH that goes something like, "you know how you say that you prioritize issues for production sites... well, I'm from FourSquare, we're using Lift and we've got a couple of open tickets we'd like to get prioritized."  I read that message... then I got a rubber band and used it to keep my jaw from hitting the keyboard... then I got real scared... I mean what if there were scaling problems with Lift and FourSquare turned into a disaster.  It's been a great experience to work with @HarryH and his team.

Interestingly, Novell and their Pulse product are also built on Lift.  The demos I've seen have blown my mind in the "Geez... you can really do that with Lift... WOW!"

I still get nervous from time to time (especially when one of the FourSquare or Pulse guys IMs me with something that that starts off, "Is this supposed to happen this way?"), but in general, it's cool having smart, fun folks building excellent stuff for a broad audience.

DZone:  In your opinion, what's the most interesting and relevant storyline in the Scala ecosystem right now?

David:  The number of people who know about Scala is the biggest story.  Three years ago, I had to do the Scala elevator pitch to most Java and Ruby coders I spoke with.  These days, most professional developers know that Scala exists, that it runs on the JVM, and that it's a functional language.

While technically, this is outside of the Scala ecosystem, it indicates that Scala has entered mainstream developer parlance, unlike Lua or even Go.

DZone:  What changes do you hope to see for the Scala language and ecosystem in the next 2-3 years?

David:  I think 2.8 has just scratched the surface of what can be done with higher kinded types and implicits.  I think that there are a number of places that Scala can grow to give library authors more flexibility to deliver libraries that look and feel more like dynamic language libraries.

In terms of the ecosystem, the biggest thing I see is Scala consultancies popping up and some of the larger consulting shops starting to practice Scala.  Ultimately, no language can reach mainstream until you can find an arbitrary number of coders, otherwise the risk of using the language is too great. 

DZone:  Why might someone with Java and Scala skills use Lift instead of one of the many Java web frameworks available?

David:  Lift is more secure than any other framework I've used.  For example, one of the top security experts wrote this about FourSquare.

  • Lift has better support for Comet than any other web framework... and that's why Novell chose Lift for the Pulse front-end.
  • Lift has excellent Ajax support.
  • Lift is persistence agnostic, so it works with your existing Java model objects and business logic.
  • Lift's REST support is far more flexible and secure than REST support in any other JVM web framework.

DZone:  You've tried to bring some of the features from successful frameworks like Django, Wicket, and Rails to the Lift Framework.  If you had to choose one web framework, besides Lift, for building a wide range of web applications and websites, which would you use?

DavidSeaside is far and away my favorite non-Lift web framework.  Avi did a tremendous job with it.  The only downside to Seaside in my mind is the Squeak runtime.  But if it weren't for the deployment challenges with Squeak, I might never have started Lift.

DZone:  Is there anything else you'd like to mention?

David:  Yeah, the Lift community and the Lift committers are a joy to be around.  They're just a wicked cool bunch of people.  It's great to wake up in the morning to the kind of conversations that go on in Lift-land the the kind of creativity and pure energy in the community.  It's a place that I really enjoy hanging out and I'm really psyched that so many cool people have gravitated into the Lift community.



Daniel Spiewak replied on Mon, 2010/05/03 - 4:36am

As one of the "Pulse guys", I'd like to corroborate what he said about the Comet stuff. Lift's support for Comet is absolutely fantastic.  There are things about the framework that I'm not as fond of, but the Comet support is very innovative.  The basic model is that every Comet-enabled client has a corresponding Actor instance on the server (remember, actors != threads, so we can support conceivably millions of clients without running into problems in this mechanism).

The advantage to this is you have something to "hang your hat on".  There's a real entity modeling remote browsers that you can work with and implement just like any other actor.  Having now gotten used to this way of doing things, I find it hard to even understand the Comet support in other frameworks.  (note: some other frameworks, like Akka, have taken inspiration from Lift's CometActor(s) and are also modeling Comet support in this way)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.