Scalatra vs Unfiltered vs Lift vs Play

[braver]

Say I want to explore Scala web apps, and am comparing web
frameworks. The four in the subject are what I've seen first. Lift
was around for a long time and is big; others seem more compact by
comparison.

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?)

Cheers,
Alexy

[Ken McDonald]

I'll definitely be following this thread. I can only comment on Lift, as I decided to go with the de facto standard:

    1) Very poor API documentation, frustratingly so. But this seems common in open source projects. (I'm a tech writer, so I'm picky about this.)

    2) 2 Free books out and one electronic one in preview, all decent, none The One True Book.

    3) Lift has evolved rapidly, and has tried out and discarded many ideas--this may be one reason it's larger. For example, its method for associating functionality with (X)HTML markup is very nice, but many examples still use the earlier method, which isn't as nice. You have to be sure you're doing things the right _current_ way.

    4) Lift gives you fairly sophisticated user management for free. If you need to change the way it does that, it may be difficult, or it may be easy.

    5) Highly responsive and active Google group.

Hope that helps.

Ken

[Ken McDonald]

Just out of curiosity, I just took a look at Play and Anorm. I have to say I strongly disagree with the premise of Anorm. If you're writing SQL by hand and manually processing the results, not only are you just making more work for yourself, but you've also added an indirect level of needed testing which I suspect makes for a _lot_ of work in complex cases. Now granted, ORMs can't make sure your queries return what you want, but they do eliminate a _lot_ of errors and generally ensure that your queries are at least valid SQL.

