Hi,
I know this question is a bit open but I have been looking at Scala/Lift as an alternative to Java/Spring and I am wonder what are the real advantages that Scala/Lift has over it. From my perspective and experience, Java Annotations and Spring really minimizes the amount of coding that you have to do for an application. Does Scala/Lift improve upon that?
Just for fun. And for the sake of learning new programming approaches.
Expanding your knowledge is always a worthwhile endeavor :) I just started learning Scala, it's affecting how I write normal Java and I can say it's been very beneficial so far.
I didn't come to Lift and Scala from a Java background, so this isn't from personal experience, but I know that many Lift developers find Scala to be a much more concise and efficient language than Java.
Scala/Spring is quite popular too, mind you. As for Lift, it is my impression that it has superior support for Comet stuff than Spring.
Let's assume we're equally comfortable in Scala and Java, and ignore the (huge) language differences except as they pertain to Spring or Lift.
Spring and Lift are almost diametrically opposed in terms of maturity and goals.
In a sentence, Spring is heavyweight and Lift is lightweight. With sufficient determination and resources you can turn that on its head, but you would need a lot of both.
Here are concrete differences that stuck in my mind after working with both frameworks. This isn't an exhaustive list, which I can't compile anyhow. Just what seemed most interesting to me...
View philosophy
Lift encourages placing some view material in snippet/action methods. Snippet code especially will be sprinkled with programmatically generated form elements, <div>s, <p>s, etc.
This is powerful and useful, especially since Scala has a builtin language-level XML mode. One can write XML inline within Scala methods, including variable bindings in braces. This can be delightful for very simple XML services or mockups of services -- you can bang out a suite of HTTP response actions all in one splendidly terse file, without templates or much attendant configuration. The downside is complexity. Depending on how far you go, there's either a fuzzy separation of concerns between view and logic, or no separation.
In contrast, regular use of Spring for webapps enforces a strong separation between the view and everything else. I think Spring supports several templating engines, but I've only used JSP in anything serious. Doing a Lift-inspired "fuzzy MVC" design with JSP would be madness. This is a good thing on larger projects, where the time to just read and understand can be overwhelming.
Object-Relational Mapper Choices
Lift's builtin ORM is "Mapper". There's an upcoming alternative called "Record", but I think it's still considered pre-alpha. The LiftWeb Book has sections on using both Mapper and JPA.
Lift's CRUDify feature, cool as it is, only works with Mapper (and not JPA).
Of course, Spring supports a panoply of standard and/or mature database technologies. The operative word there is "supports". Theoretically, you can use any Java ORM with Lift, since you can call arbitrary Java code from Scala. But Lift only really supports Mapper and (to a much lesser extent) JPA. Also, working with nontrivial Java code in Scala is currently not as seamless as one might like; using a Java ORM, you will probably find yourself either using both Java and Scala collections everywhere or converting all collections in and out of the Java components.
Configuration
Lift apps are configured pretty much entirely through a method an application-wide "Boot" class. In other words, the config is done through Scala code. This is perfect for projects with brief configurations, and when the person doing the configuring is comfortable editing Scala.
Spring is pretty flexible in terms of configuration. Lots of conf options can be driven either through XML configuration or annotations.
Documentation
Lift's documentation is young. Spring's docs are pretty mature. There's no contest.
Since Spring's docs are already nicely organized and easy to find, I'll review the docs I found for Lift. There are basically 4 sources of Lift documentation: the LiftWeb Book, the API Docs, LiftWeb's Google group, and "Getting Started". There's also a nice suite of code examples, but I wouldn't call them "documentation" per se.
The API docs are incomplete. The LiftWeb Book has been published on trees, but it's also freely available online. It is really useful, although its decidedly didactic style irritated me at times. It's a little long on tutorial and short on contract. Spring has a proper manual, which Lift lacks.
But Lift does have a nice set of examples. If you're comfortable reading the Lift code and example code (and you know Scala well already), you can work things out in fairly short order.
Both frameworks are compelling. There's a broad range of apps where you can choose either and do well.
I hate to completely throw your world for a loop. But you can you use Scala, Java, Lift, Spring in one application and have it not be a problem.
I would recommend you to check play framework, it has some very interesting ideas and supports development in Java and Scala
I've gotta say that I strongly disagree with Dan LaRocque's answer.
Lift is not monolithic. It is composed on discrete elements. It does not ignore J/EE elements, it support the likes of JNDI, JTA, JPA, etc. The fact that you're not forced to uses these elements of J/EE is a strong indication of Lift's modular design.
With the above being said, let me talk some about Lift's design philosophy.
I wrote this: http://blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html before I started writing Lift. To a great degree, and to a greater degree than is true for any other web framework that I know of, Lift meets these goals.
Lift at its core seeks to abstract away the HTTP request/response cycle rather than placing object wrappers around the HTTP Request. At the practical level, this means that most any action that a user can take (submitting form elements, doing Ajax, etc.) is represented by a GUID in the browser and a function on the server. When the GUID is presented as part of the an HTTP request, the function is applied (called) with the supplied parameters. Because the GUIDs are hard to predict and session-specific, replay attacks and many parameter tampering attacks are far more difficult with Lift than most other web frameworks, including Spring. It also means that developers are more productive because they are focusing on user actions and the business logic associated with user actions rather than the plumbing of packing and unpacking an HTTP request. For example, code for accepting or rejecting a FourSquare friend request:
ajaxButton("Accept", () => {request.accept.save;
SetHtml("acceptrejectspan", <span/>}) ++
ajaxButton("Reject", () => {request.reject.save;
SetHtml("acceptrejectspan", <span/>})
It's that simple. Because the friendRequest is in the scope when the function is created, the function closes over the scope... there's no need to expose the primary key of the friend request or do anything else... just define the text of the button (it can be localized or it can be pulled from an XHTML template or it can be pulled from a localized template) and the function to execute when the button is pushed. Lift takes care of assigning the GUID, setting up the Ajax call (via jQuery or YUI, and yes, you can add your own favorite JavaScript library), doing automatic retries with back-offs, avoiding connection starvation by queuing Ajax requests, etc.
So, one big difference between Lift and Spring is that Lift's philosophy of GUID associated with function has the dual benefit of much better security and much better developer productivity. The GUID -> Function association has proven very durable... the same construct works for normal forms, ajax, comet, multi-page wizards, etc.
The next core piece of Lift is keeping the high level abstractions around for as long as possible. On the page generation side, that means building the page as XHTML elements and keeping the page as XHTML until just before streaming the response. The benefits are resistance to cross site scripting errors, the ability to move CSS tags to the head and scripts to the bottom of the page after the page has been composed, and the ability to rewrite the page based on the target browser. On the input side, URLs can be re-written to extract parameters (both query and path parameters) in a type-safe manner, high level, security checked data is available for processing very early in the request cycle. For example, here's how to define servicing of a REST request:
serve {
case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
}
Using Scala's built-in pattern matching, we match an incoming request, extract the third part of the path and get the User that corresponds to that value, and even apply access control checks (does the current session or request have permissions to access the given User record). So, by the time the User instance hits the application logic, it's vetted.
With these two core pieces, Lift has a tremendous advantage in terms of security. To give you an idea of the magnitude of Lift's security that doesn't get in the way of features, Rasmus Lerdorg ( http://en.wikipedia.org/wiki/Rasmus_Lerdorf ) who did security for Yahoo! had this to say about FourSquare (one of the Lift poster-child sites):
Four stars to @foursquare - 1st site in a while I have taken a good look at that didn't have a single security issue (that I could find)
http://twitter.com/rasmus/status/5929904263
At the time, FourSquare had one engineer working on the code (not that @harryh isn't a super-genius) and his main focus was re-writing the PHP version of FourSquare while coping with weekly traffic doubling.
The last part of Lift's security focus is SiteMap. It's a unified access control, site navigation, and menu system. The developer defines the access control rules for each page using Scala code (e.g. If(User.loggedIn _) or If(User.superUser _)) and those access control rules are applied before any page rendering starts. This is much like Spring Security, except that it's baked in from the beginning of the project and the access control rules are unified with the rest of the application so you don't have to have process for updating the security rules in XML when the URLs change or the methods that calculate the access control change.
To summarize so far, Lift's design philosophy gives you the benefits of baked in access control, resistance to the OWASP top 10 security vulnerabilities, much better Ajax support and much higher developer productivity than does Spring.
But Lift also gives you the best Comet support of any web framework around. That's why Novell chose Lift to power their Pulse product ( http://www.novell.com/products/pulse/ ) and here's what Novell has to say about Lift:
Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level features like the built-in Comet support allow you to focus on innovating instead of the plumbing. Building a rich, real-time web application like Novell Pulse requires a framework with the power of Lift under the covers.
So, Lift is not just another me-too MVC framework. It's a framework that's got some core design principals behind it that have matured very well. It's a framework that gives the dual advantages of security and developer productivity. Lift is a framework that's built in layers and gives the developer the right choices based on their needs... choices for view generation, choices for persistence, etc.
Scala and Lift give developers a much better experience than the melange of XML, annotations, and other idioms that make up Spring.