Even if Lift isn't dead, it sure looks that way

[Tom]

My reasons:

- no website updates for over a year
- David wasn't on  Github for over 4 months
- only minor contributions to the core, with no plans to make new releases (AFAICS)


Maybe it is just that David has other stuff to do or has to deal with RL or something, but at least there should be some communication on how to resolve these issues or it needs a fork.

Otherwise Lift will die a slow death (maybe very slow, but it will die eventually) IMNSHO  I am just telling it like it is.

Cheers,

- Tom -

[Regis Blanc]

I'm not a contributor to Lift and don't really know much about the internal state, but as a user I have been extremely happy with Lift. It's extremely stable, and whenever you have a question you always get an answer in this forum. I am using other Scala libraries, supported by typesafe (or lightbend), and I keep discovering bugs, and get much less support on their forum than on the Lift one. Very recently I asked a question on Lift, got an answer in 10 minutes, and was able to fix my problem cleanly. In contrast, I had a serious issue with Slick so tried to ask for a solution, still waiting for an answer 1 month later.

So I don't know what dead means for a software, but a software that does the thing it's supposed to do correctly, is stable, and has an active community that can help with any potential issue, I would happily use it. And in fact, I recently started a new project for a start-up, and I've decided to use Lift once again.

Besides, I believe a lot of work is being done on Lift 3, so as far as I know, a new release is planned.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[DoomPirate]

I'll do everything in my power to prevent it from dying because I am banking my career on a scala/lift platform I have been creating.

I find the forum incredibly useful and I have always gotten the help I need from a member.

Updates are being made as far as I know. Other people are making contributions that are not David.

[Andreas Joseph Krogh]

På tirsdag 15. mars 2016 kl. 10:34:00, skrev DoomPirate <nguyen....@gmail.com>:

I'll do everything in my power to prevent it from dying because I am banking my career on a scala/lift platform I have been creating.

I find the forum incredibly useful and I have always gotten the help I need from a member.
 

Updates are being made as far as I know. Other people are making contributions that are not David.

 

FWIW, we\re using Lift extensively in a product which we'll have to support for 10+ years and I'll make sure it doesn't die either:-)

We've used it now for 4 years and have no plans to abandon it.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[Diego Medina]

Hi Tom,

See comments inline:

On Tue, Mar 15, 2016 at 3:42 AM, Tom <t0m4...@gmail.com> wrote:

My reasons:

- no website updates for over a year

while we haven't published updates to the site (one of these days I'll update the releases section, just need to make some time for it), we have been publishing all new releases on github at

https://github.com/lift/framework/releases. If you scroll past the draft we have to 3.0, you will see the last release was on Jan 31. Are we are very close to publishing RC1, just need to fix one bug that was recently reported.

 

- David wasn't on  Github for over 4 months

While David is the founder of Lift, he isn't Lift itself. I know most projects die once the founder isn't active any more, but luckily, Lift is a different kind of project and we have  been able to continue the project even though he had other priorities.

 

- only minor contributions to the core, with no plans to make new releases (AFAICS)

Most likely you missed all the changes that have gone into 3.0, but please take a look at the link I posted, and you will see a large number of fixes and new features. OTOH, Lift got a lot of ideas right the first time, one example is when the BREACH vulnerability was found, many frameworks were affected by it and had to either make changes or start telling their users to setup their sites in a different way, with Lift, you don't have to do anything different, see http://www.liftweb.net/lift_and_breach for the details.

 

Maybe it is just that David has other stuff to do or has to deal with RL or something, but at least there should be some communication on how to resolve these issues or it needs a fork.

I'm pretty sure we don't have an issue, but if you do want to do something for Lift, it would be awesome if you could send a pull request to https://github.com/lift/cms_site to update the releases section with all the missing releases.

 

Otherwise Lift will die a slow death (maybe very slow, but it will die eventually) IMNSHO  I am just telling it like it is.

Just so you know, people have been saying Lift will die a slow death for the past 5 years, and we are still here, alive and well :)

