5 ms·

Why Lift is My Favorite Web Framework

60 points by tomtom101 14y ago

eCa 14y ago
This is OT, but you really should track clicks on links (if you need to do it in the first place) in a different way than this: <a href="javascript:mixpanel_track_link('http://liftweb.com/','link:liftweb.com');">my first encounter with Lift</a>
- jabiko 14y ago
  Came here to say the same. At least they should detect a scroll wheel click and open the link in a new tab. Or they could use the google approach and change the link in the last moment to point to a tracking service.
  - cientifico 14y ago
    One more with the same problem. Right click open in a new window, and then 3 tabs with about:blank. That is also because using lift?
    - fhars 14y ago
      No, that s probably because 
    - xaritas 14y ago
      No, Lift does NOT do this. The site appears to be running on WordPress (guessing based on the 'wp-content' in the paths for assets). I confess to having a bit of a crush on Lift so I was happy to see something about it on the front page, but this article is a little vague, so most people will probably remember the intrusive click tracking over anything else.
    - wingchen 14y ago
      Nope. This is a wordpress blog.
    - MBCook 14y ago
      Interesting. Safari won't even give me the option to open it in a new tab, since it's obviously not a web link. Just obnoxious.
- grey-area 14y ago
  It's easy to do this with a jquery post - just bind to the click event, and post the tracking data to whatever URL you want as a separate async action, without getting in the way of the user. You should never put js in the href like this, or insert extra referral links prior to going to the real link as google have been doing recently; it breaks the web.
deleted 14y ago
[deleted]
dpick 14y ago
I've had very similar feelings using enlive in Clojure land. I doubt I'll be switching back to a more traditional templating engine any time soon.
- mossity 14y ago
  Yeah, thought of Enlive when I read this. I wish this style of templating could get imported into Rails.
- wingchen 14y ago
  I agree. View first rocks!
- cgag 14y ago
  I'm very happy with Hiccup, I think both paradigms are better than the more common ERB style templating. Either pure Clojure (or whateverlanguage) or pure HTML rather than a mix. I wish Clojure had a batteries included framework like this just to draw more attention to the language.
  - wink 14y ago
    Have you had a look at Luminus[1]? [1]: http://www.luminusweb.net http://www.luminusweb.net
zura 14y ago
What I hate in these company blogs - there seems to be no way to go to the actual company site... I always end up editing the address bar and removing "blog." prefix by hand...
tikhonj 14y ago
Many of the same advantages (and some additional ones, no doubt) hold for the Haskell web frameworks, with the added benefit of using Haskell. I'm in no position to say whether Yesod or Lift is better; I just wish more people would consider Haskell at all--it's a great choice for web programming (among many other things).
- slurgfest 14y ago
  Many of the same advantages hold for any other language's frameworks, with the added benefit of using any other language.
- danieldk 14y ago
  Yesod is great, especially its quasi quoters, such as Hamlet. However, two things that I constantly bumped into maintaining a small Yesod app is that there was a fairly constant stream of API changes and that deployment on different machines was annoying because of version conflicts installing packages. If you use Yesod, you are probably best off using a Cabal sandbox (e.g. via cabal-dev) and making specific package versions dependencies. Of course, that may be questionable from a security perspective. I ended up rewriting that particular web app to Play, which offers some of the same benefits, but was a lot easier to deploy. You can create a stand-alone version of an application with play dist, which includes all the required jars, and the only thing required on a server is the Java runtime environment. Also, Maven/sbt seems a lot more mature than Cabal. As an added advantage, you can use tried and tested Java or can go all-functional via Scala.
  - tikhonj 14y ago
    Well, for very relative values of "all-functional". But yeah, Cabal is certainly a bit of a pain. Happily, people are working on it. Superior cabal-dev functionality is going to be integrated into cabal proper very soon, if it hasn't already, for example. Also, couldn't you just compile your binary with static linking and just deploy that? I understand there can be problems if you depend on certain non-Haskell libraries like GUI toolkits, but that shouldn't be an issue for a web app. I think a statically linked binary is pretty similar to a jar file in practice.
