Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Implementing Seaside concepts in Rails on Rails?

Implementing Seaside concepts in Rails on Rails?


Why is Ruby on Rails one of the most popular web frameworks? Does Ruby on Rails introduce many new and revolutionary concepts? Or does it simply offer better implementations of old, common and well-known design practices? That is the first question asked by Giles Bowkett. He illustrates his discussion by comparing the View/Controller patterns in Rails to Seaside's (Seaside is a full-stack web framework built in SmallTalk) components and rendering methods. Would it be worth replacing the Rails views/controllers with an approach more similar to Seaside?

Giles highlights the pros (e.g centralized management) and cons (e.g meaningless URLs) of such an architecture:

couldn't you just emulate Seaside's componentized nature by replacing Rails controllers and views with Builder templates containing objects with built-in render methods which call other Builder templates? And the thing was, it'd work, in fact you'd basically get everything but continuations, but the question was whether it'd be worth it if you didn't get Seaside's session management, and whether the session stuff would or wouldn't be a nightmare in any language but Smalltalk. The idea was that Rails' template system is a big fat smelly onion. We ended up with a design that would probably work much better than Rails, in fact, for Seaside-style development, and still have all the advantages of Ruby over Squeak -- easier DB/Unix integration, more developers, etc.

In the numerous comments, Assaf Arkin kindly responds by indicating how to implement a kind of template-less solution using a capture method in Rails, while Ramon Leon and Giles Bowkett go a step further and envision a best of breed solution implementing Seaside on top of Ruby on Rails.

Despite his innovative ideas, Giles Bowkett is a real Rails aficionado. The ease of development is the best Rails asset but could it turn into a weakness? That's the second question Giles Bowkett asked, fearing the Bram's Law: The easier a piece of software is to write, the worse it's implemented in practice:

...this has always been my fear for Rails; that in five to ten years, the worst jobs you could get will be Rails jobs where you're maintaining stuff built by non-programmers who figured Rails made programming so easy that they didn't really need to understand what they were doing.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • non programmers

    by Michael Neale,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I am sure people laugh at that "fear" - but it has happened before anytime, with easy to use software. Although I am thinking of office automation type stuff, like Excel, MS Access etc (they are the big ones). They were never that popular with programmers, which is one of the differences with rails. If it sticks to its current niche, I don't see any similar danger.

    But certainly, the world is powered by apps build on MS Access, Excel etc that were built by non programmers - good or bad, thats just the way it is !

  • More on this

    by Michael Pence,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I spoke with Seaside creator Avi Bryant about these concepts here:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p