Scalatra vs Unfiltered vs Lift vs Play

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

Re: Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Adam Jorgensen on 2011-09-08, 07:07
I just want to thank Ivan for mentioning Scalatra. Following his mention of it I took some time to look at itand 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 thatif 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 :-)

On 3 September 2011 11:19, Ivan Porto Carrero <ivan [at] flanders [dot] co [dot] nz> wrote:
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.

Re: Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Viktor Klang on 2011-09-03, 10:37


On Sat, Sep 3, 2011 at 11:19 AM, Ivan Porto Carrero <ivan [at] flanders [dot] co [dot] nz> wrote:
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.

Sounds like an interesting idea!
 


--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Hristo Deshev on 2011-09-02, 21:37
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
On Fri, Sep 2, 2011 at 10:38 PM, John Cheng <johnlicheng [at] gmail [dot] com> wrote:
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!

On Fri, Sep 2, 2011 at 12:00 PM, Timothy Perrett <tperrett [at] gmail [dot] com> wrote:
> 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

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by hohonuuli on 2011-09-02, 04:57
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
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Adam Jorgensen on 2011-09-02, 05:17
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 junkand 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 :-/

On 2 September 2011 05:52, Brian Schlining <bschlining [at] gmail [dot] 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
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Sadek Drobi on 2011-09-02, 09:08

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 <bschlining [at] gmail [dot] 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
bschlining [at] gmail [dot] com




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

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by hohonuuli on 2011-09-02, 06:17


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
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by hohonuuli on 2011-09-02, 06:07
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.

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Adam Jorgensen on 2011-09-02, 07:47
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 <bschlining [at] gmail [dot] 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 ...)


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.

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by hohonuuli on 2011-09-02, 18:57
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 <bschlining [at] gmail [dot] 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 ...)

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Sadek Drobi on 2011-09-02, 21:27
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.

On Fri, Sep 2, 2011 at 7:47 PM, Brian Schlining <bschlining [at] gmail [dot] com> wrote:
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 <bschlining [at] gmail [dot] 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 ...)

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com



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

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by hohonuuli on 2011-09-02, 21:57

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 databaseaccount.currentBalance = 100.00
// Run in thread A val a0 = account.currentBalanceval b0 = a0 + 100.00account.currentBalance = b0 // commit to database
// Run in thread Bval a1 = account.currentBalance val b1 = a1 - 100.00account.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.--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by nilskp on 2011-09-03, 02:07
On Fri, Sep 2, 2011 at 3:54 PM, Brian Schlining <bschlining [at] gmail [dot] 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.
 

Just to be clear, here's why transactions are important:// initialize value in a databaseaccount.currentBalance = 100.00
// Run in thread A val a0 = account.currentBalanceval b0 = a0 + 100.00account.currentBalance = b0 // commit to database
// Run in thread Bval a1 = account.currentBalance val b1 = a1 - 100.00account.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.--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Ken McDonald on 2011-09-02, 01:07
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

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Nuanda on 2011-09-02, 09:37
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)

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Ken McDonald on 2011-09-02, 01:27
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

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Alexy Khrabrov on 2011-09-02, 02:07

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+

Re: Scalatra vs Unfiltered vs Lift vs Play

Added by Ken McDonald on 2011-09-02, 04:07

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

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland