How do folks compare them for a simple project?  I'd like to run it on
a cloud-hosted platform such as GAE, so interop with cloud is a plus.

But generally, what is the workflow which makes people pick
lightweight frameworks like Scalatra and especially Unfiltered versus
Lift?

Do people run Play with something other than Anorm back end, the
latter making incorrect claims against ORMs (hint: you can query
PostgreSQL about the schema ahead of time, cf. PGOcaml for example).
Specifically, what do you use to run on GAE?

Let's make it even simpler.

(a) Is there any reason to use Unfiltered for web sites other than
RESTful services?
(b) Is there any reason to delve into Lift for a simple web project to
explore Scala web apps instead of
(c) Scalatra or Play?
(d) so which is it, Scalatra or Play?  (Typesafe's using Play for its
website, right?)

The four you've listed fall into 2 groups: full-stack (lift and play)
and minimal (scalatra and unfiltered). Are you a full-stack or minimal?
Decide and you are half way to your answer. If you think a framework
should provide rich layers over key technologies including your
protocol, data store, presentation, and state management, then you want
full-stack. Such frameworks are fine, but it is incumbent upon you to
have an intimate understanding of how such frameworks abstract over this
infrastructure, as well as the infrastructure itself. Some will disagree
with that, arguing that the very reason you want these abstractions is
so you don't need this understanding. If you buy that then I wish you
luck; you'll surely need it should you decide to develop a non-trivial
application.

The other two, scalatra and unfiltered, are much lighter. These are
similar in that they provide a syntactic abstraction for working with
http, but intentionally avoid abstracting it away. Instead the embrace
the protocol and keep it front and center. This naturally makes some
tasks more involved (like state management), but such tools make it
easier to wield http, instead of wrangle it into something it isn't.
Additionally, because they're so small and so bound to the medium,
they're much easier to learn.

I've worked a fair bit with lift and play in the past. I like lift's
component-like architecture but found it generally obtuse. I found play
much easier to get started with, and if you're a RoR-flavored MVC type,
it's definitely a good choice. Both pack abstractions over http and come
with ORMs, view and state management out of the box. That said, I'm not
sure I would choose to use either of these simply because I'm more
minimal. In my experience I've found that the bigger the framework, the
bigger the chance of it getting in your way.

I work full time on a mid-sized web app built entirely with unfiltered.
I've worked with unfiltered in some manner since it surfaced, and for
the time being it's unlikely that I would pick something else. Why? It
simply matches my philosophy about web apps, and it leverages scala's
strength to wrap http. For example, instead of using string patterns
that the framework parses on the fly (like scalatra), unfiltered uses
partial functions to pull apart a request as a pattern match. The
library has many intuitive extractors to help you pull apart requests
based on content types, authentication headers, encoding types, and
includes a combinatorial library for sending responses in various
formats. It runs on GAE (I have two such apps deployed), standard
servlet containers, and netty.

So by now my bias is clear, but I'm not really the emotional type. I
arrived at unfiltered after years with many different frameworks, and
after having a go with both lift and play. They are fine frameworks, but
they don't match my philosophy.

-chris

On 09/01/2011 06:07 PM, braver wrote:

--
Jim

HTH,
N.

Some of the techniques (pages are treated as DOM-like objects instead
of templates during processing) takes its toll on development. It is
really hard learn. I don't buy the argument about leaking primary
keys; it has not been a problem on any framework I've worked - It is
bad developers who leak primary keys, not the framework.

If I am to buy into it, it would not be for security bad rather that
it is the only framework built completely around Scala.Note that I am
biased because I find Lift to be too time consuming for me to learn.
I'd prefer a simpler framework like Play! In fact, I am writing a
tutorial for it now!

I was just responding to Jim's question about Lift's security
features. Personally I like to learn more about Lift's approach to
security as well. I just wanted to start off with the information I've
come across and my thoughts on it.

I understand that Lift makes security a fundamental part of the
framework. That's a good thing. It's just when I read things like
"Lift apps leak fewer primary keys and other information than do other
apps" it smells like market speak to me. That, just a small part of
Lift's features list, was something I didn't like.

Regarding "Lift in Action", I am afraid to say I haven't read it. But
I have added it to my read it later list!

Just to be clear, here's why transactions are important:
// initialize value in a database
account.currentBalance = 100.00

// Run in thread A
val a0 = account.currentBalance
val b0 = a0 + 100.00
account.currentBalance = b0 // commit to database

// Run in thread B
val a1 = account.currentBalance
val b1 = a1 - 100.00
account.currentBalance = b1 // commit to database

The prize to anyone who can tell me what the value of account.currentBalance
is in the database when both threads are run *without* transactions.

ALL of the libraries mentioned above have their merits.

Lift is undoubtedly the most mature of the family of web based
software in scala. You should take note of that because that usually
means most of the bugs and kinks are worked out already. It has been
around the longest and has had the most man hours put into it. You
will most likely get the best "out of the box" experience with it if
you are writing a certain style of application. The problem with
having been around for so long, and for a while, being pretty much
your only option, is that in order for it to be a good out of the box
experience for everyone, it had to cater towards everyone's needs.
This inevitably leads to bloat and tight coupling. Most libraries
written for lift are tightly coupled together which is good if you
know you are going to be on lift forever but bad if you know in the
future you want some flexibility. Application style-wise lift is very
much like apache wicket if you are coming from the java world. It's
heavily based on server side state and components which needs to be
synchronized with client side state (views). This works for some types
of applications but as you grow you are inevitably working with a
leaky abstraction as your need to make sure clients don't ping pong
between servers that may not have the same synchronized serialized
session. My 2 cents here is that lift is rails before for rails went
rack. It's still coupling you to its ideas and libraries.