MasterXen 14y ago
Apologies if this is nit-picky, but... Some of the main points are weak and don't really apply to differentiating Lift specifically. For example, the fact that Lift is Scala-based doesn't make it any different than Symfony is PHP-based or Spring MVC is Java-based. Subjective, but I definitely understand that that this is an opinionated view (rather than a objective "Lift has Feature X" viewpoint). Similarly, what server-side framework that's in wide usage nowadays doesn't have the ability to have some form of generated/dynamic JS wiring? I'd say that's table stakes nowadays, not something to callout by any means.
lmm 14y ago
I tried to like Lift, but it's so woefully documented that I can't. At the moment I've gone back to Wicket (which is fantastic on many of these, particularly building a page out of component objects rather than bunging lots of stuff in a page controller, and has an even better way of doing bindings than lift does), even though it doesn't fit perfectly with Scala.
- wingchen 14y ago
  documentation is getting better and better these days, although i cannot argue documentation part.
dwhitney 14y ago
The sever side statefulness of Lift, the fact that it supposes I don't know how to program HTML/JavaScript, and the hostility toward Scala that Lift's creator harbors since negotiations with him joining Typesafe broke down, are all reasons I think it would behoove anyone to avoid the framework. Play, unfiltered, scalatra, and blue eyes are all fantastic
- tych0 14y ago
  > The sever side statefulness of Lift Having been using lift professionally for the last year or so, this is definitely my biggest complaint. I feel like Lift got it wrong here -- the *Var model is just hard to reason about. Our app has a lot of complicated logic to save and restore state at the appropriate times, and this model is supposedly the Right Way to do things. > the fact that it supposes I don't know how to program HTML/JavaScript Not sure why you say that; I've never gotten this feeling. > the hostility toward Scala that Lift's creator harbors Lift has 50 committers now. It's not going anywhere. If dickead maintainers were a real problem, nobody would be using glibc anymore. (I don't have any thoughts on whether DPP is a dickhead; I do think Drepper is, though :-) One thing you didn't mention is the whole CssSel model combined with the way lift does templating. I think it's awesome, and hopefully I'll never have to work with another style of templating again in my life. (In fact, I wrote an implementation of it in haskell for my personal static site generator, because I love it so much: http://hackage.haskell.org/package/hquery http://hackage.haskell.org/package/hquery </shamelessplug>).
  - jfim 14y ago
    Can you elaborate a little more on the server-side statefulness of Lift and the issues you encountered? I was reticent about statefulness on the server-side, until I read an article about statefulness in Lift[1], which does mention how having session affinity helps with it. Mostly, my questions are: does it scale and how do you handle state loss (due to servers catching on fire or other hardware/software failures)? [1] http://lift.la/lift-state-and-scaling http://lift.la/lift-state-and-scaling
    - 14y ago
laureny 14y ago
Regardless of the technical qualities of Lift, its future is pretty uncertain with 1) dpp leaving the project (in pretty bad terms) a few months ago and 2) Typesafe choosing Play over Lift for its stack. I would definitely not pick Lift today for a new project.
- riveramj 14y ago
  dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. as to why typesafe chose play over lift: they wanted to go with lift but dpp didn't want to work with them - didnt think it a wise decision. his explanation: http://www.quora.com/Lift-web-framework/Why-did-Typesafe-select-Play-for-their-stack-instead-of-Lift/answer/David-Pollak/quote/338456 http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel...
  - wingchen 14y ago
    nice to learn this. thanks
  - coldtea 14y ago
    >dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. Well, this doesn't sound a lot better than him leaving the project.
    - shadowfiend 14y ago
      With a team of committers that are contributing consistently to the project, as well as David continuing to contribute regularly, I have no idea how you can get by saying this. Releases have continued apace, and work on Lift 3 has begun. What exactly is it that you think would be bad were dpp to leave the project altogether that you see happening right now?
  - laureny 14y ago
    This was a very interesting read, especially the part about the internal workings of Typesafe (a bit concerning too).
muglug 14y ago
Lift's JS & jQuery code generation is nightmare-inducing, it's ridiculous to call it a "benefit". JavaScript should not be auto-generated by some flavour-of-the-week web framework in a totally different language. You're just creating a whole world of pain for future-you.
- wingchen 14y ago
  I respectfully disagree. I was able to finish an ajax form, including value validation with only a snippet and it's binded scala function. I did not have to create a specific rest API and write up jquery ajax code along with the snippet. Lift's JS & Jquery support was never meant to replace js and jquery. (don't write up every js feature with lift.) It's meant to eliminate tedious js works that both frontend and backend developers don't want to spend time on.
- shadowfiend 14y ago
  I think calling it nightmare-inducing is going too far, but there's nothing that forces you to use it. I think it's fantastic for prototyping, because it lets you focus on getting things done in one place. If you're not prototyping, I think you should keep your JS in JS and come up with a common interface to interact with your JS from the server—I've chosen events dispatched on the document element in a variety of situations as that communication protocol.
Uchikoma 14y ago
After some years of living with Lift: Liftweb is awful. Don't use it. There is not enough documentation (by a large margin, even with the books, one example being the dozens of hooks you could hook into if they were documented), it's too complicated and there are a millions ways to do one thing. That said the rendering and binding is the best way to do rendering I've seen yet. I'd wish this was easily usable with other frameworks. And Rogue (from foursquare) for Mongo on top of Liftweb persistence mapping is excellent. My understanding they will support things outside Lift in the future.
neya 14y ago
I might get downvoted for this..but I'll risk it, because it is a message that needs to be passed. My experience on using Lift. A few months ago, I was evaluating various frameworks to start off with my new web app. I am already running a dozen RoR apps and gradually I'm moving away from RoR. I will explain as to why, later in my post. I was evaluating between Play and Lift and I ended up choosing....Lift. Lift has an extremely high barrier to entry mainly because of the poor documentation. When I first started off with scala, I didn't even know what the hell was SBT, when I downloaded Lift, there were a lot of things that were confusing - I was expecting perfectly organized folders just like ruby on rails, but everything was almost hidden/scattered. However this was the only barrier to starting up with Lift. I also did read about the controversies about the framework, etc [1]. of Lift, but honestly, none of them actually mattered to the developer, that is me. Now that I've chosen Lift, I think I made the right choice. Now, WHY is Lift better? 1) It's a 3+ year old Framework that is extremely stead-fast and stable, production-ready. 2) Scalability - This is a subjective view, but many high profile companies switch to Scala from Ruby/PHP/etc. when they need to scale. And Lift is a really good framework that gets the job done. [2][3] 3) Contrary to popular belief, once you cross the barrier to entry, it becomes much much easier to develop Web apps with Lift. Remember those wordpress days? How scary it was in the beginning to write custom themes and plugins?? But once you started writing a few, it felt like a breeze, right? That's what I'm talking about - That's exactly how Lift is too! [4] 4) Security - Security is hard. Sure you can write your Web app without using a framework. But if you use RoR, you will realize how much work is being done on behalf of you to make your app secure (Authenticity token, CSRF protection ,etc.) Lift is no different and it is one of the most securest frameworks I've ever worked with.[5] This is a very good guide explaining why you need to choose Lift over anything else.[6] 5) RoR vs Scala - Now, Imagine this scenario - You are a sculptor (web developer). You have two materials to choose from to create a statue (your web app). One is ordinary clay (Ruby on Rails) and the other one is a Metal, preferably some alloy made of copper and bronze (Lift). It is extremely easy to model your Statue (your web app) in Clay. And once you're done modeling, you can add some chemicals, or even thin layers of metal on top of it, etc. to make it strong (Think Unicorn, Phusion, etc). But, no matter what you do, the core is still made of clay and if you throw it down, your clay model will shatter into pieces. Now compare it with the Bronze alloy (Lift). It is extremely hard to make a statue with it, but once you make statue with it, it's going to be so hard and robust, it can handle pressure (load) well - Even if you drop it, it might deform slightly, but never break. But, the disadvantage is that it takes too long to model a statue with this metal. However, you should decide if the trade-off in time is worth the effort in the long run. Of course everyone wants a nice status that is robust! In the real world, you will probably be ok with RoR, but when you need to scale, you will realize the potential benefits you are missing out soon[7] - For example, if RoR can handle X requests/sec, and Lift can handle 10x requests per second, and assuming X requests require an Amazon box, then you save 9 boxes with Lift. That is huge savings for your start up, isn't it? I always wonder why people try so hard to scale RoR. It's a great framework, but the wiser thing to do would be to use something more efficient when you need to , than holding onto something that is less efficient because you like it. Also RoR has its own confusing terminologies (personal opinion). For example: render json: @post render :json => {:errors} Notice the colons before and after the word 'json'. If you are interested in Scala, Coursera has a course on Learning Scala by Martin Odersky (The creator of Scala) and it is really good. Scala is not a purely functional programming language, which means if you are accustomed to programming in Ruby style, you can take it with you to Scala too. [1]http://www.quora.com/Lift-web-framework/Why-did-Typesafe-select-Play-for-their-stack-instead-of-Lift/answer/David-Pollak http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel... [2]http://img.scoop.it/FP9bEzouSr7kRinQRAtGmDl72eJkfbmt4t8yenImKBVaiQDB_Rd1H6kmuBWtceBJ http://img.scoop.it/FP9bEzouSr7kRinQRAtGmDl72eJkfbmt4t8yenIm... [3]http://www.quora.com/Why-did-foursquare-choose-Lift http://www.quora.com/Why-did-foursquare-choose-Lift [4]http://stackoverflow.com/questions/2573608/what-type-of-webapp-is-the-sweet-spot-for-scalas-lift-framework http://stackoverflow.com/questions/2573608/what-type-of-weba... [5]http://seventhings.liftweb.net/security http://seventhings.liftweb.net/security [6]http://seventhings.liftweb.net/ http://seventhings.liftweb.net/ [7]http://lift.la/lift-state-and-scaling http://lift.la/lift-state-and-scaling
dkhenry 14y ago
I am amazed people even see Lift as in the same balpark as Play. When I last used lift It appeared to be a relic of the J2EE stack ported to a new language. This goes beyond any technical capabilities of the framework and down to how it expects you to work in it. Even the author says that just getting started can be a pain, doesn't that tell you something about your framework. It its hard to understand what to do its hard for people in the future to understand what you did. So who cares if you can make pages with just a few "snippets" no one else can figure out what you did.
- wingchen 14y ago
  Well, we cannot assume that people cannot learn. Snippets are smaller piece of codes compared to controllers, and logically making more sense. All you have to do is to train people. Isn't it the way people learn MVC too?

