Seaside: an elegant web framework in Smalltalk

I've been playing with a web framework called Seaside and I think it's very interesting. Coming from a background in Perl, mod_python, and Django it really makes you think again about the best way to design and build web applications.

Seaside provides inspiration for where web frameworks are heading, away from the technicalities of HTTP requests and back towards something more direct like desktop UI programming.

Here's the best bit I've seen...

Imagine you have a delete method on a record that the user can call by clicking on a Delete button on a web page, but you want them to confirm the delete first, here's how you do it in Seaside:

Here's the bit that renders the button -- this is in the app code, not in a template (there are no templates) -- notice the callback:

html anchor
  callback: [ self removeContact: aContact ];
  with: 'remove'.

And here's the removeContact code, actioned by the that callback above:

removeContact: aContact
  (self confirm: 'Are you sure you want to remove', (aContact asString))
  ifTrue: [ Contact removeContact: aContact ]

That 'confirm' bit actually interrupts the method, renders a web page with the confirmation form, then restarts the method passing back in true/false. There is no URLs, no templates, no fiddling about with param decoding, just concise code. I think that's amazing!

From Wikipedia:
Over the last few years, some best practices have come to be widely accepted in the web development field: 
  • Share as little state as possible.
  • Use clean, carefully chosen, and meaningful URLs.
  • Use templates to separate the model from the presentation. 
Seaside deliberately breaks all of these rules; Avi Bryant describes it as a 'heretical' framework. He argues that this careful and reasoned rejection of the conventional wisdoms of web development has led to a very effective model for the development of web applications.
More info:

Previously I wrote:

"I'm not planning to do any real client development in it yet but I think it could provide inspiration for where web frameworks are going." I would love to program some real Seaside web apps but I'm not ready yet, see discussion of this below.


  1. You write "I'm not planning to do any real client development in it yet but I think it could provide inspiration for where web frameworks are going.".

    I've read many commnents like this for quite a few years now. It's as if everyone is saying "Very nice, we're impressed, go on with the good work but excuse me while I get to get back to the real world" (or something like it).

    Relatively speaking, hardly enyone is using it. Why not? Is it just the culture shock of using Smalltalk?

    1. I think Smalltalk is fantastic, and I was amazed to discover that such an elegant language has been around for such a long time. It is a culture shock coming from more mainstream languages, for example working in the image with live objects, but once you get it, everything else seems very basic.

      I think my problem with using Seaside for 'real work' is not the quality of the framework, which is great, but that the ecosystem is (currently) very small, and I can't tell whether it's on the up, or declining. The website looks like it's pretty dormant right now, with most posts and info dating back a few years, which doesn't help.

      Also, much of my work is paid for by clients, and they are becoming aware of the technology used to build their site. Djanjo is a relatively easy sell, but Smalltalk/Seaside isn't.

      Having said all this I'm looking for real world uses of Seaside, so we'll see...


  2. Amber is a Smalltalk variant that, rather than using Seaside, compiles to JavaScript and can use any JavaScript libraries (node, backbone, etc.). Personally I'd rather use a full fledged Smalltalk, but for small projects you might otherwise consider Node.js for Amber is a great alternative.

  3. Interestingly, the main area for professional use of Smalltalk is in production automation, particularly in embedded systems control mechanisms. Where something absolutely has to work, Smalltalk is used. Where a few bugs / crashes here and there don't matter, something less productive / more expensive is used. It makes little sense, but there you go.