Seaside without Continuations?

Seaside has become the de-facto standard of Web Frameworks in the Smalltalk world: it is available on all relevant dialects and has introduced quite a few new ideas to Web Application programming that were adopted not only in the Smalltalk world. Seaside was and still is a somewhat different framework because it throws away many concepts that had been thought of as being crucial for web development. I’m not going to go into the details on how Seaside ignored the Share Nothing Principle and threw No State on the Serverside overboard.

One of the features Seaside came up with are Continuations. These allow a web app to fully respect the Back Button by rolling back all changes you’ve made on one page. This made transactional behaviour of web applications a no-brainer: with #call:/answer:, #isolate: and the class WATask you could suddenly make your web app behave just like a modal application as it was on your fat client. Thus a Seaside Application was pretty much like a fat client application that walks you through modal windows and dialogs. This is especially interesting if you want to port a fat client application into the web with as little effort as possible (Here’s a presentation I gave on the topic at the VA Smalltalk Forum Europe 2008).

Instantiations was quite late in the game of supporting Seaside, and due to some restrictions in its virtual machine that are still not solved (but have been announced for the next version of VA Smalltalk), it doesn’t support Continuations. While this makes learning Seaside on VAST a bit harder because the VAST port does not support call/answer and isolate or WATask (some of which simply lead to weird error messages), it is by far not as bad as you might think.

Even Avi Bryant, one of the Masterminds of Seaside, repeatedly stated that Continuations are far less important than they thought in the early days. Last time he talked about this was in his Keynote at Smalltalk Solutions this year where he made the point that if he rebuilt Seaside today, he’d do it without Continuations among other substantial changes. He also made the point that what he’d do would also be a radical change to web frameworks like Rails or Django, btw.

So why is that? Why are Continuations not as important as we thought they were 7 years ago?

First of all, since most web frameworks back then had no Continuations, most web applications in the wild had no support for isolating operations in the way Seaside introduced it. Try adding an article to your shopping cart on Amazon and press the back button: the article will still be in your cart. So the behaviour that would be “right” from the point of view of Seaside, simply didn’t make its way into the mainstream of web applications. So using Continuations that way would baffle your users.

Second, web applications have come a long way since 2004: a page is not a single form, but an assembly of components, each with their own mechanics and state in them. This only proves that Seaside’s approach of composable pages from Components was right, but on the other hand means that a page in the Browser would mean keeping many Continuations per page. Not that Seaside couldn’t do that, but it brings quite a few potential problems, beginning with memory consumption and all possible problems with objects shared between tiles/components on your page. Continuations can get in your way and cause real hard problems in data consistency in such complex pages. And by the way: what does pressing the Back button mean on a web page that displays 9 different components? Does the user want to roll back only the changes he made in one of them or all? So the way most Web applications work today doesn’t fit well with Continuations.

Lastly, the massive use of JavaScript and Ajax for means that changes to your object model happen between full request/response cycles, so the whole machinery in Seaside is being circumvented and therefor lead ad absurdum. It has been discussed in the Seaside community if supporting Continuations in Ajax-Callbacks would be possible. It seems it could theoretically be done, but consensus seems to be that it’s not worth it.

So the use of Continuations in Seaside can help make writing a web app easier, but the more interactivity and modelessness you want in your app, the less you should use them in order to prevent problems.

I am neither saying that Continuations are useless, nor do I think they make Seaside any less helpful. But the more I work with Seaside without Continuations, the more I come to the conclusion they are not as helpful as they promised to be in the beginning. Having worked in both VisualWorks with Continuations and VA Smalltalk without, I prefer not to use them. I’ve posted a few comments on how to work in Seaside without Continuations and I also do give Seaside courses and it seems our coustomers like living without call/answer and isolate.

8 thoughts on “Seaside without Continuations?”

it wouldn’t be the first time I am. 😉
I’d be interested in learning more about the difference. Do you have any pointers to more details on that?
Is it possible that Backtracking was relying on Continuations in earlier versions of Seaside, say 2.6 and 2.7?

Continuations allow for control flow over multiple requests, eg. asking the user for input. Backtracking pins the state of objects to pages. So if you go pages “back” their state goes back. There is now relationship between those two. One messes around with objects (usually just components) and their state, the other messes around with stack frames.

I’d like to say something qualified about Iliad and AIDA, but I must admit I know way too little about them. I’ve been following Janko’s tutorial on AIDA at ESUG 09 in Brest, and besides that being way to little to really justify, I somehow had the feeling I don’t like it as much as I like Seaside. I would love to take some time and look into Iliad, because it seems its approach to rendering in general and its use of JavaScript is much “cleaner” than in Seaside. But this is only after a few minutes of hacking in Gnu Smalltalk/GST and reading a bit on Nicolas’s blog and skimming through some documentation.

So I am not in a position to compare the three in a fair manner. And my time is too limited to get any deeper. So I agree it would be great to have such a comparison, but I won’t be able to deliver one for some time.

No worries, I don’t have the knowlegde either so I thought I’d ask you 🙂 As you may know, Nicolas and co are in the process of writing a Smalltalk repository to replace the ailing SqueakSource called SmalltalkHub. SmalltalkHub is based on Iliad and Pharo, but the idea is for it to serve Pharo and Squeak but also potentially “any” Smalltalk implementation. I believe Janko has already ported Iliad to VW so it would be great to have it ported to VAST as well.