Ramon Leon did the unthinkable and wrote a blog post called Rails vs. Seaside.
Of course with a title like that, you're going to get some traffic; unfortunately, just like Pat Maddox's blog post today, Java People Must Be Stupid, a title which draws in traffic doesn't always necessarily draw in a whole lot of thoughtful comments as well. Must be some astrological thing, it's a good day for provocative titles that result in minimally thoughtful discussions.
The big theme in the dumber comments on Ramon's post was that Rails is obviously better than Seaside, because you can generate HTML programmatically in Rails too. The thing is, Seaside's advantage is not the ability to generate HTML programmatically. That's like, you're packing for a trip, so you compare a black sweater and a white spacesuit, and you say the sweater's better because it's hard to keep white clothes clean. These are completely different things. The sweater might be easier to wear on the plane, but if your destination is above the atmosphere, the spacesuit is going to be your only option.
Seaside doesn't generate HTML programmatically because that approach has some inherent superiority. Seaside generates HTML programmatically because it's necessary in the context of Seaside's design, and Seaside's design is the interesting part. Seaside uses a completely distinct paradigm for Web applications, and it's a paradigm where template files are much less useful. You could add templates to Seaside very, very easily, but it would be a bad idea.
Here's why. Think about named routes. Jamis Buck praised these today, and his praise certainly had some merit. Jamis Buck is, of course, a very, very smart programmer. But think about named routes. What is a named route, exactly? If your Web application could be conveniently and comprehensibly viewed as a single codebase, what would a named route be?
Named routes would be labels, the last relic of goto still surviving in Java and Perl -- and probably many other places as well -- like a Loch Ness icthyosaur lurking somewhere in Scotland, millions of years after the extinction of all its cousins. There's a reason that the guy who created Seaside calls his blog HREF Considered Harmful. An explicit, hard-coded href is completely identical to a goto. It is the same thing. And although the implementation of named routes is beautiful, the basic idea is only slightly more elegant than the basic idea of a named goto.
Say you've got an app which you're building first without Ajax, and then with Ajax. This is a very common development practice, because Ajax is often a pain in the ass to debug. Assume you're building such an app, and assume further that all the hard stuff happens on the server side, and the Ajax stuff is just cosmetic. If you build this app first without Ajax, you get to code all the hard parts in the context of standard Rails error messages -- in effect using your server and browser almost as a de facto IDE. Then when you do the last little Ajax bit, the cosmetic bit, all you're really doing is changing the views and a few controller render calls.
If you were in Seaside, you wouldn't have to do that. Seaside views HTML as a stream, and the same component can generate the same HTML on the stream whether the stream's sent out as a complete page load or an incomplete page load. Different divs in the page can come from different objects in Smalltalk, and the same set of objects can be used for rendering as Ajax or in the original Web 1.0 style. It makes no difference at all. You have complete control. And while you can emulate that kind of componentized system in Rails, with multiple levels of nested partials, it isn't elegant at all. In fact it's so heinously inelegant that you can really only do it for trivial cases. It's kind of like the way you can really only do trivial flow control if you're using goto.
But let's take it even further. Say something changes. You have a series of steps to fill out, in a form. If Pat Maddox is working for you, you can already fill out those steps in any random order, and it's not going to matter. But in most cases, you'll have to revise your system. Like say you've got a form, and the form has twenty fields, and those fields all live inside one form which you display to the user with a render call. And suddenly you want the user to be able to enter the form fields in any order, and have them saved immediately. And further, you want these form fields to be accessible at any point, anywhere in the application, where before they were only accessible at specific points, on specific pages.
To transform a code base this way, it might be possible in Rails, if you have a good team. In fact I think that's the whole point of the restful approach, and if I understand correctly, that's why people are so excited about it.
But to transform a code base this way, in Seaside? There is no transformation. You get all that for free. It's built in. That's the whole point of Seaside. Dismantling your entire design just to save form fields in a different order isn't necessary if you aren't using the 2007 goto anywhere in your code base.
At best, a Web application framework built on URLs gives you a command-line interface in the "Location" box. At worst, you get a tangled nest of gotos. But with a continuation server, you get an entire app on every page load. Everything you need is right there. The type of flexibility and detailed control which users take for granted in desktop apps is absolutely achievable in Web apps -- but it might not be achievable with Rails.
That is the question that makes Seaside interesting. Is what Seaside does without breaking a sweat even possible with Rails?
I still work with Rails. I love Rails. I'm just saying all this to offset the stupidity of the comments in Ramon's blog about Rails being able to generate HTML programmatically. It's not about being able to generate HTML programmatically. It's about being able to generate Web apps programmatically.