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.
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 !