Looks like it's great for building the things the authors thought you might want to build.
Just like every other "SuperMagic" framework, I suspect there's a lot of pain to be had once you step just a little outside of what it expects you to do with it.
We've all re-written Django inside of Django at least once, and thus have been burned by this sort of thing before. Personally, I think I'll wait to see some big projects written by people other than the framework designers before I agree that this is indeed the "best" web framework.
I've been using Django for a lot of projects, but have recently converted to Rails 3 for a personal project.
What I like about Rails is that plugins are mostly pieces of infrastructure, not ready-to-use mini-applications that are hard to customize. And Rack plugins (pieces of middleware, done in a standard/reusable way, contrary to Django's middleware) are just awesome.
I also like about Rails that authentication and admin are not built-in. Lots of plugins available for a quick-and-dirty job anyway.
I also like that defining models and even querying has been abstracted away in different interfaces, and that you can use MongoDB in a similar way as you would use a relational database.
Also, in case you need to decouple the request validations from the models (i.e. forms in Django) without HTML-rendering logic attached (useful at times, but completely getting in your way once you try doing anything complicated); in Rails you can, and it looks and feels cleaner because the field types don't have to be related to stuff you're rendering in the HTML response (i.e. field = forms.MultipleChoiceField(widget=CheckboxSelectMultiple)).
Django is awesome in case you ever thought about using Drupal for a project: much more flexible and dev friendly. But it completely got in my way so many times that I actually thought about writing my own Python web framework; which I shouldn't because people have been working on web-related stuff for the past 20 years.
Depends on your definition of pain. I've found the full stack of Lift features quite accessible, if at times somewhat poorly documented (but the group is quite excellent for these situations), from the basics to situations where I needed to short-circuit most of the Lift handling pipeline entirely to serve up something specific.
As for big projects, well, Foursquare is written in Lift.
1. Fetching content with AJAX and placing it into the DOM is "supported" by every web framework in existence.
2. Proxying ads through your own backend that threads itself? Yawn.
3. AJAX and COMET have pretty standard support. Again, this is left up to you with your Javascript library of choice.
4. Again, this is Javascript work. It might save me a little bit of development time, but I'd much rather be in complete control over the process of wiring my pages together.
5. Calling controls through classes isn't any more designer-friendly than Rails or Django template tags.
6. Pretty sure both Rails and Django have one-click install extensions for form Wizards (Rails might support it out of the box, haven't played with 3 enough lately to know)
7. All of these security principles are taken care of my every major web framework I can think of.
So we have some magic Javascript-generating controls and... that's it. Those are nice conveniences for sure, but a lot of these are uncommon use-cases, and I know I can probably bang-out a Django app to handle most of them in an afternoon, or just pull the real Javascript code I've used to handle these cases a dozen times over in the past.
The condescending attitude and failure to meet expectations means I'll probably never look at this framework again, which is a shame because it seems like it might be neat to toy around with. Too bad.
1. Lift goes further in enabling convention over configuration for common AJAX tasks that are part of normal workflows, so there is less boilerplate to write.
2. Parallel rendering means you can move to a SOA where different components on the UI are served by different backend services. This can be great if you have a recommendation service, a shopping cart and main content areas that are all served by different systems that may have different performance characteristics.. It also parallelizes the loading of the different parts of the page, which should decrease page load time.
3. Is there good comet support in existing frameworks out of the box? How would you easily update a partial in a rendered page when an object changes in rails or django? With Lift, you can hook up the rendered page (and its events) to server-side Actors... without any boilerplate code. This helps the productivity of development and (AFAIK) is still a rare feature.
4. You do have complete control, it is merely a matter of style. Lift does more things server-side.
5. One of the differences is that you don't need to have "partials", which could be more designer-friendly. I agree that this isn't a huge win.
6. yep.
7. I don't think the "No Direct Object Reference" security principle is taken care of by any other major web framework. It is a pretty big win for security -- because all of your exposed ids are session-specific, whole classes of problems just "go away".
I'm not saying that Lift is to Rails/Django what Rails/Django was to PHP, but it does have some interesting features that set it apart.
3. Ajax support seems pretty common but Comet seems pretty rare. Most major Javascript libs seem to have little or no support for Comet. Also, server side support for Comet seems even rarer.
4. Declarative syntax for dependencies seems much simpler than imperatively updating dependencies in Javascript
5. This one isn't presented very well. Essentially, all server side presentation logic is done in Scala code rather than adding custom HTML generation tags (<iterate>, <if>, etc.). This seems like a win (assuming the Scala syntax isn't awkward to work with) and something that I haven't seen before.
7. I have never seen web frameworks with built in support for A4 and A5
If these are things you have seen in other web frameworks I would be very interested to know where. I'm mostly coming from web frameworks on the JVM so it would be good to know more about what I am missing from frameworks outside of that.
I think your right that this is poorly written and maybe a little off putting. However, I think some of the stuff they present looks novel and useful.
It's somewhat frustrating to me when they continuously say "something that's hard or impossible in other web frameworks is trivial in Lift".
As one of the co-founders and developers of the NOLOH PHP Framework (http://www.noloh.com), I know that we've had many of these features for quite some time, including Comet (we support all protocols including streaming, short-polling and long-polling) with little to no effort on the developer's part, and in many cases significantly less effort than described here in lift.
I have nothing against Lift, and clearly I'm bias, however, the tone should've been less hostile in my opinion. However, maybe the hostile tone is good marketing. It's hard to say.
Lift is good, and if you're doing webapps in scala, you're probably going to use a lift package _somewhere_.
My impression of Lift is that the API aren't self-explanatory at first glance. import SHtml and S, hmmm, I know they do different things but I have to be reminded of what exactly from those packages I need.
I'm surprised no one has mentioned stateful vs stateless and horizontal scaling, yet. These are concerns dpp have addressed in the past but its worth reviving discussion. 4sq seems to be doing fine.
What is neat about lift and the foursquare story are the improvements to lift and scala web dev that come from that camp. Most recently, using MongoDB, devs now have a choice between java interop, casbah, and 4sq's rogue. Lift is an an integral and primary contributor to the scala web dev ecosystem.
Session affinity using the session id works pretty well. Many of the features come from the ability to have actors that propagate their state up to clients.
What's not mentioned (it's hard to sell) is, 50%+ of the reason Lift is so fabulous is, you're writing Scala. It's a mighty upgrade in quality of life, from either Ruby, Java or Python.
By corollary, what's being omitted is, the learning curve is steep. Scala isn't super-easy, and Lift dives fairly deep into the more complex stuff - implicits, currying, etc.
Nor is Lift itself all too well documented just yet. Yes, there's two books and a super-helpful community, but the experience is still in a different universe from the lavishly over-documented Spring MVC where you never really have to ask a question.
Ya - it's link bait. Saying "Lift is the most powerful, most secure web framework available today for Scala and Java" might be more accurate, but would be a yawn.
Just out of curiosity can you highlight the advantages lift has over other modern frameworks such as rails or django (and maybe some of the php frameworks). Most (or all) of the 7 things ship with rails 3. Stacking them up against one another might yield a better comparison.
I think that the author is coming from the Java world, in which case the comparison he likely had in mind is not Rails or django, but the plethora of Java web frameworks.
Personally, for Java Web Frameworks there are two I like, for quite different reasons.
The first is Spring MVC. the rest of Spring can go die in a fire for all I care, but the Spring MVC part is quite nice. Used properly it allows you to very quickly write a 'low ceremony but high fidelity' server based system. If you make some simplifying assumptions you can have all the Ajax you want too.
The other is GWT. The authors continually harp on about saving us from Javascript inconsistencies and cross browser compatibility. And, to be honest, I think they have a very good point. Anyone who has done serious web work would have run into cross browser problems. There are some other benefits to GWT, such as moving client state down to the client, where it well and truly belongs. Also the ability to pass real, proper Java objects (or at least pretend that is what you're doing) means GWT would never even notice most of the 'heavy lifting' that other frameworks keep rupturing their disks over - such as parsing form parameters, or having to post forms to the server to get them validated only to have to go back to the client and recreate the failed form... (save yourself the round trip and a square headache).
Now, obviously I'm clueless, but to my untrained eye as a programmer the bits I'd need to put into a Lift app look similar in some respects to the JSP tag libraries. E.g. they are trying to get you to do the programming in the html or xml. The problem is that xml (or any of its bastard love-children) is absolutely awful for doing logic in, which makes it deeply unsuited for that task. The only JSP tag library that I remember being worth mucking around with was some sort of super-duper-table-thingy.
Oh sure, you might not need to use weird variants on tags like <h:form> or <f:u:form> or <z:button> or whatever it was, but is moving the weirdness from the tag into the style/class really that big of an improvement? It is still doing the programming in the wrong place, that is, in the html.
List the ones that Rails does and how you achieve them (briefly). I'm pretty damn good with Rails, and it doesn't do a good chunk of this stuff, much as I love it.
Meh... not too impressive. Parallel Rendering: why is this a big deal? Wiring is what ASP.NET has been doing for ages. I don't see the Wizard being more than a few lines of Clojure, and Seaside just completely blows it away.
Parallel rendering matters because it increases page load speed. Let's say you have a page with 10 components that take an average of 100 ms to serve (including calls to db/soa, controller and view.) If loaded sequentially, your page will take 1 second. If loaded in parallel, it will only take 100ms (+ a little overhead.)
You might think: "oh, but this is just rendering, but most of the time is in the models/db/soa". You'd be right in other frameworks. Lift is view-first, so it will figure out what components it needs to serve up based on the view and then parallelize all of the computation required to fulfill them.
Unfortunately, this site takes the approach of "look how you can build wiz-bang with only N lines of code" rather than explaining the underlying functionality. This is exactly the wrong approach to impress developers.
It may be that Lift uses versatile and air-tight abstractions to accomplish these things, but we can't really figure that out from what's on this site. I recommend that the authors focus more on the principles on which Lift is built.
An example app running in app engine: http://lift-example.appspot.com/
Please notice that comet (and actors in general) does not work on app engine. If you are comfortable in linux it is pretty easy to copy jetty and a war to a vps like linode.com.
For a more app-engine like experience the newly announced amazon beanstalk might be a pretty good choice, but i have not tried it yet.
Let's pretend that these 7 things are really important and makes Lift different. The key hurdle of people adopting Lift is probably the Scala language more than anything. If people feel like they are comfortable in a language, they'll use anything they can get their hands on just to have some fun.
But does it look like people are having fun with Scala? When I learned SML in school, I remembered it was quite pleasant. The syntax was simple, type signatures were easy to read and be understood, and the rules were very straight-forward. Basically, I could fit the entire language in my head.
When I learned Java on my first job, I remembered it was also quite pleasant. The syntax was familiar, and concepts easy to grasp. It was verbose as ever, but hey, as least I could brain dump my thoughts into the source code, and read other people's brain dumps. Then Java 1.5 came with its "generics" that can't even remember it's own type after compilation...
A couple years later we now have this bastard child monster all grown up called Scala with its hybrid parametric P /subtype S polymorphic _ with implicit DSL <: smilies and the ever redundant parentheses and braces still in the control structures of a 201x language with optional .s and () in function calls. Don't even get me started on its suicide note that's called the Scala 2.8 Collections in the standard library.
I'm sorry, but I just don't see how this language eco-system can reach a critical mass with the handful of libraries it has now. Maybe when the tools are up to speed in a few years, smart Java people who are sick of Java will migrate over. It just has way too many rules and surprises.
Please, do start on the 2.8 collections. I'm curious to know what your problems are that an actual user of the collections would run into when using them.
Lift is a web application framework, written in Scala. Scala is a programming language. You would run this application with an HTTP server/servlet container like Jetty (optionally putting a different HTTP server/reverse proxy/load-balancer in front of that, like nginx).
If you want to have your dom events be handled server-side, then it is. It also lets you do things like have a dom node be bound to the state of a server-side object so the dom contents are updated when the server-side object's contents are changed -- it just takes care of the plumbing for you.
I think the biggest drawback with this framework is the hyperbole description.
If the offerings were sold as more direct and straight forward, perhaps it wouldn't have been such a disappointment. I expected more - based on the title.
As per "Lazing loading", if I view the source code of the link. I see all javascript files are loaded right at the beginning of the page, which is not a good practice. js loading is blocking
If your pages directly access the model, where is the controller? When I see things like foo.html it makes me think that this is not an MVC framework. (eg. foo.html on the server = /foo.html on the website)
If you don't shred pages from the designer then how to you retain the same look and feel across pages (eg. Does lift not have templating?)
Also, Lift is not the best framework for me because you have to write HTML and can't use something like HAML.
[+] [-] jasonkester|15 years ago|reply
Just like every other "SuperMagic" framework, I suspect there's a lot of pain to be had once you step just a little outside of what it expects you to do with it.
We've all re-written Django inside of Django at least once, and thus have been burned by this sort of thing before. Personally, I think I'll wait to see some big projects written by people other than the framework designers before I agree that this is indeed the "best" web framework.
[+] [-] bad_user|15 years ago|reply
What I like about Rails is that plugins are mostly pieces of infrastructure, not ready-to-use mini-applications that are hard to customize. And Rack plugins (pieces of middleware, done in a standard/reusable way, contrary to Django's middleware) are just awesome.
I also like about Rails that authentication and admin are not built-in. Lots of plugins available for a quick-and-dirty job anyway.
I also like that defining models and even querying has been abstracted away in different interfaces, and that you can use MongoDB in a similar way as you would use a relational database.
Also, in case you need to decouple the request validations from the models (i.e. forms in Django) without HTML-rendering logic attached (useful at times, but completely getting in your way once you try doing anything complicated); in Rails you can, and it looks and feels cleaner because the field types don't have to be related to stuff you're rendering in the HTML response (i.e. field = forms.MultipleChoiceField(widget=CheckboxSelectMultiple)).
Django is awesome in case you ever thought about using Drupal for a project: much more flexible and dev friendly. But it completely got in my way so many times that I actually thought about writing my own Python web framework; which I shouldn't because people have been working on web-related stuff for the past 20 years.
[+] [-] cmelbye|15 years ago|reply
[+] [-] shadowfiend|15 years ago|reply
As for big projects, well, Foursquare is written in Lift.
[+] [-] Pewpewarrows|15 years ago|reply
2. Proxying ads through your own backend that threads itself? Yawn.
3. AJAX and COMET have pretty standard support. Again, this is left up to you with your Javascript library of choice.
4. Again, this is Javascript work. It might save me a little bit of development time, but I'd much rather be in complete control over the process of wiring my pages together.
5. Calling controls through classes isn't any more designer-friendly than Rails or Django template tags.
6. Pretty sure both Rails and Django have one-click install extensions for form Wizards (Rails might support it out of the box, haven't played with 3 enough lately to know)
7. All of these security principles are taken care of my every major web framework I can think of.
So we have some magic Javascript-generating controls and... that's it. Those are nice conveniences for sure, but a lot of these are uncommon use-cases, and I know I can probably bang-out a Django app to handle most of them in an afternoon, or just pull the real Javascript code I've used to handle these cases a dozen times over in the past.
The condescending attitude and failure to meet expectations means I'll probably never look at this framework again, which is a shame because it seems like it might be neat to toy around with. Too bad.
[+] [-] aaronblohowiak|15 years ago|reply
2. Parallel rendering means you can move to a SOA where different components on the UI are served by different backend services. This can be great if you have a recommendation service, a shopping cart and main content areas that are all served by different systems that may have different performance characteristics.. It also parallelizes the loading of the different parts of the page, which should decrease page load time.
3. Is there good comet support in existing frameworks out of the box? How would you easily update a partial in a rendered page when an object changes in rails or django? With Lift, you can hook up the rendered page (and its events) to server-side Actors... without any boilerplate code. This helps the productivity of development and (AFAIK) is still a rare feature.
4. You do have complete control, it is merely a matter of style. Lift does more things server-side.
5. One of the differences is that you don't need to have "partials", which could be more designer-friendly. I agree that this isn't a huge win.
6. yep.
7. I don't think the "No Direct Object Reference" security principle is taken care of by any other major web framework. It is a pretty big win for security -- because all of your exposed ids are session-specific, whole classes of problems just "go away".
I'm not saying that Lift is to Rails/Django what Rails/Django was to PHP, but it does have some interesting features that set it apart.
Note: I have a bias.
[+] [-] eeperson|15 years ago|reply
4. Declarative syntax for dependencies seems much simpler than imperatively updating dependencies in Javascript
5. This one isn't presented very well. Essentially, all server side presentation logic is done in Scala code rather than adding custom HTML generation tags (<iterate>, <if>, etc.). This seems like a win (assuming the Scala syntax isn't awkward to work with) and something that I haven't seen before.
7. I have never seen web frameworks with built in support for A4 and A5
If these are things you have seen in other web frameworks I would be very interested to know where. I'm mostly coming from web frameworks on the JVM so it would be good to know more about what I am missing from frameworks outside of that.
I think your right that this is poorly written and maybe a little off putting. However, I think some of the stuff they present looks novel and useful.
Edit: formatting
[+] [-] asnyder|15 years ago|reply
As one of the co-founders and developers of the NOLOH PHP Framework (http://www.noloh.com), I know that we've had many of these features for quite some time, including Comet (we support all protocols including streaming, short-polling and long-polling) with little to no effort on the developer's part, and in many cases significantly less effort than described here in lift.
I have nothing against Lift, and clearly I'm bias, however, the tone should've been less hostile in my opinion. However, maybe the hostile tone is good marketing. It's hard to say.
[+] [-] swannodette|15 years ago|reply
[+] [-] steele|15 years ago|reply
My impression of Lift is that the API aren't self-explanatory at first glance. import SHtml and S, hmmm, I know they do different things but I have to be reminded of what exactly from those packages I need.
I'm surprised no one has mentioned stateful vs stateless and horizontal scaling, yet. These are concerns dpp have addressed in the past but its worth reviving discussion. 4sq seems to be doing fine.
What is neat about lift and the foursquare story are the improvements to lift and scala web dev that come from that camp. Most recently, using MongoDB, devs now have a choice between java interop, casbah, and 4sq's rogue. Lift is an an integral and primary contributor to the scala web dev ecosystem.
[+] [-] aaronblohowiak|15 years ago|reply
Session affinity using the session id works pretty well. Many of the features come from the ability to have actors that propagate their state up to clients.
[+] [-] doublez|15 years ago|reply
By corollary, what's being omitted is, the learning curve is steep. Scala isn't super-easy, and Lift dives fairly deep into the more complex stuff - implicits, currying, etc.
Nor is Lift itself all too well documented just yet. Yes, there's two books and a super-helpful community, but the experience is still in a different universe from the lavishly over-documented Spring MVC where you never really have to ask a question.
[+] [-] DennisP|15 years ago|reply
[+] [-] petervandijck|15 years ago|reply
[+] [-] rickmode|15 years ago|reply
[+] [-] strooltz|15 years ago|reply
[+] [-] Stormbringer|15 years ago|reply
Personally, for Java Web Frameworks there are two I like, for quite different reasons.
The first is Spring MVC. the rest of Spring can go die in a fire for all I care, but the Spring MVC part is quite nice. Used properly it allows you to very quickly write a 'low ceremony but high fidelity' server based system. If you make some simplifying assumptions you can have all the Ajax you want too.
The other is GWT. The authors continually harp on about saving us from Javascript inconsistencies and cross browser compatibility. And, to be honest, I think they have a very good point. Anyone who has done serious web work would have run into cross browser problems. There are some other benefits to GWT, such as moving client state down to the client, where it well and truly belongs. Also the ability to pass real, proper Java objects (or at least pretend that is what you're doing) means GWT would never even notice most of the 'heavy lifting' that other frameworks keep rupturing their disks over - such as parsing form parameters, or having to post forms to the server to get them validated only to have to go back to the client and recreate the failed form... (save yourself the round trip and a square headache).
Now, obviously I'm clueless, but to my untrained eye as a programmer the bits I'd need to put into a Lift app look similar in some respects to the JSP tag libraries. E.g. they are trying to get you to do the programming in the html or xml. The problem is that xml (or any of its bastard love-children) is absolutely awful for doing logic in, which makes it deeply unsuited for that task. The only JSP tag library that I remember being worth mucking around with was some sort of super-duper-table-thingy.
Oh sure, you might not need to use weird variants on tags like <h:form> or <f:u:form> or <z:button> or whatever it was, but is moving the weirdness from the tag into the style/class really that big of an improvement? It is still doing the programming in the wrong place, that is, in the html.
[+] [-] shadowfiend|15 years ago|reply
[+] [-] jcromartie|15 years ago|reply
[+] [-] aaronblohowiak|15 years ago|reply
You might think: "oh, but this is just rendering, but most of the time is in the models/db/soa". You'd be right in other frameworks. Lift is view-first, so it will figure out what components it needs to serve up based on the view and then parallelize all of the computation required to fulfill them.
[+] [-] arethuza|15 years ago|reply
[NB I rather like ASP.Net MVC but I use StringTemplate rather than ASPX pages for views].
[+] [-] extension|15 years ago|reply
It may be that Lift uses versatile and air-tight abstractions to accomplish these things, but we can't really figure that out from what's on this site. I recommend that the authors focus more on the principles on which Lift is built.
[+] [-] herrherr|15 years ago|reply
http://www.scala-lang.org/node/1826
That would take the pain out of deploying an app.
[+] [-] sorenbs|15 years ago|reply
[+] [-] bryanwb|15 years ago|reply
[+] [-] mtarnovan|15 years ago|reply
[+] [-] wyuenho|15 years ago|reply
But does it look like people are having fun with Scala? When I learned SML in school, I remembered it was quite pleasant. The syntax was simple, type signatures were easy to read and be understood, and the rules were very straight-forward. Basically, I could fit the entire language in my head.
When I learned Java on my first job, I remembered it was also quite pleasant. The syntax was familiar, and concepts easy to grasp. It was verbose as ever, but hey, as least I could brain dump my thoughts into the source code, and read other people's brain dumps. Then Java 1.5 came with its "generics" that can't even remember it's own type after compilation...
A couple years later we now have this bastard child monster all grown up called Scala with its hybrid parametric P /subtype S polymorphic _ with implicit DSL <: smilies and the ever redundant parentheses and braces still in the control structures of a 201x language with optional .s and () in function calls. Don't even get me started on its suicide note that's called the Scala 2.8 Collections in the standard library.
I'm sorry, but I just don't see how this language eco-system can reach a critical mass with the handful of libraries it has now. Maybe when the tools are up to speed in a few years, smart Java people who are sick of Java will migrate over. It just has way too many rules and surprises.
[+] [-] shadowfiend|15 years ago|reply
[+] [-] csomar|15 years ago|reply
Sorry, but I failed to understand: is this a web server, a programming language...? I don't exactly get, what it does and for what I should use it.
[+] [-] LiveTheDream|15 years ago|reply
http://www.liftweb.net/
http://www.scala-lang.org/
http://jetty.codehaus.org/jetty/
http://wiki.nginx.org/Main
[+] [-] KevBurnsJr|15 years ago|reply
[+] [-] aaronblohowiak|15 years ago|reply
[+] [-] marcamillion|15 years ago|reply
If the offerings were sold as more direct and straight forward, perhaps it wouldn't have been such a disappointment. I expected more - based on the title.
[+] [-] clu3|15 years ago|reply
[+] [-] wavewash|15 years ago|reply
[+] [-] mgkimsal|15 years ago|reply
[+] [-] fhars|15 years ago|reply
[+] [-] tommyg|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] fleitz|15 years ago|reply
If you don't shred pages from the designer then how to you retain the same look and feel across pages (eg. Does lift not have templating?)
Also, Lift is not the best framework for me because you have to write HTML and can't use something like HAML.
Sass + Haml + coffescript = WIN!