
Seaside – Developing Sophisticated Web Applications in Smalltalk - nikolay
http://seaside.st/
======
cousin_it
Ooh, this brings back memories. Continuation-based web frameworks were my
original gateway drug to "exotic" programming techniques. Dabble DB was the
poster child of Seaside, but didn't get much traction and was acqui-hired by
Twitter, whereupon Avi Bryant moved on to other pastures. The other high
profile examples of continuation-based web development were Paul Graham's
Viaweb (which was acquired by Yahoo and rewritten with more traditional
techniques) and Hacker News (which had usability problems due to continuations
and mostly phased them out). The verdict of history is clear: continuation-
based web development is a sexy but ultimately misguided idea.

~~~
dang
Great comment, but I don't think I agree with your conclusion. HN still has
closure-style handlers [1] all through the code—60 or so as of the latest
commit. We phased out the ones that were being invoked millions of times, but
I'd emphasize that our reason for doing this was implementation-driven, i.e.
accidental rather than essential. (This, by the way, is true of many alleged
"verdicts of history" in programming. Those who care about good ideas should
treat such arguments as guilty until proven innocent, lest we all get sucked
completely into popular practice.)

Writing the code to phase out those handlers was a deep lesson for me, because
the new code came out more verbose and harder to follow. One rarely gets to do
an apples-to-apples comparison of programming techniques on a production
system, and somewhat to my surprise the experience convinced me (I was
agnostic to begin with) that the closure approach is superior.

There are at least four reasons: (1) the closure has immediate access to all
the state that existed when the request was previously processed; (2) the
closure is nested inside the code that creates it, so everything you need to
understand a full request cycle is in one place; (3) much boilerplate is
eliminated, making the code easier to read and write—it can be explicitly at
the problem level; (4) security is less of a worry when the client only has to
pass back a token instead of all the original parameters to the request, the
latter being safely packed away in the closure. That last advantage, i.e.
reduced attack surface, was particularly surprising.

Learning this the hard way, by dismantling those advantages and replacing them
with manual code in selected cases, taught me something else about this
design: it's more than just a clever device. It's really a triumph of two of
the greatest programming ideas: first-class functions—more specifically, what
used to be called upward funargs [2] back when people were arguing about
whether they were a good idea—and lexical scoping. The combination of those
two abstractions is what allows this model to shuffle off most of the
gruntwork instead of making you, in pg's memorable phrase, a human compiler.

The fact that the design eventually hit scalability problems at millions of
users is also a vindication of it, in the sense that it enabled pg to write HN
more quickly and safely in the first place. We could selectively deal with the
scalability problems later, and have done so. That has worked fine as an
engineering tradeoff, but IMO a better solution will come from new
implementation ideas that allow another couple orders of magnitude of closures
to be kept without slowing down the rest of the system. If we get there, I
will take pleasure in rolling all that manual code back into the original
design.

1\. They're closures, not continuations, which for HN is fine.

2\. Meaning the ability to return a function from a function, and thus keep it
around indefinitely, as opposed to passing a function to another function as a
parameter (downward funargs).

~~~
cousin_it
Yeah, all fair points.

Client-side AJAX apps also allow you to keep state from one request to the
next, instead of tossing it back and forth over the net. You can use closures
on buttons and everything. In some ways it's even more natural than keeping
state on the server, because the client knows exactly how long the page stays
open. And it doesn't break when you have lots of users, because they keep the
state instead of you. I guess that's part of the reason why AJAX got so
popular :-)

That said, if I were building a site like HN, I wouldn't use any of that
stuff. I'd go with a bog standard request-response model. There's just not
that much state to be preserved. Except maybe draft comments, but these should
go in browser storage anyway.

~~~
dang
Re Ajax, yes, but there's plenty of state that you can't send to the client.
For HN, an example would be the list of known spam sites.

> _There 's just not that much state to be preserved_

Are you sure? From my perspective there's enough to make the complexity
difference in the two models significant.

~~~
cousin_it
No, I'm not sure. But from a quick look, it seems like most GET handlers on HN
take at most two parameters, except for "flag" which takes three. The POST
handlers take more, but that's stuff that needs to be sent to the user anyway,
because the user is editing it.

Out of the stuff that I did see, the "goto" parameter is the most obvious
candidate for the closure treatment. It's also the most obvious candidate for
the AJAX treatment, if you add in-place editing like on Reddit, which would be
a better UI in my opinion.

Sorry if that sounds arrogant! Of course there could be a lot of functionality
that I've missed.