60 points by tomtom101 14y ago

eCa 14y ago

This is OT, but you really should track clicks on links (if you need to do it in the first place) in a different way than this: <a href="javascript:mixpanel_track_link('http://liftweb.com/','link:liftweb.com');">my first encounter with Lift</a>

jabiko 14y ago
Came here to say the same. At least they should detect a scroll wheel click and open the link in a new tab. Or they could use the google approach and change the link in the last moment to point to a tracking service.
- cientifico 14y ago
  One more with the same problem. Right click open in a new window, and then 3 tabs with about:blank. That is also because using lift?
  - fhars 14y ago
    No, that s probably because 
  - xaritas 14y ago
    No, Lift does NOT do this. The site appears to be running on WordPress (guessing based on the 'wp-content' in the paths for assets). I confess to having a bit of a crush on Lift so I was happy to see something about it on the front page, but this article is a little vague, so most people will probably remember the intrusive click tracking over anything else.
  - wingchen 14y ago
    Nope. This is a wordpress blog.
  - MBCook 14y ago
    Interesting. Safari won't even give me the option to open it in a new tab, since it's obviously not a web link. Just obnoxious.
grey-area 14y ago
It's easy to do this with a jquery post - just bind to the click event, and post the tracking data to whatever URL you want as a separate async action, without getting in the way of the user. You should never put js in the href like this, or insert extra referral links prior to going to the real link as google have been doing recently; it breaks the web.

deleted 14y ago

[deleted]

dpick 14y ago

I've had very similar feelings using enlive in Clojure land. I doubt I'll be switching back to a more traditional templating engine any time soon.

mossity 14y ago
Yeah, thought of Enlive when I read this. I wish this style of templating could get imported into Rails.
wingchen 14y ago
I agree. View first rocks!
cgag 14y ago
I'm very happy with Hiccup, I think both paradigms are better than the more common ERB style templating. Either pure Clojure (or whateverlanguage) or pure HTML rather than a mix. I wish Clojure had a batteries included framework like this just to draw more attention to the language.
- wink 14y ago
  Have you had a look at Luminus[1]? [1]: http://www.luminusweb.net http://www.luminusweb.net

