Why the Rails Conventions Are Great

06 Jul 2012

One of the best features of Rails is that is has an opinion. A strong one at that. Anyone coming from the world of Java and J2EE can tell you that having a lot of options isn't always the best thing. Sometimes, a simple convention might be a lot easier to follow than defining hundreds of XML files.

I Love Convention Over Configuration

For example, Rails' ORM, ActiveRecord makes it possible to add columns to the database without changing the model. Which makes it a lot easier to program with. Of course today J2EE has JPA annotations, which come close to that, but I think they still are trying too hard to fit into legacy databases.

Rails is made for the 99% of all use cases, and it doesn't hide that fact. Which isn't wrong, because, well, 99% is a lot after all.

Ease Of Use

One of the amazing things that all this convention gives us is that picking up a new app is really easy. If I look at a Rails app, and a form is wrong, I can simply look at it and change it, there is no need to search where the form is in the app. In J2EE everyone is OK with using something totally different in their stacks. No app looks like the next, so picking it up is really hard and requires a lot of time. J2EE does have "Enterprise" in its name for a reason. I have worked on a huge J2EE app with a huge team, and it was great! But the knowledge needed to write one such app is immense, the overhead big. It is just not made for small development teams.

Think About the Developers

The structure also helps the 501 developers (and, to be honest, all the rest of us), because a huge amount of knowledge backs all this convention about how web apps should be developed. Something one person alone, or a single group, can never match. You don't know where this piece of code should go? No problem, search for it on the web, someone will know (or at least have seen that problem before. Maybe even solved it in a better way that you are thinking about now). This makes everything so much easier. Today, speed is really king. And Rails is fast. Really fast. Getting a site up and running isn't a problem, because there is no need to first assemble the stack yourself. Solving dependency problems. Find out how these two libraries can work together. Everything just works! A demo app will be up in no time.

Your own stack (probably) sucks!

Making your own web development stack is a lot of work. Library X only works with version 2.3 - 3.1 of library Y? But you need 3.2 for library Z? What should you do? How do you keep all the libraries up to date? What about vulnerabilities? Your glue code between two libraries breaks, what now? How should this new guy know all the guidelines you never wrote down? Having your own stack gives you a lot of freedom, but it is also a lot of work. And a mess is already coming... If you have tried it, what are your experiences? I really think, after having done both, but having such well-defined standards and conventions as Rails has does make it a lot easier. Often I thought "This is easier if I do it this way" only to find out later why others didn't do it this the hard way. I'm still waiting for others to pick up what Rails did instead of just copying it. Using the language and tools surrounding it to the fullest advantage. Is there such a thing in beside Rails?