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
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.
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
With regards to the Anorm component I am surprised to see so many people with negative opinions of it.
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 reasonableproposal 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 intoproblem 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 <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
HTH,
N.
--
Noel Welsh
Untyped Ltd http://www.untyped.com/
+44 (0) 121 285 2285 in...@untyped.com
UK company number 06226466
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
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 ...)
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!
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 AnormI hope this explains better the picture.
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!
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.
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 AnormI 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.
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)}
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!
Cheers,Ken
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.
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.
Mmmmmmm, I personally think that treating pages are DOM-like objects on the server-side is entirely thewrong way to go in web dev because it's basically duplicating what the browser already does.
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.
On Wed, Sep 7, 2011 at 5:23 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:Try thinking about it in terms of whether it is harder to "learn" to
>>
>> 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.
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.
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.
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
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
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?
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...
ok cool.
thanks.
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.
hi, hrm, no..., i think that is something else. swarm is pushing akkaactors 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...
nice!
> There was the swarm project (http://code.google.com/p/swarm-dpl/).
> No idea what it's currently up to though...
Judgning from http://code.google.com/p/swarm-dpl/updates/list,
this project seems almost dead (3 updates since Jan 2011, 3
updates in 2010...).
Does anyone know of something akin?
--Serge
It's Racket: http://faculty.cs.byu.edu/~jay/static/icfp065-mccarthy.pdf
N.
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.