On Jan 12, 2006, at 1:05 PM, Blake wrote:

> I'm working on an article on Seaside for DevSource (which is  
> oriented around Windows programmers, but which the editors have  
> also found that actual code, regardless of platform, is more  
> attractive to readers than anything else) and was wondering if  
> anyone here had any experiences they wanted to share on using  
> Seaside versus using other technologies.
>
> It appears to me that all these technologies are primarily  
> concerned with preserving state in the stateless environment of the  
> web. Is there more to it than that, really?

I see the issue of preserving state as being more of a means than an  
end.  When I'm pitching the importance of Seaside I tend to focus on  
two things:

- reducing the amount of context a given piece of the UI model has to  
know to be useful; that is, having web pages that don't have to know  
which page came before them or which might come after them, and  
having sections of a web page that don't know which sections surround  
them or which they enclose.  This just sounds like Encapsulation 101  
but it's absolutely *not* standard practice in web development,  
despite the obvious maintainability advantages.
- reducing the manual bookkeeping work required when transferring  
messages between the server and the client.  Traditional web  
application development spends an obscene amount of time shoehorning  
data into strings in URLs and form fields and making sense of those  
same or similar strings that get pulled out of subsequent HTTP  
requests.  In Seaside you never see anything at that level unless you  
really, really want to, and that alone can cut development time  
literally in half or more.

Now, both of these things are indeed *enabled* by the approach to  
state management, which is to keep a huge amount of it active, in  
memory, for each web session.  I joke that Seaside takes a "share  
everything" approach, in contrast to the conventional wisdom of  
scalable web application development which is "share nothing" (ie, be  
able to recreate the full state from scratch on every request so that  
any server running the same code could handle it).  Rails,  
incidentally, comes down very vocally on the "share nothing" side so  
I wouldn't characterize it as being "primarily concerned with  
preserving state" at all.  You might say that Rails is concerned with  
building elegant and convenient models of statelessness, whereas  
Seaside is concerned with abstracting the statelessness away to the  
point that it feels stateful.

> Also, is there an advantage, do y'all think, in Smalltalk having a  
> plug-in VM? That is to say, do you think it's easier to segue from  
> Seaside to a rich-client type experience in Smalltalk than these  
> other technologies?

Not in the sense of actually integrating with rich clients, no (or  
not enough to matter).  Somewhat in the sense that the general feel  
of Seaside is much closer to that of rich client development than  
most web technologies provide.

BTW, it's very cool that you're writing this article - are you going  
to post it to the Seaside list for feedback before sending it off?
Cheers,
Avi