Oh yeah. It's only a superificial similarity. From the Seaside perspective, I think it's most interesting as an irony.

I think I'd like to look at the internals, though. I'm wondering purely for the sake of it if it could be made more Seaside-y. Rails basically does the controller stuff first, bundles up instance vars, and passes them to the view. I can think of some kludgey ways to integrate callbacks, but I don't yet see an elegant one.

If I get REALLY lucky, I'm going to be able to deploy something in Seaside internally, at my current contract. I haven't figured out the best thing to create to make use of this opportunity, though. I'd like to build something in Seaside that couldn't be built in anything else. Definitely still at the "hmmmmmm" stage with that.

HA good one. But Giles from this post and your comment posts it seems like your subconcious is pushing you towards using seaside more and more. Two questions: 1. is that true? 2. How do you deploy seaside for a 'production' environment? cause I have no idea.

For example my prod rails environmment consists of mongrel clusters and nginx, what special things do you do for seaside?

Also another thing that is surprisingly not coming up in your blog is the growing rebellion to Flex + RubyAMF + rails they achieve this same kind of view utopia that we so desperately are seeking, yet for the most part are still getting shunned. Peter Armstrong who seems to be the lead proponent of this movement has actually got some pretty good ideas and is even got a book! What are your thoughts on that movement?

I definitely want to do more with Seaside. It's just a matter of the right context. I can't just build an app and maybe people will come. I need to have a more specific goal. We were talking about doing some work with Seaside at my last company, and where I am now, if I build something useful with Seaside, people will use it. So it's really just a matter of building something cool at this point. I think I'll probably make something hella Ajaxy with an insane number of callbacks and stuff. (Seaside's support for Ajax works a lot like Rails', but seems a good deal more concise.)

I dunno. I think in terms of functionality and features, anything that can be done in Seaside can be done in a different framework in a different way. I think the key is doing something in Seaside that would be godawfull in another framework, but doing it easily.

@nima:

Check out On Smalltalk. Ramon Leon did some posts a while back on how to deploy and scale Seaside, using Apache. You use pretty much the same techniques and technologies as you would use for RoR to scale it. Both use a similar scheme for serving pages. RoR has its own internal http server. So does Seaside, called Comanche.

@mark - actually RoR ships with a toy server called WEBrick, but doesn't have any internal HTTP. Also WEBrick is kind of semi-deprecated in favor of Mongrel, a better server written in Ruby and C. (Semi-deprecated because I think Rails still ships with WEBrick but defaults to using Mongrel instead, even though Mongrel is a separate package.)

In terms of the whole "could be done in anything, but only fun in Seaside," that's really what I meant.

On Smalltalk is a very good blog. Much more detail on Seaside than you'll find here.