I haven't really used Play enough to speak to all of its merits but it
seems to fall under the category of good out of the box experiences.
The scala component seems very complementary to the java component so
starting with java and migrating to scala here would require the least
amount of effort. It seems to have good modularity but one thing I
noticed (I am not an expert so take this with a grain of salt) is that
it decided to create its own classloading model. I think it has since
been able to adapt to traditional java deployment containers but it
was an after through. This means that writing components of a play app
you would not easily be able to switch to another framework if you
chose to. For this reason I put it under the same category as lift
"box"es. Beware of getting boxed in. If you are cool with that this
falls under the same category as lift.

Scalatra looks nice for simple apps but falls under the category of
one of my pet peeves, it's just copying a framework from one language
and porting it to another. Every language and their mother at one
point tried to copy rails and more recently the ruby web framework
sinatra. Sintara is very attractive, sexy even, because it's almost
nothing (no out of the box orm no enforced idioms or structure). For
this reason it's also attractive to copy. I think the original impl of
scalatra ("step" then) came from a short blog post of some just doing
a simple proof of concept to learn scala. I don't think it was
originally intended to be serious but it has taken on new life since
then. While imitation _is_ a sincere form of flattery, there is a
problem with doing this in software. It's where your eyes are at.
Groovy on Grails had this problem as well. They were always looking to
copy the latest features of ruby on rails while rails was always
looking at inventing the future. This meant that grails would forever
be behind the real rails. I see people following the same path falling
into the same pit. Rather than looking towards the future they are
copying the past. I _do_ like the sinatra style of applications but if
I wanted to write a sinatra app, I'd just use sinatra :) It's still
the best implementation. Outside of that, I'm surprised no one
mentioned http://circumflex.ru/ which has almost the exact same dsl,
has been around longer, and looks to be better documented (not even
copying sinatra's documentation styles!). All of that aside, The guys
behind scalatra seem pretty keen on keeping it around so if you are a
ruby dev looking to move to scala, you may be a good first stop. It's
not going away anytime soon and neither is the hipness of Frank
himself.

I've just recently started hearing about BlueEyes which seems to
follow the same design of unfiltered in terms of how it handles
requests (partial functions). I haven't really looked that much into
it besides the readme, but promoting yourself the way it does is very
off-putting to me web 3.0? I'm guessing that means html6 (j/k) In all
fairness, it looks like right style of development to me. It's using
scala idioms which I think is very important in a scala library.
However, unlike unfiltered, it seems very tightly coupled with netty.
So if you are targeting netty this is a good thing. If you are not, it
doesn't provide much value. I predict the use of netty to be close to
the future in the realm of java/scala/jvm web libraries. It has some
pretty nice wrappings around the complexities of nio. Netty may not
web 3.0 but it is use is moving towards that direction :)

Finally there is unfiltered. Why another framework? Two things, 1)
it's actually been around for a while, almost a subculture. So there
weren't enough out there to put it in the `yet another` context at the
time. When we started writing it, there weren't many options that
suited our philosophy. We wanted something that that was simple and
just tied together a few simple concepts using idioms people are
already used to in scala programming: partial functions and
extractors. That's really about it. 2) It's not a framework! I kind of
hate that term. A framework implies that you are designing yourself
around an enclosed structure. Once you put up the walls, you're pretty
much stuck there. I'd rather say unfiltered is an http library or tool
kit or tool belt. It's just a set of libraries that you decide on how
you want to compose yourself. There is no orm, there is no expected
directory structure. You can write an executable app in one line of
code. If you wanted, there even could be no server dependency. Or if
you wanted to you could, with minimal effort, switch between server
dependencies (including netty, jetty, or if you wanted which ever
backend you want to implement). It's just a set of libraries that try
to be loosely coupled so that you can solve your problem and get out
of the way. The compromise here is not out of the box experience build
into the framework it self. Instead we encourage you to look at that
problem in a different way, much better imho. Use another library to
do the packaging for you and leave that out of the framework. That's
where the giter8 project came from. Giter8 follows the same
philosophy. Loose coupling. Is giter8 tied to unfiltered? No! It's
just a library for templatizing pretty much anything and exposing your
templates over the web.

I will admit that unfiltered's weak spot right now is really a good
traditional view templating system but I encourage you to think of
that problem in other ways too. Maybe a lot of serverside templating
isn't the best answer for your problem. Maybe you want client-side
templating. Maybe scala isn't the best tool for that. Maybe you don't
need templating at all. Maybe you just need static files. I find it
frustrating when our best solution is to look at how we handled things
in the past and how others are currently doing them. I commend lift
for it's view binding approach as this seems a bit nicer than wickets
view binding model. More recently, lift has added a nicer query
interface for manipulating views which I prefer. That may have been
inspired from the clojure library that already did that and just does
that. I really like that style.

Hopefully this all get interpreted the way I meant it, that is, with
no disrespect to anyone's hard work. Everyone of these libraries
started in someone's spare time and exist as open source for anyone to
contribute to.

There are _NO_ bad scala web libraries. Asking "which is the best?" is
just asking the wrong question.

If you are looking to use one, you may want to

1) think about the problem you are trying to solve
2) think about how you expect that solution to evolve in the future
3) be opinionated but be honest
4) know your own design philosophies and see how the tools you choose
align with those
5) have fun!

What's needed is a really short intro to what you need to know to do the 90%
most common tasks in Web development, plus much better API docs. I've
volunteered to one of the committers to contribute some API doc, we'll see
if that flies.