Scalatra vs Unfiltered vs Lift vs Play

On Wed, Sep 21, 2011 at 10:48 AM, Kevin Wright 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...

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.

On 21 September 2011 18:55, Raoul Duke <raould@gmail.com> wrote:

On Wed, Sep 21, 2011 at 10:48 AM, Kevin Wright <kev.lee.wright@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...

On Wed, Sep 21, 2011 at 11:00 AM, Kevin Wright 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.

That sounds pretty cool :-)

On 21 September 2011 19:27, Raoul Duke <raould@gmail.com> wrote:

On Wed, Sep 21, 2011 at 8:23 AM, Adam Jorgensen
<adam.jorgensen.za@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?

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.

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...

You might be thinking about LINKS:
http://homepages.inf.ed.ac.uk/wadler/topics/links.html

On Wed, Sep 21, 2011 at 1:16 PM, Florian Hars wrote:
> Silver bullets are currently out of stock.

nice!

Indeed, everything you write is true and silver bullets are almost always out of stock.
Web development tends to be about picking the lesser of available evils in order to producesomething that you're, at most, 95% happy with.
Obviously the trick with client-side state is to avoid putting anything with securityimpacts in it, even if this means that you use server-side sessions (Which some people from the pure no-shared-state-world despise but I personally see the utility  of) or something equivalent to store said data.
The issue of heavy-database loads due to shared nothing can and should be mitigated with the use of some kind of fast caching layer to reduce the number of DB hits as much as possible. Of course, caching is not appropriate forevery scenario and it does introduce complexity overheads but the performancegain is often worth it.
When it comes to shared-state on the server-side it's ultimately no so black-and-whiteas it can seem. For example, I personally don't mind the shared-state provided asa baseline with PHP: Every request happens in it's own isolated thread/process and state is shared via a standard session system. On the other hand, my current job involvesworking on a large, extant Python web application that is built along the Application Servermodel and I am overall not happy with the amount of state sharing not to mention a few other bits and bobs that make me cry once a week :-/
On 21 September 2011 22:16, Florian Hars <florian@hars.de> wrote:

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.

Kevin Wright wrote:

> 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

Swarm development is now happening here:https://github.com/sanity/Swarmand it's actually been quite active over the past year.
I haven't looked at it properly yet but there's a sort of twitter clone done in swarm which might be relevant to this discussion.https://github.com/sanity/Swarm/blob/master/swarm-twitter/core/src/main/scala/swarm/twitter/SwarmTwitterTemplate.scala

-Rob
On Thu, Sep 22, 2011 at 8:15 AM, Serge Le Huitouze <serge.lehuitouze@gmail.com> wrote:

Kevin Wright <kev.lee.wri...@gmail.com> wrote:

> 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

On Wed, Sep 21, 2011 at 6:27 PM, Raoul Duke wrote:
> maybe racket scheme?

It's Racket: http://faculty.cs.byu.edu/~jay/static/icfp065-mccarthy.pdf

N.

Please let me introduce Xitrum:
https://github.com/ngocdaothanh/xitrum

To give it a try, install SBT and giter8, then run:
g8 ngocdaothanh/xitrum
cd my_project
sbt run

Xitrum is lightweight. To see all its dependencies, from the above
directory:
sbt xitrum-package
ls target/xitrum/lib

Ngoc

Hi Ngoc,
Any example apps for xitrum?

On Sep 22, 4:58 am, ngocdaothanh wrote:
> Please let me introduce Xitrum:https://github.com/ngocdaothanh/xitrum
>
> To give it a try, install SBT and giter8, then run:
> g8 ngocdaothanh/xitrum
> cd my_project
> sbt run
>
> Xitrum is lightweight. To see all its dependencies, from the above
> directory:
> sbt xitrum-package
> ls target/xitrum/lib
>
> Ngoc

Sure Donny: https://github.com/ngocdaothanh/comy

On Sep 23, 1:33 am, Donny Oliver wrote:
> Hi Ngoc,
> Any example apps for xitrum?

