Saturday, July 28, 2007

It Isn't X vs Y

So I hate to admit this, but now that OSCON is over, several days after delivering my presentation on Seaside and Rails, I figured out the actual conclusion.

People have taken my posts on Seaside and Rails as if they were discussions of Seaside vs. Rails. That just isn't the case; in fact it's silly. What it's really about is that there are design differences between these two frameworks, and while I don't think either one is the answer, I do think both are way better than everything else out there that I know about.

Rails' assumption that building REST into your app at such a level that APIs are almost auto-generated by default is the right way to do things; Seaside's decision to give Web app developers the same kind of power that desktop developers have is also the right way to do things.

When you look at Rubinius, it's entirely possible Avi Bryant's hypothetical Ruby virtual machine could in fact happen very soon. At that point, features of Seaside which were previously only available via Smalltalk will become available to Rails. At the same time, Gemstone is doing work to make Seaside applications much easier to deploy. Object databases like Gemstone's are pretty much necessary if you want to handle particular problem spaces, such as warehousing and inventory systems. Object DBs already exist for Java, so JRuby will make object databases available to Rails applications, which means you could use Rails for gigantic enterprise problems suited to object DBs. But if you did that, you'd need to rewrite ActiveRecord, since object databases give you active records by definition.

Basically, I'm indulging in some amateur futurism here, and there's lots of interesting things happening on that horizon.


  1. Liked the post. In a post I did recently I talked about a speech Alan Kay gave 10 years ago where he was talking about the semantic web. His conception of it was to make every object a server, and therefore each object should have its own URL. It actually maps fairly well to the way RoR does things, if you implement the notion that each page in a Rails app. corresponds to a unique object. When he said that it sounded a lot like what I've heard described about REST. He even went so far as to say each object should have its own IP. Yikes! From what I've heard the internet actually ran out of IP addresses a while ago, and has managed to keep going by some sort of IP virtualization mechanism.

    What's interesting is that Kay likes the internet fine, but is not so keen on the whole HTML browser paradigm. He said in his speech that this just recapitulates platform lock-in similar to MS-DOS, not in the sense of a particular browser being dominant, but that the browser itself, as a platform, is dominant. It defines and confines what protocol can be used on the client.

    His notion of the web was that clients would download the software necessary to interpret/render the data, and presumably the data formats would be simple. In my estimation this would've required a whole different operating system architecture.

  2. Kind of rethought what I said. In the case of creating aggregate pages, where each object is part of a page, this would fit in Kay's model if each component had its own URL, and could be accessed independently of a particular page or application. This fits very well with the idea of mashups.

  3. I think ActiveRecord, as it is currently constructed, may turn out to be Rails's biggest liability in the long run. As it already takes us so close to a fully object-based entity model, why not just take the logical next step, to a real object database backend (say, CouchDb or something like GemStone)?

    This would mean not having to put up with DRY violation (your schema, associations and constraints spread out over the RDBMS itself, the Rails model, and your migrations) and indeed eliminating any other vestigial remains of the object-relational impedance mismatch.

    I think that forcibly stuffing all our data into RDBMSes is equivalent to pushing bits around using machine language. Time to raise the abstraction level, maybe - but can Rails survive the paradigm shift?


Note: Only a member of this blog may post a comment.