

Lift 2.1 ships - d_c
http://www.liftweb.net/21_ga

======
scalyweb
Glad to see they are now supporting Scala 2.8 but...

what happened to their website? I seem to recall a vastly different appearance
before. If the look of the Lift website is an indicator to first time visitors
of the quality of the framework, I wonder how many visitors don't get beyond
the initial landing page.

Here's what I noticed immediately in about a minute: -Not a lot of contrast
for colors to help material stand out -Lack of contrast leads to difficult
reading on tired eyes and I'm only 30 something -Page balance - Small main
content area compared to long running side panel -The quote box just looks ...
meh -No favicon -The icons of the groups/companies using the framekwork appear
to have a lot of artifacts in them

I really like Scala but this site redesign is probably not helping win new
users to the framework.

~~~
babo
Even the download tgz and zip archives are not available right now.

~~~
steele
<http://github.com/lift/lift_21_sbt>

------
shadowsun7
Is there an article about Foursquare choosing to use Lift over other
alternatives? The only ones I can find on the switch, at the moment are:
<http://www.scala-lang.org/node/5130> and
<http://java.dzone.com/articles/interview-lift-creator>

Edit: Nevermind, found the answer on Quora - [http://www.quora.com/Why-did-
Foursquare-choose-Lift?q=foursq...](http://www.quora.com/Why-did-Foursquare-
choose-Lift?q=foursquare+lift)

~~~
cageface
It's interesting that Foursquare sees Scala and Lift as a critical technical
advantage but Gowalla seems to be competing just fine with their Rails stack.

~~~
al3x
You might want to back up "competing just fine" with something.

Numbers on Compete
(<http://siteanalytics.compete.com/foursquare.com+gowalla.com/>) suggest that
Foursquare is pushing quite a bit more traffic than Gowalla, at least on the
web. Most reports suggest that Foursquare is also beating out Gowalla in terms
of users.

(Full disclosure: I have friends at Foursquare, Gowalla, and on the Lift
project. I don't really care about any one of them "winning", I just like
facts.)

~~~
cageface
I guess I was speaking more anecdotally, in terms of both sites providing
roughly equivalent functionality and supporting non-trivial load. Thanks for
the analytics link though. I didn't realize the traffic disparity was that
high.

------
steele
Lift has the most natural comet abstraction I've used, but using lift's 1.0
ORM felt a little raw and the API has a steep learning curve. The sheer amount
imports at the top of a class can get ugly, especially when working w/ heavy
javascript. While waiting for 2.0 to have some more documentation and Record
to replace Mapper, I've looked at some of the Play! Framework which seems to
very straightforward scala support. Abandoning HttpServlet makes me nervous
and response streaming isn't supported (no real comet), but Play! is a really
refreshing web framework w/ scala support. Don't expect all forms of scalate
to work though despite having a module for it.

I don't have any issues w/ the new liftweb site look and feel. That shouldn't
be a deal breaker for a quality web framework. For example, HN seems to have a
large hadron collider over clojure -- anyone remember what the non-github
compojure website looks like?

Anyone have any success w/ the tar/zip link on the liftweb download page?
Broken links for me; sad panda. :(

~~~
cageface
Lift and Play! embody very different philosophies of web development, but if
you want something closer to the common MVC frameworks Play! is very nicely
done.

~~~
steele
Well if you mean Model/Controller/Route first vs View first, yes they are
philosophically different. But I meant more along the lines of how friendly
the API is. An additional example would also include the fact that although
Lift has come a long way in providing meaningful error information, by
contrast Play!'s take on it is just a breath of fresh air. This isn't to say
that Lift is doing it wrong; it's error messaging is less arcane than some
other web frameworks.

~~~
cageface
I agree that Play shows a lot of polish and attention to detail. I haven't
done anything significant with it but it was very pleasant for the few simple
things I tried.

------
abp
I didn't know about <http://squeryl.org/> before seeing it in the new feature
list.

Seems like it could be valuable competition for <http://scalaquery.org/>

------
narrator
I've been working with Lift a bit. It is very different from any other web
framework I've ever used. That said, there's some real brilliance in it,
especially how Comet and Ajax work. Lately, it's gotten a lot easier to work
with, as the IDE has gotten into a usable state.

The learning curve is pretty steep though. You have to learn Scala, The Java
APIs and the non-traditional approach to web development that Lift takes.
That, and it's a young ecosystem. There aren't 101 e-commerce shopping cart
systems written in it yet.

~~~
d_c
Which IDE do you use?

~~~
tyweir
If you're an Emacs user, look into Ensime, it's fantastic.
<http://github.com/aemoncannon/ensime>

------
joevandyk
Thing that bugs me about Lift (last time I looked) is that it only supports
sticky sessions. If the server your session is on goes down, you lose your
session.

Is there a way around this in Lift yet?

~~~
SkyMarshal
David Pollack, Lift founder, has this to say about sticky sessions and scaling
(paragraphs added):

 _"In practice, scaling a Lift site is much much easier than scaling a LAMP
site. Why? Well, state exists someplace. If it exists in the JVM, you get a
lot of performance benefits and stability as well as, in Lift's case, lots of
security.

Contrast that with sessions in memcached. "Whoop, memcached went down, there
go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm,
there go all the session." "Whoops, Google just crawled us creating 200,000
new sessions pushing all the but the active sessions out of cache." "Whoops,
the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached
went down..."

So, you try storing sessions in some wacky shared version of MySQL. This
solution requires tons of hardware and a team of make sure that the sharing
code is correct, etc. Contrast that to using Nginx, Jetty and session
affinity. It's about 4 hours of setup time and it just works. See
<http://blog.harryh.org/post/7550...  >

So, talk to a Facebook engineer about the challenges they go through to manage
state between the front end, memcached, MySQL, etc. Compare that to Twitter
with the famous fail whale. Compare that to Apple's store and the iTunes store
which are written on WebObject (which is highly stateful.)

Lift apps running at scale typically require 7% of the front end resources of
LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse
are two) do not have the kind of scaling issues associated with LAMP sites
that have similar traffic patterns. Scaling with Lift is neither tricky, nor
risky. It's simple. It's known. It's proven. Scaling with LAMP is playing
whack-a-mole with state and that only becomes a problem at scale."_

See his comment under Jackson Davis's answer to this question:

[http://www.quora.com/What-are-the-advantages-and-
disadvantag...](http://www.quora.com/What-are-the-advantages-and-
disadvantages-of-writing-a-web-app-in-Scala-using-Lift)

~~~
nl
Is there any reason why session replication wouldn't work? It works ok on
Tomcat (<http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html>) and
Jetty has support too.

(I've never use Lift or Scala.)

~~~
SkyMarshal
I don't know, but that would be a good question to pose on Quora, where David
seems to frequent.

------
swah
So, whats the easiest, tested way for a Django programmer, outsider to the
Java world to write a site running on the JVM?

~~~
cageface
Probably Rails with JRuby. Install rvm, use rvm to install jruby, then install
rails via jgem and you're ready to go.

Sinatra would be even easier if you're doing something simple.

Edit: very curious as to the reason for downvotes on this. If you have a
better answer, give it.