zura 14y ago

What I hate in these company blogs - there seems to be no way to go to the actual company site... I always end up editing the address bar and removing "blog." prefix by hand...

tikhonj 14y ago

Many of the same advantages (and some additional ones, no doubt) hold for the Haskell web frameworks, with the added benefit of using Haskell. I'm in no position to say whether Yesod or Lift is better; I just wish more people would consider Haskell at all--it's a great choice for web programming (among many other things).

slurgfest 14y ago
Many of the same advantages hold for any other language's frameworks, with the added benefit of using any other language.
danieldk 14y ago
Yesod is great, especially its quasi quoters, such as Hamlet. However, two things that I constantly bumped into maintaining a small Yesod app is that there was a fairly constant stream of API changes and that deployment on different machines was annoying because of version conflicts installing packages. If you use Yesod, you are probably best off using a Cabal sandbox (e.g. via cabal-dev) and making specific package versions dependencies. Of course, that may be questionable from a security perspective. I ended up rewriting that particular web app to Play, which offers some of the same benefits, but was a lot easier to deploy. You can create a stand-alone version of an application with play dist, which includes all the required jars, and the only thing required on a server is the Java runtime environment. Also, Maven/sbt seems a lot more mature than Cabal. As an added advantage, you can use tried and tested Java or can go all-functional via Scala.
- tikhonj 14y ago
  Well, for very relative values of "all-functional". But yeah, Cabal is certainly a bit of a pain. Happily, people are working on it. Superior cabal-dev functionality is going to be integrated into cabal proper very soon, if it hasn't already, for example. Also, couldn't you just compile your binary with static linking and just deploy that? I understand there can be problems if you depend on certain non-Haskell libraries like GUI toolkits, but that shouldn't be an issue for a web app. I think a statically linked binary is pretty similar to a jar file in practice.

MasterXen 14y ago

Apologies if this is nit-picky, but... Some of the main points are weak and don't really apply to differentiating Lift specifically. For example, the fact that Lift is Scala-based doesn't make it any different than Symfony is PHP-based or Spring MVC is Java-based. Subjective, but I definitely understand that that this is an opinionated view (rather than a objective "Lift has Feature X" viewpoint). Similarly, what server-side framework that's in wide usage nowadays doesn't have the ability to have some form of generated/dynamic JS wiring? I'd say that's table stakes nowadays, not something to callout by any means.

lmm 14y ago

I tried to like Lift, but it's so woefully documented that I can't. At the moment I've gone back to Wicket (which is fantastic on many of these, particularly building a page out of component objects rather than bunging lots of stuff in a page controller, and has an even better way of doing bindings than lift does), even though it doesn't fit perfectly with Scala.

wingchen 14y ago
documentation is getting better and better these days, although i cannot argue documentation part.

dwhitney 14y ago

The sever side statefulness of Lift, the fact that it supposes I don't know how to program HTML/JavaScript, and the hostility toward Scala that Lift's creator harbors since negotiations with him joining Typesafe broke down, are all reasons I think it would behoove anyone to avoid the framework. Play, unfiltered, scalatra, and blue eyes are all fantastic

tych0 14y ago
> The sever side statefulness of Lift Having been using lift professionally for the last year or so, this is definitely my biggest complaint. I feel like Lift got it wrong here -- the *Var model is just hard to reason about. Our app has a lot of complicated logic to save and restore state at the appropriate times, and this model is supposedly the Right Way to do things. > the fact that it supposes I don't know how to program HTML/JavaScript Not sure why you say that; I've never gotten this feeling. > the hostility toward Scala that Lift's creator harbors Lift has 50 committers now. It's not going anywhere. If dickead maintainers were a real problem, nobody would be using glibc anymore. (I don't have any thoughts on whether DPP is a dickhead; I do think Drepper is, though :-) One thing you didn't mention is the whole CssSel model combined with the way lift does templating. I think it's awesome, and hopefully I'll never have to work with another style of templating again in my life. (In fact, I wrote an implementation of it in haskell for my personal static site generator, because I love it so much: http://hackage.haskell.org/package/hquery http://hackage.haskell.org/package/hquery </shamelessplug>).
- jfim 14y ago
  Can you elaborate a little more on the server-side statefulness of Lift and the issues you encountered? I was reticent about statefulness on the server-side, until I read an article about statefulness in Lift[1], which does mention how having session affinity helps with it. Mostly, my questions are: does it scale and how do you handle state loss (due to servers catching on fire or other hardware/software failures)? [1] http://lift.la/lift-state-and-scaling http://lift.la/lift-state-and-scaling
  - 14y ago

laureny 14y ago

Regardless of the technical qualities of Lift, its future is pretty uncertain with 1) dpp leaving the project (in pretty bad terms) a few months ago and 2) Typesafe choosing Play over Lift for its stack. I would definitely not pick Lift today for a new project.

