Thanks for the comment – you’ve answered all of my concerns regarding Seaside (apart from the learning a new language thing, but that is what I’m interested in at the end of the day anyway). Seaside will be the next thing I take a look at, cheers.

Ian

My day job is writing web apps in Seaside, so I thought I’d try to answer your questions.

Scaling is always a contentious topic, but here are some things I’ve observed. Seaside apps tend to use more memory than REST applications, simply because they store all those continuations. Not huge amounts, but enough that when scaling an app up, it’s one of the things to keep an eye on. Fortunately Seaside has tools for memory profiling, so you can measure just how much memory is used by a given session, and what’s being stored.

The other scaling issue is session affinity. Since Seaside stores continuations and callbacks in memory, all the requests for a particular session have to be handled on the same server. These means some load-balancing schemes won’t work with Seaside.

On the other hand, you can run Seaside apps on a cluster of webservers, so scaling becomes a matter of adding hardware. Once you exhaust that strategy, you’re probably in Amazon/Ebay/Google land, where all bets are off anyway.

As for editing components via a browser, Seaside runs in one of two modes. “Development mode” includes lots of tools and utilities that make development easier: halos, time profiling, memory profiling, HMTL validation, and yes, a component for editing the code for other components. All that is turned off in “deployment mode,” so you don’t have to worry about random users monkeying with your app.

The editing component makes a really cool demo and can be handy in a pinch, but it can’t hold a candle to the Smalltalk IDE, so nobody uses it for day-to-day development anyway.

Hope this helps,

Colin