+1

I'd better add @jacksingleton comment near Lift entry. Just to avoid future submits of the framework.

I think Lift is pretty awesome. It also solves many interesting problems that other listed frameworks don't.

For example, Lift is more secure than any other framework listed. I think "awesome" definition should take security in mind, and if a framework is really good at it, that should be enough to be included in the list.

While it may have been a good choice at one point in time (before scala got any other web frameworks)

Both Liftweb and Playframework were founded at 2007:
https://en.wikipedia.org/wiki/Play_Framework
https://en.wikipedia.org/wiki/Liftweb

I think Lift is useful for static web page, but is not for dynamic web page that is common recently.

The biggest reason for it , you have to take HTML DOM manipulation to server side.

It means that if designer want to create ajax content, they have to learn Scala. So really, Lift is not designer friendly.

I think View First concept is not wrong. But it does not suit server side.
Nowadays, you can do it by JavaScript framework such as Angular.js or Knockout.js and so on.
If you use JavaScript Framework then you can make dynamic view by html template and easy JavaScript. It is more designer friendly and more suitable for View First approach.

I don't think that's fair to negatively judge on what a framework can do. Please, judge by what it cannot, or what conceptions doesn't it have. For example...:

if designer want to create ajax content, they have to learn Scala

That's actually wrong. A designer isn't forced to learn Scala. Liftweb just offers an alternative to old-style manual ajax bindings. Instead it offers a new conception (which is safe but requires Scala). Say you don't want it yet and want to stay traditionally? OK, do it, absolutely no stoppers here.

you have to take HTML DOM manipulation to server side.

No, really, you don't have to. You can serve both static files and dynamic HTML. You're not forced to. Again, HTML, not "DOM". Lift is server-side, it cannot generate DOM.
I mean, you really have the right to "not like" the way HTML is generated. OK, that's your choice. Not the only one right.

can do it by JavaScript framework such as Angular.js or Knockout.js and so on. If you use JavaScript Framework then you can make dynamic view by html

I don't actually get the point here. You want to say that "JavaScript Frameworks" do "view-first" better? OK, use them. No, I don't want to use server-side javascript myself.:) I personally like FRP and ScalaJs http://www.scala-js.org/ , worked with Lift, spray and java frameworks. Lift is one of the most awesome things I worked with, together with ScalaJs.)

@icoxfog417 I can send you your comment if you removed it accidentally (because I received it by mail).

(thank you for @vn971 , I accidentally removed comment!)

If judge by what it cannot, Lift cannot separate client side and server side.

Lift's basic feature is "receive DOM and return DOM". It is called by Snippets.
Here is the simple Snippet.

class ShowDate {
  def showTime = "#time *" #> date.map(_.toString)
}

It receives DOM from view, and find #time element , then set date to it.
Because of this feature, Lift has many DOM selector methods and many DOM render methods.

It means below fact.

• Server side developer has to know DOM structure, and send DOM from Scala.
• Client side designer has to know Scala to convert elements.

As @vn971 say, I think there are some tips to avoid it.
But many documents about Lift (Simply Lift, Lift cookbook etc) shows examples like above.It means that if you use Lift according to documents, it mixes client side and server side.

If all of your team member learned Scala, it is no matter (and ScalaJs is good choice).
But if not, it causes confusion.

Let me answer on some of the aspects you mentioned.

• about logic and view separation (server-side and designer). Well, it's like this: many other frameworks just inline the code, whereas for Lift it's sufficient to keep an HTML (again, not DOM) attribute the same.
• it's true, the server-side developer must have some knowledge on html structure it wants to touch
• it's not true that a designer has to write scala code. He just edits html keeping some attributes or id-s, that's all. It really works.
• I'm not a team member of Lift, if that's what you want to say. I only made a contribution to Lift once to add a small functionality. (I also contributed to SBT, squeryl and other libraries.)

Summing up, yes, Lift really strongly advises you to use trasformations like def showTime = "#time" #> myJodaTime.toString. But it's actually one of the things that keeps Lift strong and allows it achieve security and other goals. It's also the reason why the framework has such a strong separation of view and logic (Scala developer doesn't write HTML at all, designer doesn't write Scala at all).

…and here we go, first flame war on "awesomeness".
Perhaps Lift is a bit special, but it really shines in some aspects. For example, the security features are really awesome.
@lauris I strongly vote for re-including Lift on this list. Perhaps you might add some comment like "steep learning curve", because imo getting started with Lift isn't straightforward.

This is an interesting discussion and I think that it would ok to add Lift back. Probably with a reference to this discussion.