In Lift, there are two standard ORMs, Mapper and Record. (Like I said in my first post, there's been a fair bit of experimentation to find the best way of doing things.) I would say Mapper is easier to use, and is good for relatively simple things. If you'll be doing really complex queries, you can use squeryl with Record (or on its own--you don't need to use one of the Lift ORMs). Note that the previously mentioned user management features are implemented using Mapper, so if you use squeryl, you can't declare relationships or do SQL queries between the User table and squeryl/Record tables.

With a language like Scala, I want to be working at a higher level of abstraction, and Anorm seems to be going back to a lower level of abstraction. Oh well, just my opinion.

Ken

[braver]

In fact, looks like folks were deploying Play onto GAE with Siena, so
I guess we don't have to use that A(b)norm after all.

A+

[Ken McDonald]

Definitely better, but I still like the promise of squeryl for SQL work.

[Chris Lewis]

The choice of a framework is a reflection of one's philosophy, and so
questions about this choice are introspections into one's own philosophy
about what a web application is, how it works, and what you expect to
lose and gain from your chosen tool.

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

[Brian Schlining]

I think Chris' answer is a very good summary. I just wanted to mention I ported a mid-sized app from Wicket over to Scalatra and the resulting code base is much lighter and the code is far easer to understand. Also, the Java world has some great persistence API's that I'm familiar with so having a framework with persistence baked-in wasn't important for me. But if you're not up on one of those you might want a framework with persistence built in.

Got to say unfiltered looks interesting ...

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.

-- 

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschl...@gmail.com

[Adam Jorgensen]

My only experience with the frameworks mentioned has been some fiddling about with Play. Generally I like what I see in said framework. It dispenses with all the needlessly obtuse J2EE junk

and gets you up and running quickly with a work flow that is very close to what you are used to if you've done any work recently using Ruby, Python or PHP. The simple approach to web apps

endorsed by Play may not be appropriate for 100% of web applications but it is probably a better bet than J2EE for about 95% of stuff.

With regards to the Anorm component I am surprised to see so many people with negative opinions of it. As I understand it Anorm mostly just lets you query using SQL (Which is a pretty reasonable

proposal if you ask me) and get back objects which are easy to work with. It's possible to do various other stuff with it, but the aforementioned feature is its key strength.

Whether or not you agree with the Anorm philosophy is just one of those things. Some people love top-heavy ORM systems and the supposed safety ropes they provide.Other people run into 

problem after problem after problem and just want something less long-winded. It's a matter of choice and I personally applaud Anorm for helping to provide that choice.

Overall, I like ORMs but think the programmers working with them should still have a firm grasp of SQL. Unfortunately this is not always the case :-/

[Jim McBeath]

On Thu, Sep 01, 2011 at 11:13:59PM -0400, Chris Lewis wrote:
> The choice of a framework is a reflection of one's philosophy

Lift claims to have a lot of security built in against stuff like
cross-site scripting and replay attacks [1], without the developer having to
do anything special or even think about it. I haven't used any of the
frameworks enough to know. Can anyone comment on this claim?

--
Jim

[1] http://seventhings.liftweb.net/ item 7

[Brian Schlining]

With regards to the Anorm component I am surprised to see so many people with negative opinions of it. 

??? Did someone say something negative about Anorm? My take was that folks were pointing out other persistence frameworks that have worked successfully.  

 

[Brian Schlining]

Hey, I don't see that Anorm supports database transactions. Is that really true or am I missing something? (SQL without transactions seems like a pretty significant oversight ...)

With regards to the Anorm component I am surprised to see so many people with negative opinions of it. As I understand it Anorm mostly just lets you query using SQL (Which is a pretty reasonable

proposal if you ask me) and get back objects which are easy to work with. It's possible to do various other stuff with it, but the aforementioned feature is its key strength.

[Adam Jorgensen]

Er...I would imagine that since Anorm involves writing actual SQL that using a transaction involves writing the actual SQL for said transaction...

[Sadache Aldrobi]

Whether or not you agree with the Anorm philosophy is just one of those things. Some people love top-heavy ORM systems and the supposed safety ropes they provide.Other people run into 

problem after problem after problem and just want something less long-winded. It's a matter of choice and I personally applaud Anorm for helping to provide that choice.

Overall, I like ORMs but think the programmers working with them should still have a firm grasp of SQL. Unfortunately this is not always the case :-/

Well that's exactly the way I would explain it. If you prefer ORMs, there are quite some choices in Scala, Anorm is about lightweight API that will allow you to do plain old JDBC nicely and doesn't assume you own your database (data lives more than applications) and assumes you want to use the full power of your database.

Nevertheless, Play doesn't stop you from using ORMs.

 

On 2 September 2011 05:52, Brian Schlining <bschl...@gmail.com> wrote:

I think Chris' answer is a very good summary. I just wanted to mention I ported a mid-sized app from Wicket over to Scalatra and the resulting code base is much lighter and the code is far easer to understand. Also, the Java world has some great persistence API's that I'm familiar with so having a framework with persistence baked-in wasn't important for me. But if you're not up on one of those you might want a framework with persistence built in.

Got to say unfiltered looks interesting ...

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.

-- 

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschl...@gmail.com

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Nuanda]

In terms of documented API, Lift's not great. However you'd really have to mod Lift up in terms of "books to read" for newcomers looking for an quick onramp to the technology:

* http://www.amazon.com/Definitive-Guide-Lift-Scala-Based-Framework/dp/1430224215  (Apress)

* http://www.manning.com/perrett/  (Manning)

* http://simply.liftweb.net/  (e-Book)

[Timothy Perrett]

Morning all,

This is an interesting thread an I would for the most part agree with "chris" on his view about web frameworks and libraries. Finding one that fits the way you work is the key to being successful. With that being said, there is indeed quite a gulf between feature sets so it is important to understand what you are trying to do. 

I'm fairly amazed that no one has yet pointed out the obvious division of stateful vs stateless. All the ones you listed are specifically stateless, or at least, they do round-tripping of their state for each request either into a cookie or some other store. Lift doesn't do that and as such has a pretty different approach. One of the other commenters asked about Lift's security, and yes, it does have sophisticated security built into all the component rendering which essentially makes attacks like CSRF impossible. Thats the tip of the iceberg and there's a lot of stuff in there that people don't use or isn't widely published. 

So how do you decide? First and foremost, think about what you are doing: is it a site, pure services or an application? You'll find that each of the projects you listed fits more naturally into one of these categories. For example, unfiltered is excellent for services, but sure, you could do them in Lift or Play, but unfiltered's natural fit is for services (IMHO), and it does that excellently. Conversely, Lift is great for building rich applications, but likewise, can also do services.

Clearly having written a book about Lift I am biased, but i've also used unfiltered and several others... its about strengths and weaknesses: all projects have them and you need to match those against your own approach. Many people like Play! because it has good documentation and uses a familiar MVC pattern of implementation, and whilst I can respect those who understand the approach and choose it because it fits them, it's really not an approach that fits me or my needs.

I just want to close by talking a little bit about this notion of full stack or not. IMHO, this is a complete red herring and not something that really matters. Sure things like Lift and Play come with their own persistence and other plumbing, but there is really nothing to say or require that you should use them. Within my applications i'm using lift-webkit and thats it; otherwise i'm either using ScalaQuery for RDBMS access or Salat for MongoDB. That being said, there are excellent projects like Rogue built on top of Lift's persistence systems... again, its about choice. Building your application stack is up to you, and isn't mandated by any of the frameworks you mentioned above. I personally think that is a really important thing to note, because it means that you choose the tools that work for you, from top to bottom. 

Thanks, Tim

PS: Just seen some new mails come in about deployment; all of the projects you listed can be built as WAR files, so they'll deploy to pretty much any cloud hosting service. GAE comes with extra limitations around creating new threads, but that affects all toolkits. If you want cloud hosting you have cloudbees, heroku or plain ec2. 

[Noel Welsh]

If you like Unfiltered, take a look at BlueEyes. It does a bit more
than Unfiltered but has a very similar model. FWIW, I've developed
apps in BlueEyes and Lift and agree with most of the statements
expressed in this thread.

HTH,
N.

--
Noel Welsh
Untyped Ltd                 http://www.untyped.com/
+44 (0) 121 285 2285    in...@untyped.com
UK company number    06226466

[John Cheng]

On Thu, Sep 1, 2011 at 9:21 PM, Jim McBeath <sc...@j.jimmc.org> wrote:
> On Thu, Sep 01, 2011 at 11:13:59PM -0400, Chris Lewis wrote:
>> The choice of a framework is a reflection of one's philosophy
>
> Lift claims to have a lot of security built in against stuff like
> cross-site scripting and replay attacks [1], without the developer having to
> do anything special or even think about it.  I haven't used any of the
> frameworks enough to know.  Can anyone comment on this claim?
>

See
http://groups.google.com/group/liftweb/browse_thread/thread/73791b1d6625116

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!

--
---
John L Cheng

[Brian Schlining]

If don't think so. For one, JDBC nicely abstracts transaction bounds; having to manually code the transaction bounds using your database's particular SQL dialect is enough of a deal breaker to NOT use Anorm. For another thing, transactions are used to do things like read a value, do some processing with that value and then update the value in the database. If Anorm, forced you to do ALL of that in straight SQL in order to use transactions, why would I bother with it? In that case it's offering me less than straight JDBC and far, far less than most other persistence frameworks.

Er...I would imagine that since Anorm involves writing actual SQL that using a transaction involves writing the actual SQL for said transaction...

On 2 September 2011 07:02, Brian Schlining <bschl...@gmail.com> wrote:

Hey, I don't see that Anorm supports database transactions. Is that really true or am I missing something? (SQL without transactions seems like a pretty significant oversight ...)

[Timothy Perrett]

Hi John,

I'm not sure anyone is saying that Lift not "leaking primary keys" is the biggest feature in the world, IMO, the XSS, CSRF and overall security argument with Lift is far more compelling. Broadly, Lift is attempting to make it more work for the developer to do something silly and introduce vulnerabilities, whilst making the more secure route easier and the default choice.

Lift's documentation is not the best, that is true, but i've had a lot of good feedback from readers of my book who are now enjoying Lift having previously struggled with it, so maybe it's worth a second look for you. In any case, everyone has their preference and there are lots of products to choose from within the ecosystem, as myself and others have previously commented. 

Thanks, Tim

[John Cheng]

Hi Tim,

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!

[Sadache Aldrobi]

Here is the scenario:

You want to use JDBC -> Api is ugly and mutable -> you wrap it into a nicer safe api -> you want to support more types -> you add typeclasses -> you get overwhelmed with parsing the same structures the same way -> you add combinators -> you get Anorm

I hope this explains better the picture.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Hristo Deshev]

