Why We’re Sticking with Ruby on Rails at GitLab

When David Heinemeier Hansson created Ruby on Rails (interview), he was guided by his experience with both PHP and Java. On the one hand, he didn’t like the way the verbosity and rigidness of Java made Java web frameworks complex and difficult to use, but he appreciated their structural integrity. On the other hand, he loved the initial approachability of PHP but was less fond of the quagmires that such projects tended to turn into.

It seems like these are exclusive choices: You either get approachable and messy, or well-structured and hard to use, pick your poison. We used to make a similar, and similarly hard, distinction between server-class operating systems such as Unix, which were stable but hard to use, and client operating systems such as Windows and MacOS that were approachable but crashed a lot.

Everyone accepted this dichotomy as God-given until NeXT put a beautiful, approachable and buttery-smooth GUI on top of a solid Unix base. Nowadays, “server-class” Unix runs not just beautiful GUI desktops, but also most phones and smartwatches.

So it turned out that approachability and crashes were not actually linked except by historical accident, and the same turns out to be true for approachability and messiness in web frameworks: They are independent axes.

And these independent axes opened up a very desirable open spot in the lower right-hand corner: an approachable, well-structured web framework.

With its solid, metaprogrammable Smalltalk heritage and good Unix integration, Ruby proved to be the perfect vehicle for Ruby creator DHH to fill that desirable bottom-right corner of the table with Rails: an extremely approachable, productive and well-structured web framework.