Removing Lift is bullshit. @icoxfog417's complaints about the framework are better summarized as using the wrong tool for the wrong job. There are parts of the framework I dislike (take the screens for instance. I hate those). They don't help me solve my problem, so I don't use them. If server-side DOM manipulation doesn't make sense for your project, then don't use that part. Wrong tool for the wrong job.

Besides, I would argue that JSPs, GSPs, whatever Play has, etc are exactly the same thing. The difference is Lift doesn't try to give you some half-logic/half-view semi-HTML crap to work in. Instead you can leverage all of the power of a real language to mutate the DOM to render the view for a given model.

Furthermore, it can make a phenomenal backend for angular (see lift-ng). Take a look at that plugin and you'll see the client and server can be well separated, securely connected, and powerfully working in tandem. No server-side DOM manipulation, but all of the power and security of the Lift framework

Besides, this notion that server-side developers should be divorced from the DOM is not always the right way to divide your work force anyway. My team is full-stack. We work in thin vertical slices, without arbitrary specialization about the application's architecture.

Apologetics aside, I don't think that one person's distaste for a library justifies its omission from an otherwise useful source of information.

I prefer Lift's tradeoffs to Play's. It's egregious that it's been removed from the list based on some-guy-doesn't-like-it. Maybe we should remove Scalaz too; I've read plenty of articles about silly people rewriting it out of apps for similar "reasons".

Ok, here we go: #66
@lauris please merge and close this discussion.

@Skyr I merged and added link to this discussion near the Lift entry.

See also #52

// disagreeing a little with Joe Barnes, I think @icoxfog417 meant a far more simple task of generating HTML. (Like with selector transformations.) But anyways..

I think that we should write/discuss about the situation that Lift adapts.

As @Skyr, @joescii say, Lift will have certain domain that works well.
And Also, I feel that to use Lift needs some more learning(@joescii said my mention is "parts of the framework I dislike", but that is basic way explained in many documents).

I'd still opt for removing Life, because David Pollak is a self-centered asshole who isn't interested at all in the bigger picture of the Scala community, and seems to thrive in competing with others in a agressive and anti-social way.

Ad hominem. This isn't a proposal to add David Pollack himself to the awesome Scala list. The Lift library should be judged on its technical merits. While far from perfect, Lift has several unique and valuable attributes that make a worthy alternative to Scala on Rails (Play) and other Scala libraries.

I agree with @japgolly, personalities of contributors should not be taken into account.
and in my opinion the Lift contributors has asked themselves and answered just about any problem you can run into while building a website, instead of play/rails type of frameworks, that follow the "do it our way or the highway" approach, although I'm very much in favor of play's non-blocking architecture

Firstly, I apologize for my strong comments earlier. I use Lift on a daily basis and contribute frequently to the community, plugins, and so forth. It has provided me tremendous value in my work, and seeing it omitted from an otherwise fine resource got under my skin a bit. I overreacted quite immaturely, and for that I apologize.

That aside, the last thing I'll say is if it gets omitted, @lauris will occasionally get a PR from other folks who likewise find it valuable. Hell, I'm enough of a smartass to write a script to send him one every afternoon. :) but... perhaps that's better than receiving endless comments from this flame war.

A couple of notes.

Lift has a very light-weight and Scala-esque REST system that uses pattern matching rather than type-less Strings to define REST: http://simply.liftweb.net/index-5.3.html#toc-Section-5.3 With pattern matching, the types of objects are reified as close to the wire as possible. This makes for more secure and well types REST endpoints than does the "define your REST endpoints via String" mechanisms.

Lift 3 has support for single page apps with no server-side HTML generation via seamless browser/server actors and streaming promises. Oh, and all of the stuff that's baked into Lift 3 for single page apps can be done in app-level code for any Lift 2.x app.

If you want to write server-generated HTML apps, Lift does that, although with a more secure and designer friendly templating mechanism than most other web frameworks (DOM manipulation vs. String output).

If you want to write apps that do pure client-side DOM manipulation, Lift has terrific features for that (REST, browser actors, streaming promises).

Or you can write apps that do whatever is in between.

In terms of the personal attacks against me (words like "asshole" are attacks, not facts), perhaps writing the first major framework/library, hosting the first Scala-specific Maven repository, writing the second (to Martin's first) Scala book, helping companies like Twitter, Foursquare, and LinkedIn become successful with Scala, and creating and promoting and producing the first four Scala-related conferences are not some people's ideas of contributing to Scala... but what I have or have not contributed to the Scala ecosystem should not be a criteria for judging if Lift, which sits under a number of the libraries listed in Scala Awesome including Spray (yep, Spray uses Lift's JSON library), should be listed as part of the Scala ecosystem.

I've worked with a lot of frameworks and I can say that Lift is awesome, and there is a team behind it (not just a person) working really hard and a lot of happy users.

My only wish that people join hands for greater good of community.