I'm using Play! and I sorta like it. It feels simple and productive to me, and I'm used to MVC frameworks. There are two things that I don't like though:

1) It's a bit bloated. Building a war archive of a "Hello world" app with the Scala plugin enabled gets you a 53 MB file! I'd love to have a way to strip stuff that I don't use like JPA-based ORM's, Anorm, Groovy, and whatnot.

2) It lags behind Scala releases. No Scala 2.9.x support yet.

By the way, Scalatra looks way cool. If I was starting my project now, I'd probably pick it.

Hristo

[Brian Schlining]

You want to use JDBC -> Api is ugly and mutable -> you wrap it into a nicer safe api -> you want to support more types -> you add typeclasses -> you get overwhelmed with parsing the same structures the same way -> you add combinators -> you get Anorm

I hope this explains better the picture.

No, I don't think you understand my point. My question is: Does Anorm support transactions? I found some discussion about it on this thread: https://groups.google.com/forum/#!topic/play-framework/qA6GyRn_eew but it doesn't look like Anorm allows you to explicitly demarcate transaction boundaries. You can add all the syntactic sugar you want to make it a type-safe, combinator filled, 'nicer safer' api. But without transaction support, it's just a toy framework that I would not put into production. 

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.

 

With that said, it looks like the Anorm authors are at least thinking about adding transaction support.