And before I forget, like others have said on this thread, Lift works really well, we also use it at work for a system that handles compliance, communications and trading data/analysis and we currently have 3 full time committers, and two part time committers working with us (and a few other developers).

Thanks and look forward to your contributions.

Diego

-- 

Compliance is a corporate asset.  Manage it more effectively with ACM.

Diego Medina

VP Engineering

https://www.ascendantcompliancemanager.com/

 

Cheers,

- Tom -

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[Diego Medina]

.... And in fact, I recently started a new project for a start-up, and I've decided to use Lift once again.

Great news!

@DoomPirate, @Andreas: To many more years using Lift! :)

[Flavian Alexandru]

Just throwing my 2 cents in here:

• Lift is still guilty of very innocent little bugs like 3.0-M6 still not running under Tomcat 8 thanks to a regression from 2011/2012. Details here. Not the end of the world but its the kind of oopsie you shouldn't have in a big framework. This is one brilliant example of an afternoon spent in the company of logs looking for bs bugs.
  
  
• Documentation is still a fundamental issue. The new content security policy implementation however rightfully done, was one hell of an afternoon figuring out the automagical triggers Lift uses to turn the behaviour on and off. Again, just a super small example. Every google hit is cca 2008 - 2011 pointing to APIs either long long deprecated or nowadays non-existent.
  
  
• A lot of the primitives like LAFuture should really not exist in my honest opinion, introducing concurrent primitives for no apparent reason is not fun, same goes for actors and so on. I agree you are maybe specialising some of the items there, but you are also limiting a great deal of adoption in doing so, give people what they are used to.
  
  
• There is still no proper asynchronous support, making Lift mostly useless for very very large applications. Netty and all the fun stuff. Getting Lift fully stateless is also a pleasure reserved to the most stubborn of developers, with some acquired taste for pain.
  
  
• It's riddled with bs features hard to get rid off, like processing `on` attributes when no one asked it to. Introducing a jQuery dependency and some comet.js stuff out of thin air. Introducing 50 ways to get rid of it.
  
  
• The whole record stuff, the 2005 blocking I/O and all that is unfortunately very very out of date, having personally written database drivers used worldwide, I can say in full honesty there's huge room for improvement in that territory. 
  
  

To sum it all up, I think the potential may still be in here, but very rapidly degrading. However great some bits are, Lift is constantly shooting itself in the foot through massive lack of documentation, very limited adoption compared to its competitors, and no strong commercial muscle behind Lift like other frameworks have.

I know DPP didn't like getting mixed with Typesafe back in the day, and it's a choice he was entitled to make, but it cost the eco-system tremendously and it was probably not the right move for the well being of Scala developers in general.

At the time and even nowdays in many ways, Lift is vastly superior to Play, with no bs Twirl compiler and shitty ways to define routes and reverse routes and a whole bunch of completely unnecessary headache, but Play is a great deal more well documented, manageable by lower end engineers, with native async support and a whole eco-system of up-to-date active plugins and extensions a community is working on, which sadly is missing in Lift.

No point in looking backwards, but maybe looking to the future some of the goals on that list are attainable.

[Matt Farmer]

Did anyone else notice the email address is "Tom Arnold" once you account for all the digits?

https://en.m.wikipedia.org/wiki/Tom_Arnold_(actor)

;)

That said, I'll echo that Lift is not dead. We are in the situation of not having people on payroll whose job is to just work on the framework and things the framework needs. 

There are good aspects to that, fwiw. Our objectives aren't split between corporate interests and the good of the framework. But you did highlight an area that we could stand to improve on: our website and communication. But the flip side is Lift is maintained by volunteer effort. Sometimes we all get busy. And I at least spend what time I have actually working on code. 

I don't know if this is secret or not - but Antonio has been doing some work on what a redesign would look like there. I've gotten a peek at it and I'm stoked.

Also, don't count David out yet. He's tweeted at least once about getting back into the fray. :)

Cheers!

—
Matt Farmer | Blog | Twitter

GPG: CD57 2E26 F60C 0A61 E6D8  FC72 4493 8917 D667 4D07