riveramj 14y ago
dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. as to why typesafe chose play over lift: they wanted to go with lift but dpp didn't want to work with them - didnt think it a wise decision. his explanation: http://www.quora.com/Lift-web-framework/Why-did-Typesafe-select-Play-for-their-stack-instead-of-Lift/answer/David-Pollak/quote/338456 http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel...
- wingchen 14y ago
  nice to learn this. thanks
- coldtea 14y ago
  >dpp did not leave lift. true he has other projects and focuses on more than just lift, but he is still heavily involved in it. Well, this doesn't sound a lot better than him leaving the project.
  - shadowfiend 14y ago
    With a team of committers that are contributing consistently to the project, as well as David continuing to contribute regularly, I have no idea how you can get by saying this. Releases have continued apace, and work on Lift 3 has begun. What exactly is it that you think would be bad were dpp to leave the project altogether that you see happening right now?
- laureny 14y ago
  This was a very interesting read, especially the part about the internal workings of Typesafe (a bit concerning too).

muglug 14y ago

Lift's JS & jQuery code generation is nightmare-inducing, it's ridiculous to call it a "benefit". JavaScript should not be auto-generated by some flavour-of-the-week web framework in a totally different language. You're just creating a whole world of pain for future-you.

wingchen 14y ago
I respectfully disagree. I was able to finish an ajax form, including value validation with only a snippet and it's binded scala function. I did not have to create a specific rest API and write up jquery ajax code along with the snippet. Lift's JS & Jquery support was never meant to replace js and jquery. (don't write up every js feature with lift.) It's meant to eliminate tedious js works that both frontend and backend developers don't want to spend time on.
shadowfiend 14y ago
I think calling it nightmare-inducing is going too far, but there's nothing that forces you to use it. I think it's fantastic for prototyping, because it lets you focus on getting things done in one place. If you're not prototyping, I think you should keep your JS in JS and come up with a common interface to interact with your JS from the server—I've chosen events dispatched on the document element in a variety of situations as that communication protocol.

Uchikoma 14y ago

After some years of living with Lift: Liftweb is awful. Don't use it. There is not enough documentation (by a large margin, even with the books, one example being the dozens of hooks you could hook into if they were documented), it's too complicated and there are a millions ways to do one thing. That said the rendering and binding is the best way to do rendering I've seen yet. I'd wish this was easily usable with other frameworks. And Rogue (from foursquare) for Mongo on top of Liftweb persistence mapping is excellent. My understanding they will support things outside Lift in the future.

neya 14y ago

I might get downvoted for this..but I'll risk it, because it is a message that needs to be passed. My experience on using Lift. A few months ago, I was evaluating various frameworks to start off with my new web app. I am already running a dozen RoR apps and gradually I'm moving away from RoR. I will explain as to why, later in my post. I was evaluating between Play and Lift and I ended up choosing....Lift. Lift has an extremely high barrier to entry mainly because of the poor documentation. When I first started off with scala, I didn't even know what the hell was SBT, when I downloaded Lift, there were a lot of things that were confusing - I was expecting perfectly organized folders just like ruby on rails, but everything was almost hidden/scattered. However this was the only barrier to starting up with Lift. I also did read about the controversies about the framework, etc [1]. of Lift, but honestly, none of them actually mattered to the developer, that is me. Now that I've chosen Lift, I think I made the right choice. Now, WHY is Lift better? 1) It's a 3+ year old Framework that is extremely stead-fast and stable, production-ready. 2) Scalability - This is a subjective view, but many high profile companies switch to Scala from Ruby/PHP/etc. when they need to scale. And Lift is a really good framework that gets the job done. [2][3] 3) Contrary to popular belief, once you cross the barrier to entry, it becomes much much easier to develop Web apps with Lift. Remember those wordpress days? How scary it was in the beginning to write custom themes and plugins?? But once you started writing a few, it felt like a breeze, right? That's what I'm talking about - That's exactly how Lift is too! [4] 4) Security - Security is hard. Sure you can write your Web app without using a framework. But if you use RoR, you will realize how much work is being done on behalf of you to make your app secure (Authenticity token, CSRF protection ,etc.) Lift is no different and it is one of the most securest frameworks I've ever worked with.[5] This is a very good guide explaining why you need to choose Lift over anything else.[6] 5) RoR vs Scala - Now, Imagine this scenario - You are a sculptor (web developer). You have two materials to choose from to create a statue (your web app). One is ordinary clay (Ruby on Rails) and the other one is a Metal, preferably some alloy made of copper and bronze (Lift). It is extremely easy to model your Statue (your web app) in Clay. And once you're done modeling, you can add some chemicals, or even thin layers of metal on top of it, etc. to make it strong (Think Unicorn, Phusion, etc). But, no matter what you do, the core is still made of clay and if you throw it down, your clay model will shatter into pieces. Now compare it with the Bronze alloy (Lift). It is extremely hard to make a statue with it, but once you make statue with it, it's going to be so hard and robust, it can handle pressure (load) well - Even if you drop it, it might deform slightly, but never break. But, the disadvantage is that it takes too long to model a statue with this metal. However, you should decide if the trade-off in time is worth the effort in the long run. Of course everyone wants a nice status that is robust! In the real world, you will probably be ok with RoR, but when you need to scale, you will realize the potential benefits you are missing out soon[7] - For example, if RoR can handle X requests/sec, and Lift can handle 10x requests per second, and assuming X requests require an Amazon box, then you save 9 boxes with Lift. That is huge savings for your start up, isn't it? I always wonder why people try so hard to scale RoR. It's a great framework, but the wiser thing to do would be to use something more efficient when you need to , than holding onto something that is less efficient because you like it. Also RoR has its own confusing terminologies (personal opinion). For example: render json: @post render :json => {:errors} Notice the colons before and after the word 'json'. If you are interested in Scala, Coursera has a course on Learning Scala by Martin Odersky (The creator of Scala) and it is really good. Scala is not a purely functional programming language, which means if you are accustomed to programming in Ruby style, you can take it with you to Scala too. [1]http://www.quora.com/Lift-web-framework/Why-did-Typesafe-select-Play-for-their-stack-instead-of-Lift/answer/David-Pollak http://www.quora.com/Lift-web-framework/Why-did-Typesafe-sel... [2]http://img.scoop.it/FP9bEzouSr7kRinQRAtGmDl72eJkfbmt4t8yenImKBVaiQDB_Rd1H6kmuBWtceBJ http://img.scoop.it/FP9bEzouSr7kRinQRAtGmDl72eJkfbmt4t8yenIm... [3]http://www.quora.com/Why-did-foursquare-choose-Lift http://www.quora.com/Why-did-foursquare-choose-Lift [4]http://stackoverflow.com/questions/2573608/what-type-of-webapp-is-the-sweet-spot-for-scalas-lift-framework http://stackoverflow.com/questions/2573608/what-type-of-weba... [5]http://seventhings.liftweb.net/security http://seventhings.liftweb.net/security [6]http://seventhings.liftweb.net/ http://seventhings.liftweb.net/ [7]http://lift.la/lift-state-and-scaling http://lift.la/lift-state-and-scaling

dkhenry 14y ago

I am amazed people even see Lift as in the same balpark as Play. When I last used lift It appeared to be a relic of the J2EE stack ported to a new language. This goes beyond any technical capabilities of the framework and down to how it expects you to work in it. Even the author says that just getting started can be a pain, doesn't that tell you something about your framework. It its hard to understand what to do its hard for people in the future to understand what you did. So who cares if you can make pages with just a few "snippets" no one else can figure out what you did.

wingchen 14y ago
Well, we cannot assume that people cannot learn. Snippets are smaller piece of codes compared to controllers, and logically making more sense. All you have to do is to train people. Isn't it the way people learn MVC too?