[doug]

I'll admit up front I'm biased. I work on unfiltered. My bias isn't
that though. It's in picking the right tool for the right job.

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!

5 is probably the most important. It doesn't matter which library you
choose as long as you are having fun writing code!

[Ken McDonald]

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!

Lift is a Big framework, but it is not inherently difficult to learn; in fact, it is inherently very easy to learn enough to become quite productive. But, the API documentation is absolutely horrible (by no means an open-source shortcoming restricted to Lift), and the three books available each do some of the job of what's needed, but not of them are complete enough. So you fall back on the Lift newsgroup.

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.

Cheers,

Ken 

[Alexandre Bertails]

I've played with all four solutions, writing sample projects.

I started with Lift. I liked the key concepts but was hurt by the lack
of documentation at the time (don't know if it has changed). Writing a
simple widget using Lift's JS abstraction was just a PITA, so I tried
with Scalatra. Then I looked at Play!. I believe there is some good
potential there. But I didn't need Anorm and I already wanted to keep
Scalate for my templates. Also, Play! was really in my way: I really
need to have control over sbt as the app we have in mind has some
heavy middleware. IMO, Play! doesn't let you consider that the Web is
just a part of your application.

I then looked at Scalatra and Unfiltered. I picked Unfiltered (maybe
because I knew the authors) and I don't regret it. It's really in the
Scala spirit: don't get in my way, do one thing and only one. And do
it well. I test my APIs with Dispatch, which is really good too. I was
amazed how fast I could write tricky applications, where I really care
about the HTTP stack.

Alexandre.

[Nils Kilden-Pedersen]

On Fri, Sep 2, 2011 at 3:54 PM, Brian Schlining <bschl...@gmail.com> wrote:

You want to use JDBC -> Api is ugly and mutable -> you wrap it into a nicer safe api -> you want to support more types -> you add typeclasses -> you get overwhelmed with parsing the same structures the same way -> you add combinators -> you get Anorm

I hope this explains better the picture.

No, I don't think you understand my point. My question is: Does Anorm support transactions? I found some discussion about it on this thread: https://groups.google.com/forum/#!topic/play-framework/qA6GyRn_eew but it doesn't look like Anorm allows you to explicitly demarcate transaction boundaries. You can add all the syntactic sugar you want to make it a type-safe, combinator filled, 'nicer safer' api. But without transaction support, it's just a toy framework that I would not put into production. 

For what it's worth, O/R Broker, which seems to build on the same premise as Anorm, does support transactions (and savepoints) and transaction isolation level support.

[曹江华]

i'm like xitrum on https://github.com/ngocdaothanh/xitrum

[eugene yokota]

I like Unfiltered.

It's easy to learn and set up, and it's met my needs so far.

I just want something that can take care of http aspect, and let me decide about UI layer and persistence. This "dont stress the chef" attitude fits in nicely with other libraries in Scala like time (Joda time wrapper) that just does one thing.

For my initial project, I wanted a simple restful ws on appengine that would process an uploaded file and return back some files. I started out with Play! (fun experience) and switched to Unfiltered. I had to extend the request handling a bit, but still look me less than a day to learn it.

For slightly more serious use (I write financial apps at work) I've thought about different options, but eventually decided on Unfiltered for a project because I wanted to keep the server-side stateless and generate the UI using javascript. I also wanted to write my own SQL to reuse existing stuff, which O/R Broker allowed me to do.

The great thing about Unfiltered is that all interactions among its component are out in the open as plain Scala code. This allows one to extend the library as she sees fit. Writing a custom authentication was just as simple as writing a "plan".

Also there are some modules that allows you to do more than just http, like jsonp:

case GET(UFPath("/jsonp/lift-json/optional") & Jsonp.Optional(callback)) =>
  callback respond {
    import net.liftweb.json.JsonAST._
    import net.liftweb.json.JsonDSL._
    "answer" -> Seq(42)
  }

Lift certainly has a lot of real world usage creds, but Unfiltered is up there with guys like Meetup, Novus, and Remember The Milk using it.

-eugene

[Ivan Porto Carrero]

Allow me to reply to this one.

I choose technologies, in descending order:

* zero-to-hero factor 

* if open source: code quality/layout/structure

* documentation

* license

Lift, I think we all agree, it works it's not perfect and it's a gorilla. I'm not a fan of big frameworks because it requires me to remember too much code and the chance the code has bugs in it or misses the extension point I need is pretty high.

Unfiltered is pretty cool and works pretty well.

Now the reason for scalatra and it's similarity to sinatra. I program 7 different languages sometimes in 1 day.

I'd rather invest time in something that fully embraces the http protocol and have my knowledge be transferrable across languages/frameworks/platforms.

You also have a whole new set of paradigms, conventions and context to learn. Not to mention the quirks each framework has.

There is a sinatra clone for just about every single language out there. I can't say that about lift, unfiltered, blueeyes or spray. Circumflex is really sad that they are so similar to us and we've asked them if they want to merge with us because it's such a duplication of effort but we never got taken up on that offer.

And yes HTTP is very simple so instead of re-inventing the wheel why not:

Then I would think that there are too many us vs them debates and which is the best web framework. We can put the scalatra dsl on top of unfiltered as a special type of Intent for example. I like the plans and intents of unfiltered and they have a nice abstraction over jetty and netty that is very re-usable.

I'd like to see more frameworks like spray, blueeyes etc to also use unfiltered as a base and have the unfiltered plans be our WSGI/WAI/Rack/... or something along those lines.

[√iktor Ҡlang]

Sounds like an interesting idea!
 

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Peter Hausel]