[Matt Farmer]

Responding inline.

On Tuesday, March 15, 2016 at 8:42:42 AM UTC-4, Flavian Alexandru wrote:

Just throwing my 2 cents in here:

• Lift is still guilty of very innocent little bugs like 3.0-M6 still not running under Tomcat 8 thanks to a regression from 2011/2012. Details here. Not the end of the world but its the kind of oopsie you shouldn't have in a big framework. This is one brilliant example of an afternoon spent in the company of logs looking for bs bugs.
  

FWIW, these oopsies exist in Play as well, unfortunately. I've spent some time debugging a few of them. But you're right. I've responded to that thread to bump it. Let's see if anyone else has been working on it. If you have an idea about it, I'd be very interested to see a PR. I think most of us have worked with Jetty.

• Documentation is still a fundamental issue. The new content security policy implementation however rightfully done, was one hell of an afternoon figuring out the automagical triggers Lift uses to turn the behaviour on and off. Again, just a super small example. Every google hit is cca 2008 - 2011 pointing to APIs either long long deprecated or nowadays non-existent.

Yeah, let's fix that. I mentioned that Antonio is working on a new site, but perhaps we can work on consolidating our documentation before then.  

• A lot of the primitives like LAFuture should really not exist in my honest opinion, introducing concurrent primitives for no apparent reason is not fun, same goes for actors and so on. I agree you are maybe specialising some of the items there, but you are also limiting a great deal of adoption in doing so, give people what they are used to.

If I recall, these classes predate their current scala implementations. That said, we've been working in Lift 3 on supporting Scala futures and LAFutures equally. I think it's a logical possibility to unify some of those things over the next several releases, but some (like LiftActors in particular) I think are sometimes easier to reason about than the standard alternative (e.g. Akka). 

• There is still no proper asynchronous support, making Lift mostly useless for very very large applications. Netty and all the fun stuff. Getting Lift fully stateless is also a pleasure reserved to the most stubborn of developers, with some acquired taste for pain.

Lift isn't designed to be stateless, so you're fighting the framework a bit there. Sorry, but the statefulness is where part of the power comes from. I don't know what, exactly, proper async support would look like for you. Is there a thread where you've discussed this? 

• It's riddled with bs features hard to get rid off, like processing `on` attributes when no one asked it to. Introducing a jQuery dependency and some comet.js stuff out of thin air. Introducing 50 ways to get rid of it.

I don't understand what each of these is referencing. Well I get what the jQ dependency is referencing. But the others seem vague.

• The whole record stuff, the 2005 blocking I/O and all that is unfortunately very very out of date, having personally written database drivers used worldwide, I can say in full honesty there's huge room for improvement in that territory. 

Are you volunteering to contribute? :) 

 

To sum it all up, I think the potential may still be in here, but very rapidly degrading. However great some bits are, Lift is constantly shooting itself in the foot through massive lack of documentation, very limited adoption compared to its competitors, and no strong commercial muscle behind Lift like other frameworks have.

I know DPP didn't like getting mixed with Typesafe back in the day, and it's a choice he was entitled to make, but it cost the eco-system tremendously and it was probably not the right move for the well being of Scala developers in general.

At the time and even nowdays in many ways, Lift is vastly superior to Play, with no bs Twirl compiler and shitty ways to define routes and reverse routes and a whole bunch of completely unnecessary headache, but Play is a great deal more well documented, manageable by lower end engineers, with native async support and a whole eco-system of up-to-date active plugins and extensions a community is working on, which sadly is missing in Lift.

No point in looking backwards, but maybe looking to the future some of the goals on that list are attainable.

I certainly think things on that list are attainable. But it's going to take people getting pissed off and lending a hand. And maybe it's time to consider changing how be bring people into that process. Lift has historically been very conservative on that front for Intellectual Property reasons. I think our official policy is to still only accept minor contributions from non-committers which has miffed a number of folks.

[Tom]

Hey, thanks for all the answers.

My 2 cents:

