stevedoria.net

After delving into Ruby and Rails, I have felt the following but never got around to writing about it. I have since abandoned the adoption of Rails, but I recently stumbled upon a newsgroup post that expresses what I think about the framework (but with examples that I would not have produced without more experience):

Newsgroups: comp.lang.lisp
From: Maciej Katafiasz
Date: Mon, 21 Jan 2008 12:47:45 +0000 (UTC)
Local: Mon, Jan 21 2008 7:47 am
Subject: Re: OT: Rails is shitty
[was top down programming in a bottom up language]
Den Mon, 21 Jan 2008 06:08:27 +0000 skrev Sohail Somani:

> On Mon, 21 Jan 2008 04:10:19 +0000,
> Maciej Katafiasz wrote:
>> Let’s not. Rails is a really shitty way of doing things.

> I don’t really care either way, but Rails has gotten
> Ruby usage. This might be because it is quite Mickey
> Mouse… But why is Rails a really shitty way of doing
> things?

First, I completely agree with what Slava said. Now to expand that a bit with my own thoughts:

Rails is 100% magic with 0% design. It sports all the great quality and consistency you’ve come to expect from PHP, except with loads more magic. There’s no overarching design or scheme of things, it’s just a bucket of tools with some glue poured in. This has a couple of important consequences:

– There’s no reasoning about Rails — more familiarity won’t give you better chances of figuring out something new because that’s what follows from the design, only because that’s how it usually ends up being implemented and because you have memorised more things, so your guesses are better. In essence, being better in Rails means being better at grepping the internet.

– There’s no thought given to the general problem to solve, it’s just improved PHP + “ActiveRecord, lol”. This means Rails doesn’t have solutions that are particularly good or scalable or make sense, only hacks that happened to solve someone’s specific problem at a time and were implementable in 5 minutes or less. Rails is heaps better than PHP, but it’s still only good for what PHP is good, and that’s not writing webapps. This permeates Rails all the way down: it’s got hacky modules that only solve particular problems, those modules have hacky functions that only solve particular problems and those functions only do hacky things that solved someone’s particular problem.

Some examples:
* AR’s find family of functions. It’s a horrible hack, for instance, they support the :group clause, which has semantics (“return a collection of groups of things”) incompatible with find’s base semantics (“return a collection of things”). Rails answer? It implicitly relies on MySQL’s retarded interpretation of SQL and the fact that given a table with two columns, id and colour, it will silently interpret “SELECT * FROM table GROUP BY colour” as “SELECT FIRST(id), colour FROM table GROUP BY colour”. End result? A valid combination of clauses in AR will generate incorrect SQL Postgres will (correctly) choke on.

* AR’s find again, it supports :join (which documentation hilariously describes as “rarely needed”), except that it doesn’t return real objects then, but make-believe fake readonly objects that will only have some attributes filled in (because they have no backing with physical rows), but will *still* have the base type and all the methods of the class you queried on! So if you go with that and try to call one of the methods that depend on unfilled attributes, you die horribly.

– Reading and, in general, understanding Rails is horribly difficult, since it’s no design and layers upon layers of magic. Very often you will find 5-7 layers of functions delegating the work deeper and deeper in, until you arrive to a completely undocumented internal function that in turn splits the work to three other, unrelated internal functions. Given that each of those 10 functions takes a hash called “options”, each layer altering it subtly, but none having the complete picture, and that 9 times out of 10 that hash is not documented on any level, figuring out what your choices are is pure hell. It’s made even more fun by the fact that different parts of Rails are accessible at various points of handling the request, and you can’t just jump in and poke things from the console, since it won’t have 99% of the things that only magically spring to life once a request is live.

– As a rule, there’s no quality assurance, and the average quality is very low. Because it’s such a patchwork, it will only have parts of things implemented, some other (not necessarily overlapping) parts documented, and a whole load of missing things just dangling and waiting for you to run into them. For example, the docs for text_field_with_auto_complete discuss how you can use options to make it complete only parts of entries (which was exactly what I needed, to show “foo (123)” in the popup, but only insert “foo” in the text field). What it doesn’t tell you, however, is that none of the stock completion-generating methods will prepare such splittable data for you, and you’re supposed to copy their code and hack it on your own instead. It took me half a day to finally understand that it wasn’t me being stupid and unable to find it, but it was actually Rails documenting interfaces that _weren’t there_.

– And to stress the first point again, Rails never concerns itself with the big-picture problem of “writing webapps”. It only thinks as big as “outputting HTML strings” and “querying the DB for a list of things”. This means the important, actually hard stuff like handling the stateless nature of HTTP, or sanitising and escaping the user input is just not adressed at all, and you only learn about them when one day you discover 84 possible XSS injection points (actual number from a Rails app I’m somewhat famililar with).

I’m a huge fan of innovative frameworks like Weblocks, because they actually stopped and thought about the whole thing for a moment, and try things that will address the problem as a whole. And even if some specific things will turn out to be harder to do that by just churning out raw HTML, and there will be abstraction leaks, it’s still better because they try out new things to find a solution that has a chance work. Rails doesn’t, because its entire culture seems to be fundamentally incapable of thinking more than 5 minutes into the future.

Cheers,
Maciej

This entry was posted on Tuesday, January 22nd, 2008 at 12:53 am and is filed under Ruby. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.