Hi Doug, good post! 

A few comments about play!:

- The best way to think about play! is as a platform, not a library. Play! uses its own classloader, compiler and HTTP layer (based on Netty) to provide quick class reloading on the fly (without server restart), faster, web.xml-free deployment options and simple async and background processing (http://www.playframework.org/documentation/1.2.3/asynchronous) .  

- You can package a play application as a war file (or a native grizzly module), in this case a front end dispatch servlet will convert the Servlet/Grizzly HTTP request/response objects into Play's own and bootstrap your app.  The servlet API implementation is indeed newer but the main drawback really is just that it requires packaging and the result war file will contain the whole play platform but as far as Play is concerned it's just a different Request/Response implementation

- Play's core architecture actually is very close to Unfiltered's, since both provide a Servlet and a Netty based request/response implementation. The standalone option in both cases is Netty

- You are right in that it would be hard to migrate away from play! but it's mainly true on the controller level (which frankly presents the same complexity as moving away from *any* web framework) but if someone follows the old 'skinny controller, fat models' idea (http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model) it should be quite straightforward. Also, thanks to the upcoming sbt support in 2.0, adding existing scala libraries to play apps should be much easier

- The original 1.X version of the framework was written in java and the scala module needed to work around many java limitations (mostly related to static methods), however, the freshly announced 2.0 (http://www.playframework.org/2.0)  will have scala bits and pieces within the main framework.

- Talking about Play 2.0, a few scala related highlights:

-- sbt will be used as the main building tool

-- the scala based templating engine will be the new default for both java and scala projects

-- Akka integration

-- Type checked routing

-- Play core will be (partly) rewritten in scala to support both java and scala projects better

I hope it helps someone.

Peter

PS and I agree with Doug, all of these frameworks are good choices, they just represent different trade-offs.

[Michael Fortin]

Hi,

After following the thread on 'Scalatra vs Unfiltered vs Lift vs Play', I'd like to throw my hat back into the ring.  Several months ago I posted here about my web framework I've been working.  After getting a lot of valuable feedback I've rebuild may it's parts. 

I did a quick webcast that attempts to give a high level view here: 

http://youtu.be/-kSMybXngpY

Website: http://brzy.org

google group: http://groups.google.com/group/brzy-web-framework

Some of the parts:

Fab(ricate) 

- A build tool, similar to maven but more domain specific.

- Uses project archetypes at the foundation of it's design.

http://wiki.brzy.org/doku.php?id=fabricate:home

WebApp Framework

- It's built on top of fab.

- A RESTful, action based framework.

- Incudes support for role based authentication, interceptors, file upload/download, json & xml, and more.

http://wiki.brzy.org/doku.php?id=archetype:brzywebapp

Calista - a Cassandra client api

- Access cassandra via a client api that's built directly on the low level thrift api.

http://wiki.brzy.org/doku.php?id=calista:home

One of my goals from the start has to build a simpler, more integrated and extensible framework, from the bottom up, instead of just focusing on the web framework or a build tool alone. 

As always, any feedback would be greatly appreciated.

_M!ke

[Naftoli Gugenheim]

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.

 Why is it harder to program with a NodeSeq than a String? I would think it's just the opposite.

 

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.

What are you referring to? Where does lift decide whether or not you "leak" a primary key, and how does that make things harder?

 

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!

Hmmm... sounds like regarding documentation, the rich get richer and the poor get poorer.

I highly doubt that Lift is inherently hard to learn (assuming knowledge of Scala) --- most likely it's the state of documentation. You have to admit though, things are a lot better than they used to be.

[Naftoli Gugenheim]

The short intro part is not a matter of API docs --- you could write that today if you wanted. 

Anyway, I'm not sure why, but no one seems to have mentioned perhaps the most important set of Lift documentation --- the assembla wiki (http://www.assembla.com/spaces/liftweb/wiki/).

Cheers,

Ken 

[Brian Schlining]

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.

 Why is it harder to program with a NodeSeq than a String? I would think it's just the opposite.

Have you tried modifying Scala's XML literals with RewriteRules? I would definitely consider that harder than working with a String.

[Doug Tangren]

On Wed, Sep 7, 2011 at 9:09 PM, Brian Schlining <bschl...@gmail.com> wrote:

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.

 Why is it harder to program with a NodeSeq than a String? I would think it's just the opposite.

Have you tried modifying Scala's XML literals with RewriteRules? I would definitely consider that harder than working with a String.

I don't think that templating libraries necessary should be coupled with a given framework aside from  bindings. I haven't looked and anti-xml yet but it may have a nicer interface for manipulating node seqs (I feel you Brian). I haven't played a lot with templating libraries in scala besides some basic scalate. Ideally what I'd want is something like clojure/s enlive [1] in scala. Basically binding css selectors to xml transformations in a self-contained library.

[1]: http://clj-me.blogspot.com/2009/01/enlive-yet-another-html-templating.html

[Adam Jorgensen]

I just want to thank Ivan for mentioning Scalatra. Following his mention of it I took some time to look at it

and I really like it.

In fact, I think ultra light-weight frameworks like Scalatra are the way of the future as the make developing

RESTful application extremely easy.

Which is not too say that full-stack frameworks and mid-level frameworks will disappear. Rather, I think that

if one is developing a client-heavy (Ie, Lots of JS) web app then something like Scalatra is probably going to

be awesome to work with :-)

[Xuefeng Wu]

play! team announce play!2.0 yesterday.  It's big version and it will rewrite the core framework in Scala.
https://groups.google.com/forum/#!topic/play-framework/jNyoIWv_xGQ

[Adam Jorgensen]

Mmmmmmm, I personally think that treating pages are DOM-like objects on the server-side is entirely the 

wrong way to go in web dev because it's basically duplicating what the browser already does.

[Doug Tangren]

On Thu, Sep 8, 2011 at 2:55 AM, Adam Jorgensen <adam.jor...@gmail.com> wrote:

Mmmmmmm, I personally think that treating pages are DOM-like objects on the server-side is entirely the 

wrong way to go in web dev because it's basically duplicating what the browser already does.

Server rendered pages _are_ dom-like objects.  

[Adam Jorgensen]

I accuse myself of miscommunication in the study with the html.

Mostly likely the case. What I meant was marshalling the HTML into an actual DOM on the server during processing

in order to manipulate it before serializing it back to HTML and sending it on to the client. That is what I consider to 

be the wrong way to go (As you can imagine, I dislike XML-based templating schemes immensely :-)

[John Cheng]

On Wed, Sep 7, 2011 at 5:23 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
>>
>> 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.
>
>  Why is it harder to program with a NodeSeq than a String? I would think
> it's just the opposite.

Try thinking about it in terms of whether it is harder to "learn" to
manipulate a NodeSeq vs strings. Learning Lift's programming model
reminded me of learning XSLT and working on projects where web
development is strictly done via XML and XSLT and generating
everything as valid, conforming XHTML.

A template system that allows for arbitrary string to be inserted at
any place is easier to learn. Here is one analogy - If I wanted to
learn HTML, I would start by coding the HTML code in a text editor,
then loading it in the browser to see what the code does. I would not
use the DOM module to create an XML DOM tree in (your favorite
language) then serialize the output into a file to be loaded by the
browser.

>>
>> 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.
>
> What are you referring to? Where does lift decide whether or not you "leak"
> a primary key, and how does that make things harder?

Take a look at the link in my post
http://groups.google.com/group/liftweb/browse_thread/thread/73791b1d6625116

David Pollak said "Lift apps leak fewer primary keys and other
information than do other apps. "

>> 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!
>
> Hmmm... sounds like regarding documentation, the rich get richer and the
> poor get poorer.
> I highly doubt that Lift is inherently hard to learn (assuming knowledge of
> Scala) --- most likely it's the state of documentation. You have to admit
> though, things are a lot better than they used to be.

You shouldn't make things so black and white. Its not that Lift can
only be considered "hard" or "easy" and I declared it solidly in the
camp of "hard". I just find it _relatively_ more difficult to learn. I
looked at both Play and Lift to introduce Scala to my coworkers and my
conclusion is that it would be easier to get them started on Play
compared to Lift.

[Doug Tangren]

On Thu, Sep 8, 2011 at 9:30 AM, John Cheng <johnl...@gmail.com> wrote:

On Wed, Sep 7, 2011 at 5:23 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
>>
>> 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.
>
>  Why is it harder to program with a NodeSeq than a String? I would think
> it's just the opposite.

Try thinking about it in terms of whether it is harder to "learn" to
manipulate a NodeSeq vs strings. Learning Lift's programming model
reminded me of learning XSLT and working on projects where web
development is strictly done via XML and XSLT and generating
everything as valid, conforming XHTML.

A template system that allows for arbitrary string to be inserted at
any place is easier to learn. Here is one analogy - If I wanted to
learn HTML, I would start by coding the HTML code in a text editor,
then loading it in the browser to see what the code does. I would not
use the DOM module to create an XML DOM tree in (your favorite
language) then serialize the output into a file to be loaded by the
browser.

That depends. If you wanted to start learning html, You could put arbitrary text in a text editor, save it, and load it in a browser, and keep doing that until you eventually figure out if what you entered was well formed or not.

I'm not sure if this is easier to learn if you don't already know xml. You may spend some time fumbling around wondering why something doesn't render before realizing that you didn't close a tag or entered some invalid markup. This is akin to developing in scripting languages where you only find these kinds of errors at run-time. Luckily some browser vendors have realized that some people still write malformed html and permit you to be sloppy and make a best attempt at cleaning your markup for you. Good luck with getting that to work consistently across browsers. I'd rather have valid markup from the start (which a type system can provide).

 One thing programming in a compiled language buys you is not having to waste time these kinds of errors. Since xml is a first class type in scala, the compiler call tell you immediately that your markup is not well formed, instead of wasting time debugging that yourself.

In any case, I think this topic is going off on a tangent not related to the thread.

 

 

[Daniel Sobral]

On Thu, Sep 8, 2011 at 11:10, Doug Tangren <d.ta...@gmail.com> wrote:
>
>  One thing programming in a compiled language buys you is not having to
> waste time these kinds of errors. Since xml is a first class type in scala,
> the compiler call tell you immediately that your markup is not well formed,
> instead of wasting time debugging that yourself.

Err, not so much. The compiler will tell you if the XML is malformed,
but not if the markup is malformed. Scala doesn't apply DTD or XSD at
compile time -- and given the dynamic nature of XML snippets, it would
be very hard indeed for it to do so.

--
Daniel C. Sobral

I travel to the future all the time.

[Adam Jorgensen]

Well, malformed HTML isn't entirely the fault of the browser developers. There is, after all, a difference between HTML and XHTML that starts at the standard level ( <br> vs. <br/> anyone ) and continues on up.

[Joseph Pachod]

Hi

Just a question to all the ones going for RESTish frameworks: what do
you suggest when you have to do a web application, with plenty of
forms and state? Still going for some RESTish frameworks? If so, how
do you handle (roughly) the state? If not, what do you go for then?

Thanks in advance
joseph

[Noel Welsh]

One approach is to push UI state into the client. Use lots of
Javascript, and probably a framework like backbone.js

HTH,
N.

On Wed, Sep 21, 2011 at 10:06 AM, Joseph Pachod <joseph...@gmail.com> wrote:
> Hi
>
> Just a question to all the ones going for RESTish frameworks: what do
> you suggest when you have to do a web application, with plenty of
> forms and state? Still going for some RESTish frameworks? If so, how
> do you handle (roughly) the state? If not, what do you go for then?
>
> Thanks in advance
> joseph

--
Noel Welsh
Untyped Ltd                 http://www.untyped.com/
+44 (0) 121 285 2285    in...@untyped.com
UK company number    06226466

[Kevin Wright]

It's worth noting here that we have *lots* of native Scala frameworks available that are designed to handle RESTful json queries:

https://wiki.scala-lang.org/display/SW/Tools+and+Libraries#ToolsandLibraries-Frameworks

So you can still happily use this approach and keep your state on the client, without having to drop down to an untyped scripting language for your server-side logic as well.

I'll freely concede that socket.io is rather cool though, and a *very* good reason for going with node.js.  But even then, there are ways to quickly get back into the land of type safety: https://github.com/remeniuk/nodejs-scala-connector

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Adam Jorgensen]