Just make the website and the blog integrate https://github.com/lift/framework/releases. That way there is always new stuff on those sites and the project looks much more alive.

Cheers,

- Tom - (not the actor)

[Antonio Salazar Cardozo]

At this point I almost relish posts to the ML that Lift is dead, because

it brings out a litany of encouraging folks using it and loving it. It's a

better sign of life than anything else could be, for me :)

That said, some criticisms along the way bear addressing, and I'll

cover my thoughts where they differ from Matt's excellent response:

On Tuesday, March 15, 2016 at 8:42:42 AM UTC-4, Flavian Alexandru wrote:

• Lift is still guilty of very innocent little bugs like 3.0-M6 still not running under Tomcat 8 thanks to a regression from 2011/2012. Details here. Not the end of the world but its the kind of oopsie you shouldn't have in a big framework. This is one brilliant example of an afternoon spent in the company of logs looking for bs bugs.
  

The truth is, we lean on our community a little more than many frameworks

because, as you mention below, there is no commercial unit that pays people

to work just on Lift. As such, posting something in the middle of the summer

can rarely require a second poke—usually best delivered with, say, an example

project that shows the bug's manifestation.

Certainly I'm not happy that this regression showed up, and I'm disappointed

that it didn't get a reply (I try to make sure it's rather hard to find a post in the

ML that doesn't have at least a request for additional information, and that's a

blatant example). As Matt mentioned, however, I don't think we're doing

particularly worse than dedicated teams much larger than our committers.

We would, of course, love to do better, so thanks for pointing out this particular

instance of a broader issue.

Worth noting: it feels like many folks have been moving towards Lift 3 slowly. This

is to be expected, but will probably mean that it will be a slightly buggier release

than the 2.x point releases. I anticipate we'll be ready to put out some patch releases

to deal with things that shake out as the initial wave of folks upgrade to a stable release

in the near future.

• Documentation is still a fundamental issue. The new content security policy implementation however rightfully done, was one hell of an afternoon figuring out the automagical triggers Lift uses to turn the behaviour on and off. Again, just a super small example. Every google hit is cca 2008 - 2011 pointing to APIs either long long deprecated or nowadays non-existent.
  

I won't disagree about documentation. It's a hard thing to act on, and it's the

biggest piece that we ask the community to help us with. Right now we're focused

on getting Lift 3 out the door. I would like to try and make documentation my focus

for Lift 3.1, if the stars align correctly.

Even in Lift 3, however, we had fairly significant cleanups of Scaladocs, and I know

most of the new code written in the last year or two has had detailed Scaladocs

attached to it. Incidentally, all of the SecurityRules stuff is included in that—and to

some extent those Scaladocs can act as basic documentation for the underlying

browser/HTTP info too.

Additionally, Lift 3 has more source content for documentation than any previous

release, thanks to well-discussed ML posts that are linked in to detailed PRs that

are in turn linked in to reasonable release notes. So the material is there, even

though it hasn't been pulled together yet.

• A lot of the primitives like LAFuture should really not exist in my honest opinion, introducing concurrent primitives for no apparent reason is not fun, same goes for actors and so on. I agree you are maybe specialising some of the items there, but you are also limiting a great deal of adoption in doing so, give people what they are used to.
  

I think we view Lift's actor/future implementations as saner, simpler implementations

of Scala's primitives. That was their original goal (really, originally they were meant

to be saner, simpler, and actually work, since Scala's early actor iterations were

incredibly buggy), but it remains true today IMO. No weird execution context implicit

complexity that leads to defining how your stuff runs separately from where it's

instantiated, etc. No actor systems. Just the bare bones, with an API that means you

can upgrade to the heavy hitting stuff if and when the occasion calls for it.

 

For what it's worth, Lift's concurrency stuff has largely been unchanged for years,

because it just works (LAScheduler's tendency to stick around after it's no longer

wanted notwithstanding ;) ). It's also, as with many of Lift's moving parts, entirely

optional. This includes, as Matt mentioned, making sure that additional LAFuture

support in Lift 3 also included making it work seamlessly with Scala Futures.

