Firstly, Lift is not Rails. It really bugs me when people are like "oh, well
rails does XYZ". Its apples and oranges in many respects - especially when you
consider the ages of the respective projects... Lift is much, much younger than
Rails. Moreover, Lift is a very advanced framework -more so than its
competitors- and we are working on distilling the experience for people who new
to the ecosystem. We have invested a massive amount of time in Lift over the
past 3 years, and yes, we have prioritised features in production systems over
the introductory experience for newbies. Personally, I think this will make us
more mature when Lift reaches critical mass so in this way its no bad thing...
I am currently writing a 500 page book on Lift, and I hope it will fill the
vast documentation gap that currently exists in the community. We know its a
problem, but don't be naive enough to think that we don't know its a problem -
the Lift team has some of the finest engineers and researchers around and a
number of us have come from doing all manner of other frameworks and so
forth... we understand the issues and rest assured they are being addressed. I
am currently collaborating with Mark @ SBT on a processor system that will give
us a more flexible "getting started" system than even Rails or Django.
By all means, come here with questions and you will find this group to be very
responsive and helpful, but do not come here and automatically assume that you
can illuminate to us the errors in our project marketing or experience.
Cheers, Tim
PS: "Who uses PDF?"... easily one of the funniest things i've read this year.
PDF is the format for electronic document communication. Hundreds of millions
of dollars a year are spent on PDF-based technology.
On 6 Mar 2010, at 04:43, cageface wrote:
> Like many other web developers, I abandoned some heavyweight Java web
> frameworks about 6 years ago for Rails and have been working pretty
> much exclusively in Rails ever since. However, I've always had a
> secret lust for functional languages so when I heard about Scala and
> Lift I decided to take a closer look. My first impression of the
> community from studying this list and many other blogs, articles etc
> is that it's a group of smart, dedicated folks that have generously
> dedicated a lot of time and energy to making Lift a first-class
> alternative to the more conventional options.
>
> However, my first brush with the framework itself has so far left a
> very different impression. I think one of the reasons Rails caught on
> so quickly in the beginning was that it was marketed brilliantly. DHH
> made Rails look so simple, stylish and intuitive that anybody drowning
> in the bulk and complexity of Java web dev at the time couldn't help
> but take notice. Lift, in contrast, and particularly for anybody with
> a prior history in Java, seems very daunting and rough. The following
> impressions are very much superficial first impressions and may really
> have no deeper substance than that but I think first impressions count
> for a lot in this sphere.
>
> First, the liftweb.net site is nice. It's a clean, elegant,
> contemporary design. So far so good. Let's click on "getting started".
> What's this? PDF? Who uses PDF? Nevermind, let's look at the HTML.
> Gack! This looks like an academic LaTEX conversion from the 90s.
> Layout and formatting are next to non-existent. This doesn't look like
> the intro for a simple, ready-to-use tool.
>
> Oh well, pushing past the wall of text intro we discover that we need
> Maven. Alarms are starting to go off in the heads of many Java
> refugees that remember Maven as the nadir of the XML-situp
> overabstracted agony that was pre-Rails Java web dev. I imagine many
> people have signed off by this point. We go download maven and press
> on to the first actual command we can run, which is an impressively
> cryptic 8-line mvn invocation that seems to take about 10 minutes to
> download every single apache and codehaus jar file.
>
> When this finally winds down we start the server and take a look at
> our homely start page and bounce back to the docs. XHTML. Hmmm. Didn't
> everybody give up on that a few years ago? HTML literals *in* the
> code? All the "snippets" we're going to be editing live six levels
> deep in the project directory structure? This will be fun with emacs/
> vim...
>
> By this point our enthusiasm is seriously waning but our dreams of an
> expressive but statically typed platform keep us going on to the next
> section anyway. We begin with another mvn invocation that mysteriously
> fails. After futzing with it for a bit and googling around we discover
> that there are spaces following each of the \ line continuations so we
> copy and paste the whole thing into a file, clean it up, and invoke it
> via sh. After this finishes we create the first model, which actually
> looks pretty reasonable, similar to a Django model with a little more
> boilerplate but nothing too intimidating. We discover to our chagrin
> that we're going to have to manually add each model to the toplevel
> Schemifier invocation in Boot.scala, which makes us grumpy. We skim
> through the explanation of the views and we're not sure what to make
> of the html binding approach. On one hand it looks pretty precise. On
> the other hand it suggests an even tighter straightjacket than Django
> templates. We reserve judgement.
>
> We work through the next few instructions to come to the creation of
> TD.scala only to be greeted by a *19* line file header:
> package com.liftworkshop.snippet
>
> import com.liftworkshop._
> import model._
>
> import net.liftweb._
> import http._
> import SHtml._
> import S._
>
> import js._
> import JsCmds._
>
> import mapper._
>
> import util._
> import Helpers._
>
> import scala.xml.{NodeSeq, Text}
>
> And at this point we give up and start quickly paging through the rest
> of the tutorial only to come to this:
> object priority extends MappedInt(this) {
> override def defaultValue = 5
>
> override def validations = validPriority _ :: super.validations
>
> def validPriority(in: Int): List[FieldError] =
> if (in > 0 && in <= 10) Nil
> else List(FieldError(this, <b>Priority must be 1-10</b>))
>
> override def _toForm = Full(select(ToDo.priorityList,
> Full(is.toString),
> f => set(f.toInt)))
> }
>
> and we suddenly find a new appreciation for :validates_numericality_of
> and we also wonder why our model should be specifying it's
> representation in the form and we decide to go googling for whatever
> the Scala equivalent of Sinatra is.
>
> I apologize if this seems flippant but I really think that a lot of
> people won't even push on this far, never mind having to do the
> homework of learning the basics of scala first. I know that docs and
> introductory materials aren't usually that much fun to work on and I
> can imagine that the framework itself is much more polished and
> sophisticated but as potential recruiting material I think this just
> isn't very good.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
