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
Locked