+1 to this

State on the Server-Side is not cool and ends up causing lots of problems in the long run.

I've worked with stateful server-side stuff in PHP, Java and Python and while the lure can sometimes

be pretty compelling the long-term offsets make you tear your hair out.

[chris]

We use Unfiltered for such an application. You can do simple session
id mimicking and pass that via cookies, or you can store a lightweight
user object in the cookie. As long as it's small and doesn't have
sensitive details, this is a decent solution. You incur a small hit
for deserialization and/or per-request lookups, but you're free of
server-managed state (no need for something like sticky sessions).

On Sep 21, 5:06 am, Joseph Pachod <joseph.pac...@gmail.com> wrote:
> Hi
>
> Just a question to all the ones going for RESTish frameworks: what do
> you suggest when you have to do a web application, with plenty of
> forms and state? Still going for some RESTish frameworks? If so, how
> do you handle (roughly) the state? If not, what do you go for then?
>
> Thanks in advance
> joseph
>
> On Thu, Sep 8, 2011 at 5:14 PM, Adam Jorgensen
>
>
>
>
>
>
>

> <adam.jorgensen...@gmail.com> wrote:
> > On 8 September 2011 16:10, Doug Tangren <d.tang...@gmail.com> wrote:
>
> >> On Thu, Sep 8, 2011 at 9:30 AM, John Cheng <johnlich...@gmail.com> wrote:
>
> >>> On Wed, Sep 7, 2011 at 5:23 PM, Naftoli Gugenheim <naftoli...@gmail.com>