Sorry, Thunderbird saved like seven drafts and they all showed up in Conversation view, so I thought it had sent it a few times.

On 09/08/2011 09:30 AM, John Cheng wrote:

CAJzZBASwzdVN7p4W-jZ1mE36QKAEnfZP-NO14Lp+kUA1mfPyzQ [at] mail [dot] gmail [dot] com" type="cite">

On Wed, Sep 7, 2011 at 5:23 PM, Naftoli Gugenheim  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.

That makes it a different "it." :) Just like Java may be easier to learn than Scala, but transforming a List is a lot easier in Scala (and not very hard to learn how to do).

CAJzZBASwzdVN7p4W-jZ1mE36QKAEnfZP-NO14Lp+kUA1mfPyzQ [at] mail [dot] gmail [dot] com" type="cite">

 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.

It may be easier to learn, but I can't think of anything you would want to do in real life that's easier to do with a String, and I can think of many, many things that are much easier with a NodeSeq.

CAJzZBASwzdVN7p4W-jZ1mE36QKAEnfZP-NO14Lp+kUA1mfPyzQ [at] mail [dot] gmail [dot] com" type="cite">

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. "

Fine, but my main question was, how does "not leaking primary keys" make things harder? Not having to send state back and forth, instead just associating a function, makes things much easier if anything.

CAJzZBASwzdVN7p4W-jZ1mE36QKAEnfZP-NO14Lp+kUA1mfPyzQ [at] mail [dot] gmail [dot] com" type="cite">

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.

Again, but is your experience of difficulty learning one or the other a property of the design of the actual software? Or is it a property of the learning experience one is treated to by the documentation?

CAJzZBASwzdVN7p4W-jZ1mE36QKAEnfZP-NO14Lp+kUA1mfPyzQ [at] mail [dot] gmail [dot] com" type="cite">

> Any example apps for xitrum?

Sure Donny:
https://github.com/ngocdaothanh/comy

A screenshot (the Japanese UI is for demonstrating i18n feature):
http://tinyurl.com/3fcx98c

Ngoc

Sorry to jump in.

Please let me introduce Xitrum, a younger web framework:
* Source: https://github.com/ngocdaothanh/xitrum
* Doc: http://ngocdaothanh.github.com/xitrum/
* Mailing list: https://groups.google.com/group/xitrum-framework

To give it a try, install SBT and g8 (https://github.com/n8han/
giter8), then run these commands:
g8 ngocdaothanh/xitrum
cd my_project
sbt run

Xitrum is lightweight. To see all its dependencies, run these commands
from the above directory:
sbt xitrum-package
ls target/xitrum/lib

To see a sample project:
https://github.com/ngocdaothanh/comy

Its screenshot (the Japanese UI is for demonstrating i18n feature):
http://tinyurl.com/3fcx98c

From README:
--------------------
Xitrum is an async and clustered Scala web framework and web server on
top of Netty and Hazelcast:
* It fills the gap between Scalatra and Lift: more powerful than
Scalatra and easier to use than Lift. You can easily create both
RESTful APIs and postbacks. Xitrum is controller-first like Scalatra,
not view-first like Lift.
* Annotation is used for URL routes, in the spirit of JAX-RS. You
don't have to declare all routes in a single place.
* Typesafe, in the spirit of Scala.
* Async, in the spirit of Netty.
* Sessions can be stored in cookies or clustered Hazelcast.
* jQuery Validation is integrated for browser side and server side
validation.
* i18n using GNU gettext.
* Conditional GET using ETag.

Hazelcast also gives:
* In-process and clustered cache, you don't need separate cache
servers.
* In-process and clustered Comet, you don't need a separate Comet
server.
--------------------

Xitrum is in usable form and has been used in several production
commercial projects. Please try it and give comments etc. so that I
can improve it.

Thanks,
Ngoc

A sample project, to see how a project using Xitrum looks like:
https://github.com/ngocdaothanh/comy

Its screenshot (the Japanese UI is for demonstrating i18n feature):
http://tinyurl.com/3fcx98c

Ngoc