• There is still no proper asynchronous support, making Lift mostly useless for very very large applications. Netty and all the fun stuff. Getting Lift fully stateless is also a pleasure reserved to the most stubborn of developers, with some acquired taste for pain.
  

Re: asynchronicity: I'm guessing you specifically mean support for non-blocking

web servers, rather than the asynchronicity which is baked into Lift pretty deeply

(though admittedly much more deeply in Lift 3, which isn't out the door but will

be very soon). We've largely not needed it, which is why it hasn't been worked

on. Indeed, even async IO for databases and such is indirectly supported through

direct and indirect servlet continuation support in RestHelper and CSS selector

bindings in Lift 3, in addition to expansions to the comet and async REST work

that existed in Lift 2.6 and much earlier.

• 
  
• It's riddled with bs features hard to get rid off, like processing `on` attributes when no one asked it to. Introducing a jQuery dependency and some comet.js stuff out of thin air. Introducing 50 ways to get rid of it.
  

Lift is secure by default. This is one of its core principles, and guides development.

One of the assessments we made in Lift 3 was how we could leverage new browser

technologies to make Lift even more secure out of the box than it had been in

previous releases. The end result was the new SecurityRules setup that allows

the application to specify a whole host of improved security controls. Event attribute

extraction was a core part of this, since event attributes are a key vector for

cross-site scripting and hijacking attacks.

If you want to write an application that doesn't follow current security best practices,

it's going to be harder. But that's nothing new for Lift—indeed, it's one of the things

that distinguishes it from many other frameworks. The happy path is the secure path,

whenever we can make it that way. You won't see me apologizing for that; indeed,

you'll see me actively advocating against a different path.

Incidentally, there is no jQuery dependency. Comet JS is not new, it's been around

for more than 6 years, it's just been moved into the same file as Lift's base AJAX stuff

for easier serving and because it adds relatively little extra file overhead and almost

no execution overhead if you're not using it.

• The whole record stuff, the 2005 blocking I/O and all that is unfortunately very very out of date, having personally written database drivers used worldwide, I can say in full honesty there's huge room for improvement in that territory. 
  

I don't know much about record/mapper/etc, but you're right that not a lot of time

has been poured into them lately. They're also completely separate from Lift's

utilities, its common package, and its web stuff, so you can leave it if you prefer

to (many people do; for example, we use our own internal system at work).

On a different note, someone I know was recently looking at Scala database

libraries and found Lift's to better support several of the core needs they had.

Lift's db stuff has chosen a very specific set of approaches that I think are not

necessarily common, but seem to be useful for folks who need them.

To sum it all up, I think the potential may still be in here, but very rapidly degrading. However great some bits are, Lift is constantly shooting itself in the foot through massive lack of documentation, very limited adoption compared to its competitors, and no strong commercial muscle behind Lift like other frameworks have.

We'll have to agree to disagree. Shooting oneself in the foot requires active effort

to do any of the things you're talking about. We simply don't have time to do those

things because we are actually using Lift to build real products. So it's true, the

adoption is lower than it could be if we had someone being paid to work on Lift. And

it's true, the documentation is worse than it could be if we had someone being paid to

write documentation. But I see no degradation of “potential”. Lift is good, now. It's been

good for years, and it's why we're using it at Elemica and why it's being used wherever

it's being used. It's stable, which is more than many frameworks can say, and it's

a better choice for long-term development than many other frameworks as a result.

Indeed, to that end, the fact that its development is a touch slower is an advantage.

 

At the time and even nowdays in many ways, Lift is vastly superior to Play, with no bs Twirl compiler and shitty ways to define routes and reverse routes and a whole bunch of completely unnecessary headache, but Play is a great deal more well documented, manageable by lower end engineers, with native async support and a whole eco-system of up-to-date active plugins and extensions a community is working on, which sadly is missing in Lift.

If everything sucks one way or another, then it's really just about making tradeoffs.