------
muraiki
Developing webapps in Seaside is a lot of fun. The ability that Smalltalk
gives to you in terms of having a live coding environment, coupled with being
able to debug and modify Seaside code in the browser while in development
mode, is really powerful. When I first started learning how to program,
learning Pharo and Seaside was of tremendous help in understanding how things
work. After having used components to build webapps in Seaside, I was
simultaneously amused and saddened when I saw it hailed as the next big thing
years after Seaside had already done it (disclaimer: I've probably now opened
myself up to someone telling me that it was done before Seaside did it!)

The free "Dynamic Web Development with Seaside" book guides you through
creating an ajax webapp, but the last time I checked the chapters on
persistence were kind of weak. That being said, for toy webapps it's
sufficient to just save the state of the Seaside image, with a singleton as
your "database".

~~~
igrekel
Indeed, the big plus is really that when an error happens, you can save the
state and open a debugger right where the problem happened resume execution.
This was a big help when I'd get home at night, I would check if there were
errors during the day and would fix them right in the debugger.

------
polotics
Seems to me that the Nagare framework is the closest match in Python.

~~~
klibertp
Yes, it's explicitly said in the docs that it's based/inspired by Seaside[1].
But note that - last time I checked - Nagare requires Stackless Python and not
the standard interpreter. That's because Stackless lets you serialize tasklets
and stack frames, which is impossible in normal Python without a custom C
extension. It also lacked many useful features, like any kind of
authentication handling (but, being WSGI compliant, you probably can plug some
middleware to handle this).

[1]
[http://www.nagare.org/trac/wiki/NagareFeatures](http://www.nagare.org/trac/wiki/NagareFeatures)

------
remontoire
This approach to webdev (continuations) could be so cool. I just wish there
was a framework on the level of django/rails so that I could feel comfortable
using it for a large product.

~~~
tbje
The Lift web framework in Scala is somehow similar in that aspect. It has been
used on multiple bigger sites like foursquare. I really like the approach
compared to MVC.

~~~
eggy
Racket does stateful and stateless servers, and the continuations are either
stored on the server or the client per which type you choose to implement [1].

    
    
      [1]  https://docs.racket-lang.org/web-server/

------
mariodiana
Can I ask: assuming that Smalltalk and Seaside are the bee's knees, who are
your customers? Who do you sell Seaside solutions to?

I'm not a Smalltalk developer; I ask this as someone who finds himself missing
Objective-C's dynamism when programming C# or Java, so I'm sympathetic to the
advantages of Smalltalk. But customers know .NET and Java. That's not a hard
sell.

~~~
igrekel
Personally I still have a seaside application, I sell the service so clients
get a user account on the web application that I host myself. I wouldn't
attempt selling the application as something a client would continue
developing on.

------
Jack5500
I wrote a Monopoly Clone in Seaside for University. The framework was really
intuitive, but the documentation could use some work.

------
fahrradflucht
Not responsive :(

~~~
Jack5500
Well, it's as responsive as design it to be. The framework only gives you the
building blocks(tags), you can still use bootstrap or your own responsive
design with it

~~~
astares
Smalltalk is the most lively environment you can have. Pure OO with direct
feedback. Not the usual dead code in files with long cycles as in more
mainstream technologies

There is a bootstrap package for Seaside, check out the demo page at:
[http://pharo.pharocloud.com](http://pharo.pharocloud.com)

It is true that meanwhile single page applications have hit the client web
space - but you can address them easily with the Seaside-REST package (for
instance sending JSON to clients side AngularJS). If you need a framework with
less footprint check out "Teapot" which you can easily run on Pharo
([http://www.pharo.org](http://www.pharo.org)).

------
mostafaberg
Irrelevant funny comment, but everytime I read Smalltalk I imagine this
scenario:

Jim: Yo bob!, how's it going man?

Bob: Not so much, what's going on your side?

Jim: Nah, not so much, how's your family?

Bob: They're fine, how's your wife?

Jim: All is good man, all is good...

Bob: ....

Jim:.....

Bob: Hey we should make a webapp together!

Jim: That would be totally rad !..

Jim: .. I've even heard there's a sophisticated webapp framework for people
having a smalltalk like us!

Bob: Whoa that's cool !, let's get on it man!

Jim: Smashing!!, But what kind of app should we work on?!

Bob: I don't know let's just download it and make something simple

Jim: Darn, it's only made for sophisticated webapps, says so on their
website:(

Bob: Naaah, life sucks man, lets wait till they support simple stuff in the
future

Jim: Sure thing, let's take it in our next smalltalk, gotta run now I have a
scrum!

Bob: Ok, I'll get my coffee and leave before no one notices I don't even work
here!

Jim: K man, cya!

