OSCON 2006: Web Heresies: The Seaside Framework

Kevin Yank
Tweet

This week, Kevin Yank is reporting from OSCON 2006 in Portland, OR.

Avi Bryant has the dubious distinction of being one of the few web geeks with an avid interest in Smalltalk, and has created a web application development framework that suits his particular fancy. That framework is Seaside. As it turns out, Seaside also breaks a lot of the conventional wisdom that is embraced by many other web frameworks, and those “heresies” are what Bryant focused on in this talk.

The first of the rules broken by Seaside is that web designers are responsible for producing HTML code. Many other frameworks go to great lengths to provide sophisticated template systems that allow developers and designers to work in tandem on the HTML of an application without stepping on each other’s toes (in theory). Seaside abandons this approach, and generates all HTML code from Smalltalk code within the application, based on the theory that, if the HTML code that is generated is semantically meaningful, all the designer should really need is to write the CSS code that styles the HTML.

One of the nice side-effects of this approach is that you don’t need to lose sleep over things like assigning names to form fields, as these can be generated automatically by the framework, in much the same way as session IDs are generated by most other frameworks.

Speaking of sessions, Seaside doesn’t bother serializing them, which is something that most other frameworks go to a lot of trouble to do. Bryant argues that the problems that serialized sessions are designed to solve—the need to share sessions between load-balanced servers, and the need to fail-over in the event of a server crash without losing any active sessions—are non-issues. As a result, Seaside stores all sessions in memory.

Again, this has freeing consequences. Sessions can contain crazy things like closures, or even continuations—meaning the code that responds to a request can effectively “pause itself”, store its state (the execution context) in the session, and send a response to the browser that prompts the user for some information. When the next request comes through with the information required, the execution context is retrieved from the session and the code continues to execute where it left off. Suddenly, multi-page form workflows become trivial not only to implement, but to modify (say, by reordering the steps).

Seeing this stuff in action is frankly astounding for someone like me who spends most of his days stuck in the PHP/Java/whatever mindset, and the natural tendency is to just assume that this is cutting-edge, experimental stuff. But Seaside is at the heart of applications that have been in production use for up to five years at this point!

Of course, Seaside is based on Smalltalk, which is a development environment that is quite different from the mainstream platforms. So this isn’t something you can just hop into and get something running in a couple of hours. But there are certainly lessons to be learned from the common assumptions that Seaside has refused to accept.

Get your free chapter of Level Up Your Web Apps with Go

Get a free chapter of Level Up Your Web Apps with Go, plus updates and exclusive offers from SitePoint.

  • didimo

    Heh my own framework uses database to store temporary and permament session, allowing me to store large objects in a session, the nice thing is that this scales quite well my latest project involves hundreds to thousands of users being online simultaneously

    I found Memory tables perfect for this task, also innodb is surprisingly fast (im using mysql5,php5.1.4,apache2.2

  • http://www.sitepoint.com/ Kevin Yank

    didimo,

    I’m afraid you missed the point. Even storing sessions in a memory table requires you to serialize the session data. You can’t store the current execution context, including the call stack, in a database.

  • mde

    I was in the Seaside session too, and it was kind of astonishing to see what you can do when you set aside a lot of the traditional approaches to developing a Web app.

    On the other hand, the idea of using programming code to generate your markup isn’t all that heretical to client-side developers who do it all the time with JavaScript. :) We just do it right there on the client instead of going back to the Web server for it.