The circumstances around Lift (we're committers with additional jobs) have made us

pick a different set of tradeoffs than the circumstances around Play. The principles

around Lift (secure by default, view-first) have given us very different strengths than

Play and other frameworks. We embrace those differences.

All of that said, thanks for laying these out. It's always good to see critical feedback

and assess whether it's something that can be acted on immediately or at all. I think

Matt laid out some good ways forward, some of which were already in the works.

Thanks,

Antonio

PS: Using David's involvement as a barometer of the Lift project's health is not only

incorrect, it's actively overlooking one of Lift's strengths. Many projects fare poorly

when their founders step back. Lift has instead continued to be actively developed

and actively supported, despite the fact that various things have kept David busy

over the past couple of years. This gives him the space he needs to improve and

grow his own life without fearing that Lift will fall apart in his absence, and it gives

the community the opportunity to really absorb the founding principles that he built

the project on, and start creating a community identity instead of a cult of personality.

David's transition of the project to shared governance has been one of Lift's (and

David's) most underrated successes, in my opinion. We now get to leverage his

significant knowledge when he has the time to give it, while continuing to advance

even in his absence.

[Antonio Salazar Cardozo]

On Tuesday, March 15, 2016 at 12:38:28 PM UTC-4, Tom wrote:

Hey, thanks for all the answers.

My 2 cents:

Just make the website and the blog integrate https://github.com/lift/framework/releases. That way there is always new stuff on those sites and the project looks much more alive.

That's one of the things that's been on my docket for after Lift 3 gets

released… Granted that's taken a bit longer than intended ;)

Thanks,

Antonio

[David Pollak]

Folks,

Just a couple of things. In January, I joined kiva.org as VP Engineering. I'm currently shepherding three of Kiva's most ambitious projects ever to completion. I'm a bit busy.

More broadly, I moved out of the BDFL role 4ish years ago. One of the truly amazing things about Lift is that it survived the founder moving from the BDFL role to a contributor role and the project continued to thrive. How many other open source projects have made that transition?

In terms of bugs... yeah... Lift has them. The number of critical bugs... the number of dot dot releases of Lift is insanely few compared to any other 50K+ LoC software project.

In terms of LAFuture and other Lift-isms. These were added before Scala had support for these features and before Scala had any kind of reasonable support for these features. Take Lift's Actors... I spent years trying to get EPFL to clean up bugs in their actor implementation... then I wrote an implementation for Lift and that cleared the way for Jonas to write Akka actors... and if you want to see the poop-storm that my transgressions engendered... just search this list for Martin's comments on the Lift Actor implementation.

Yeah... do I wish we could have gotten Lift 3.0 out the door on Feb 28th to celebrate Lift's 9th birthday? Yes. Do I wish a unicorn would bring me lunch? Yes.

At the end of the day, the most important part of Lift is the community. The fact that volunteers give faster and better answers on the Lift mailing list than you can get from paid support contracts is a hell of a good indicator that Lift is alive and well.

Okay... back to my day job.

Thanks,

David

PS -- y'all feel very encouraged to make a loan on https://kiva.org ;-)

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Twitter: http://twitter.com/dpp

Empower people around the world with a $25 loan http://kiva.org

Lift, the simply functional web framework http://liftweb.net

Blog: http://goodstuff.im

[John Michael Lafayette]

As a novice who is picking a web framework for his personal site, the home page of the framework's web site has a big impact on me. I want a website that will look great, and I see a website the looks lame, and it dissuades me from picking that framework.

You want a website that is as cool as your framework. HTML5 canvas. Mobile and desktop.

You want the website to take up the whole space instead of leaving big gaps.You want hover-over drop down menus with an arrow that inverts itself when the drop-down menu opens.

ONLY READ THE BELOW SECTION IF YOU CARE FOR DETAILS ON HOW I WOULD DO IT

For something like:

Taking Off

Get started with Lift. Build your first interactive Lift-powered app.

I would make the entire div clickable instead of just "Taking Off".

Whitespace has got to go. Your web page is your canvas and white space is unused canvas. I would fill it with pictures - Lift in the IDE, example of a running lift site (with link on GitHub)

Even the example Lift site should look cool.