I had an interesting conversation with Raganwald.
He sent me an e-mail with the subject "Bram's Law explains the FizzBuzz phenomenon." It pointed me to a blog post explaining Bram's Law:
The easier a piece of software is to write, the worse it's implemented in practice.
I replied that 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.
The conversation then moved to Avi Bryant's post on onions, and the questions it raises -- especially the question of to what extent Rails is simply doing onions better than any other onions framework out there. And then I kind of went off on a tangent:
We had a pretty interesting workshop here the other day. I was supposed to just give my "HREF Considered Harmful" presentation, the one from the screencast, but the projector was all screwed up and I ended up having to just make stuff up and write it on a whiteboard. Some of the stuff I made up didn't really make sense, so I got challenged on it. One person was like, 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. Although the flipside to Bram's law is that any time a really great language is used to solve a moronic problem you suddenly get to choose from ridiculously qualified developers to solve that problem. The Python paradox.
But the flipside to the onions thing, he also mentioned meaningful params as an onion. Some people have told me they think Avi Bryant doesn't understand the Web, and I kind of suspect it was because when you throw away meaningful params, you destroy interoperability. That's why the Rails REST stuff is all about cooking APIs directly into everything you code. Everybody loves mashups, and certainly I was using a Google Maps mashup to predict traffic on the LA freeways before Google itself added that feature. It was a win for Google -- free R&D if it implements the idea -- and a win for every person in LA who ever saw it either way. On the other hand, I heard one of the Flickr people explaining that the downside of their APIs is that they have to be able to accomodate really bad programmers pinging their servers a thousand times a day simply because those programmers don't know any better.
Now I have to admit, this "framework" which would be better than Rails for Seaside-style development, obviously that's a bold statement, and obviously this thing is vaporware in the extreme. So take it with a grain of salt. Please take it with a grain of salt, because the last thing in the world I want is an army of angry recovering PHP junkies descending on me and explaining why Rails is the best thing EVAR. I know. Rails is awesome. It's beautiful.
And forgive my hubris; if it's any consolation, I stole the basic idea from a Rails programmer who was dissing Seaside (ironically enough) in a comment that was posted on Ramon Leon's blog.
However, there's one place where it's very easy to see the benefits of Seaside's componentized, templateless style. Picture a complex enterprise application which a large corporation uses to manage logistics like shipping, billing and accounting. Say this company wants to present, to its clients, a subset of the information available throughout this huge sprawling app. You can do it with things like render :partial and render :template -- but components are more elegant for this sort of thing. And this isn't an academic example; it was a task we'd faced and for which components would have been nice to have.
One interesting and terribly tempting misuse of reflection might be to write objects which had to_html methods, which consisted of render :template calls generated dynamically from the names of the object and action called. This would move code out of the templates and back into objects, even when that code couldn't be contained in any one model, kind of like Jay Fields' Presenter layer. But is it worth doing? The answer depends on whether Rails' template system really is a big fat smelly onion or not. Are there advantages to a template architecture that I'm unaware of? There might be. I don't know.