[Raoul Duke]

On Wed, Sep 21, 2011 at 8:23 AM, Adam Jorgensen
<adam.jor...@gmail.com> wrote:
> State on the Server-Side is not cool and ends up causing lots of problems in
> the long run.

there's recent work where the usually-server-side-continuations are
pushed to the client. pretty cool. can't recall where it was. maybe
racket scheme? or smalltalk?

[Kevin Wright]

There was the swarm project.  No idea what it's currently up to though...

[Raoul Duke]

On Wed, Sep 21, 2011 at 10:48 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> There was the swarm project.  No idea what it's currently up to though...

hi, hrm, no..., i think that is something else. swarm is pushing akka
actors to another machine on which they run, if i understand
correctly. what i'm talking about is a web application server system
in the classis seaside / viaweb server-side continuations style, but
with the continuations being serialized and pushed to the browser's
cache so that the server doesn't die under load. or at least that is
what i think i'm talking about, that is what i have in my head, but
can't find the reference. the idea of saving it on the client is not
new, so i must be thinking of an article that has some nuance on it,
but i am pretty sure that it wasn't swarm... but i might be brain
addled...

[Kevin Wright]

Not so, swarm is about serialising continuations and pushing them to remote machines, wherever the data is: http://code.google.com/p/swarm-dpl/

No actors involved.

[Raoul Duke]

On Wed, Sep 21, 2011 at 11:00 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
> Not so, swarm is about serialising continuations and pushing them to remote
> machines, wherever the data is: http://code.google.com/p/swarm-dpl/

ok cool.

thanks.

[Adam Jorgensen]

That sounds pretty cool :-)

[Florian Hars]

On Wed, Sep 21, 2011 at 05:23:12PM +0200, Adam Jorgensen wrote:
> State on the Server-Side is not cool and ends up causing lots of problems in
> the long run.

On the other hand, state on the client can be a security
nightmare and highly inefficient if the state is large
enough. And on the third hand, shared nothing architectures
may produce horrible database loads that require big iron
database servers that are far more expensive and more
difficult to manage than a load balancing router with session
affinity.

And "lots of forms and state" is exactly what lift was designed
for, so I wouldn't exclude it a priori.

Silver bullets are currently out of stock.

- Florian.