Thanks for your comments. I did Ruby/Rails for 2 years until I found Scala in November 2006.
Please allow me to rebut your thoughtful post. On Fri, Mar 5, 2010 at 8:43 PM, cageface <[email protected]> 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. Back when I was doing Rails, the state of Rails' documentation was not materially different from the current state of Lift's documentation with the exception of DHH's awesome book (which is my all time favorite tech book). Most of the online documentation was weak or non-existent. It was never possible to figure out what mixins impacted the behavior of a class. I spent most of my time reading Rail's source to figure out how to do anything that marginally off the beaten path. > 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. This is one of the things I wanted to do differently with Lift. I didn't want to "market" it. I wanted to build solid technology that addressed serious needs including security, highly interactive apps, and scalability. I also wanted to create a welcoming community (Warren does not represent this community except for his brains which were missing last night when he wrote his snarky response) so that the adoption of Lift would come from substance, not a pile of fanboys (this is not a reference to you) who were not able to see past the flaws in Rails. > 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. It depends on what you want to do. One of the problems I found with new Rails apps was that they were ugly and unstyled. We adopted Blueprint CSS as a default for Lift projects so at least they looked clean. Further, Lift's templating with "surround" makes it much easier to swap out better looking sites. My experience doing Rails (remember, this goes back 5 years, so this situation may have changed) was that I spent the first hour of any project doing the layout. The second issue with Rails apps is when you do them "easy" they tend not to be secure. When I say secure, I mean this kind of secure: http://twitter.com/rasmus/status/5929904263 When you protoype in Lift, you get secure by default. You don't have to have the "security sprint" or other stuff after prototype stage to "get things right." > 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. > While I agree, that early impressions are important. But at the same time, Lift is unabashedly different. It's different for reasons and those reasons are often borne out of experience. It takes some time to get used to the differences. My goal with the getting started guide was to set up ET-style Reese's Pieces so that the reader would get a sense of success and a sense of Lift's difference and benefits. I'm sorry that the pieces didn't taste good to you. ;-) > > 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? While I'm not sure I 100% agree with Tim's "6 million dollar man" argument about PDF, PDF is common and useful... Scribd (which is definitely in the hip-cool-kids side of street) is built on 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. > Okay... sorry... but this is a gratuitous swipe. Ugly == Not Easy to Use. Nope. Sorry. I don't buy this. > > 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. We are not in the build tool business. When we started with Lift, the options were Ant and Maven. You can read this list for the occasional anti-Maven flare-up. I stand by the decision. Currently, there are a couple of alternatives to Maven. There's Buildr on JRuby and Simple Build Tool (sbt). But Buildr on JRuby wasn't an option when I started Lift (it became an option 18 months ago), but AFAIK, there's no IDE support for Buildr (you can't "open" a Buildr project in an IDE, you have to manually configure the project and the dependencies.) sbt was not mature enough for serious use until their 0.5 release. sbt is growing very, very nicely. We will be moving to sbt post Lift 2.0, but right now, Maven is the best option as a default. > 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. > Yeah, I wish there was a better solution to the first issue (the long, ugly Maven invocation to build a project). The second point is dead wrong. Every Rails job I worked on required tremendous configuration pain. On my most recent Rails-related job (this was 18 months ago), I spent a day configuring my machine with the right Gems and the right versions of the right Gems. The fact that Maven gets it right without having to do anything other than adding 4 lines of XML to a single file is vastly superior. > > 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? Actually, most new sites I come across are XHTML 1.1. XHTML 2.0 is dead, but HTML 5 supports a superset of XHTML 1.1, so as the world transitions to HTML 5, you'll still be able to use Lift. > HTML literals *in* the > code? Yeah. You have String constants in Rails code all the time. Plus, you have a non-trivial amount of logic in ERBs. Plus you have to worry about escaping Strings when you output them in an ERB template. In Lift, if you want, you can load templates and bind variables into the templates, it's super-easy. And all of Lift's template loading goes through Lift's localization mechanism. So, for prototypes, put your HTML literals in your code. When the team is big enough to divide the work, go through and pull out the literals into template files. Yeah, this violates a little of the "a prototype is shippable" that I was talking about above, but you can also start with "best practices" in terms of the templating. > 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... > I introduced one of the guys that designed the J2EE spec to Rails. His first reaction to Rails was, "there are so many files and so many directories." My response to him was, "And each one has a purpose once you understand a little more about the framework, so get over it." I do 50% of my coding with Emacs and my fingers do the right thing. Those using TextMate or an IDE don't worry at all. > > 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. Yeah. Scala is statically typed. The model defines the schema. You're complaining about adding a few characters to a file to identify a model/DB table that's in active use. So, but this is not a legitimate complaint. > 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: > If you've got a better way to do it, let me know. I've been asking the Scala folks for a unified import facility for 3+ years. In Scala 2.8, there are package objects that will mitigate some of the import pain. > 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 > You mean http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#M002172 All 42 uncommented lines of it? The point of the validPriority method is to demonstrate how easy it is to build a validator. Lift provides a fair number of validators... most of them are the common ones that I and other committers have built for the projects we work on. In practice, most projects build their own validators... and because they are just functions, there's a lot less magic than what's going on with Rails. > 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. > So, when you specify the :message if :validates_numericality_of, you're not specifying representation? At this point, it seems like you're looking to bash. What Lift gives you is the ability to put markup in your code and there are good reasons for this. Originally, FieldError took only a String. Then there was the desire to include links and icons (with mouse-overs) in the validation messages, so we changed FieldError to take markup. > > I apologize if this seems flippant but I really think that a lot of > people won't even push on this far, It's interesting... Lift has been growing at a pretty nice rate. We've got 1,700+ people on our mailing list. A couple of the committers are ex-Rails people. Hip start-ups and enterprise web developers alike are adopting Lift... and not because it's the only Scala-based web framework. With Scala, you can choose any Java web framework and many people choose Wicket. There are a number of Scala-specific web frameworks including Sweet with is an MVC framework that has better documentation than Lift. Slinky which is a very functionally flavored web framework and part of the ScalaZ package. There's Play, a very interactive Java/Scala MVC web framework. There's also web.lib, another functional web framework. In terms of project popularity (community size, committer team size, community growth rates, code-base growth rates, interest by publishers publishing Lift-related books, etc.) Lift has met or exceeded all of my goals. No, it's not Rails or jQuery or Spring, but its trajectory is better than the likes of Wicket, Django, etc. What I've observed is there's an inflection point for developers coming from other frameworks. There's an initial dislike of Lift's differences... but once they hit the inflection point and they get the "why" in the differences, they become avid Lift users. Thanks, David > 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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
