David Pollak on lift and Scala
lift is an expressive and elegant framework for writing web applications. lift stresses the importance of security, maintainability, scalability and performance, while allowing for high levels of developer productivity.
lift 0.6 brings the following exciting new and enhanced features:
- Scala 2.7.0 support (which means that you can once again use Eclipse to develop lift apps)
- Localization of core lift classes (Thanks Marius)
- Enhancements to Redirect support
- Cookie support (rather than using underlying Servlet cookie support)
- Enhancements to Prepared Statements
- Significant enhancements to JSON support and client-side HTML generation
- Improved tests and documentation (thanks Eric)
InfoQ took the opportunity to ask David about some of the motivations that lead him to develop lift, as well as his experiences with Scala to date.
Can you give us some background on your experiences that led to developing lift?
I had done 18 months of Rails and 10 years of Java development. Rails was a fresh perspective on web development... common tasks were the "short path" items. It was great. However, I found that Ruby's dynamic typing led to a lot of errors and the requirement for 95% test coverage in order to have reasonable deployments. Unfortunately, to get 95% test coverage, my code size (including tests) ballooned to near Java sizes. Additionally, because Rails "changes things" (it has different methods that it dynamically changes) between development, test, and deployment, even with excellent test coverage, there were frequent deployment mishaps. The above problems intersected with the MRI Ruby implementation being slow and unstable and a development community that didn't care, I decided to "look elsewhere." I stumbled across Scala and instantly realized it was what I was looking for. Scala has all the language features that I like in Ruby and all the language features I like in Java. It was a "you've got your peanut butter in my chocolate" moment for me.
What makes Scala a great environment to build a web framework in?
Syntax. Performance. Stability. An excellent type system that's only there when you need it. Closures. Pattern Matching. Built in XML literals. Actors. It's hard to decide.
What would you say differentiates lift from Rails, Seaside or Java frameworks such as Struts or Spring MVC?
As easy and concise as Rails.
As secure and stateful as Seaside and Wicket.
Type-safe yet not hyper-verbose unlike Struts.
Better Comet support than any other web framework.
Support for "real time" application that allow many people to collaborate.
So, you can build wicked powerful apps wicked fast (just like Rails.) But you don't have the issue of shovelling all your state into a relational database. The state is "live" not freeze-dried and that makes a huge difference for writing apps that go beyond front ends to database tables.
Can you describe your experiences deploying lift in a production environment? What sort of performance are you seeing?
I've done a fair amount of benchmarking lift applications. The lift render pipeline is short and sweet and lift runs on standard web containers. This means that you get similar performance to well written J2EE apps. For non-database pages, lift typically has sub 1ms render time. For pages that require hitting the database, page render times are related to db access. On an Amazon EC2 instance (1.7Ghz Intel processor with 2GB of RAM), I was able to sustain 500+ pages per second and 50% of those pages had DB access and the MySQL instance was running on the same box.
How do you see lift working with existing Java applications, or in mixed language environments (e.g. JRuby)?
lift works very well with existing Java code. lift's RabbitMQ and XMPP support is based on Java libraries. Scala calling Java code is 100% seamless. Scala implementing Java interfaces and subclassing Java classes is 100% seamless. It just works. There's at least 1 lift project that's lift and Spring co-existing in the same WAR file. My first Scala app was a Servlet container. I was so blown away that "it just worked."
Ian Culling, Andy Powell & Lee Cunningham Dec 11, 2013