Advantages of the Rails Framework

Rails is big on the DRY principle. DRY stands for don’t repeat yourself, a principle that states information in a system should be expressed in only one place.

For example, consider database configuration parameters. When you connect to a database, you generally need credentials, such as a username, password, and the name of the database you want to work with. It might seem acceptable to include this connection information with each database query, and would surely hold up fine if you were making only one or two connections. But as soon as you need to make more than a few connections, you would end up with a lot of instances of that username and password littered throughout your code. Then if your username and password for the database changed, you would have a lot of finding and replacing to do. It would be a much better idea to keep the connection information in a single file, referencing it as necessary. That way, if the credentials should change, you need to modify only a single file. That’s what the DRY principle is all about.

The more duplication there is in a system, the more room there is for bugs to hide. The more places that the same information resides, the more that has to be modified when a change is required, and the harder it becomes to track these changes.

Rails is organized in such a way as to remain as DRY as possible. You generally specify information in a single place, and move on to better things.

Rails Is Opinionated Software

Frameworks encode opinions. It should come as no surprise then that Rails has strong opinions about how your application should be constructed. When you’re working on a Rails application, those opinions are imposed on you, whether you’re aware of it or not. One of the ways that Rails makes its voice heard is by gently (sometimes, forcefully) nudging you in the right direction. We’ve already mentioned this form of encouragement when we talked about convention over configuration. You’re invited to do the right thing by virtue of the fact that doing the wrong thing is often more difficult.

Ruby is known for making certain programmatic constructs look more natural by way of what’s called syntactic sugar. Syntactic sugar means that the syntax for something is altered in such a way as to make it appear more natural, even though it behaves the same way. Things that are syntactically correct but otherwise look awkward when typed are often treated to syntactic sugar.

Rails has popularized the term syntactic vinegar. Syntactic vinegar is the exact opposite of syntactic sugar: awkward programmatic constructs are discouraged by making their syntax look sour. When you write a snippet of code that looks bad, chances are it is bad. Rails is good at making the right thing obvious by virtue of its beauty, and the wrong thing equally obvious by virtue of ugliness.

You can see Rails’s opinion in the things it does automatically, the ways it encourages you to do the right thing, and the conventions it asks you to accept. You’ll find that Rails has an opinion on nearly everything about web application construction: how you should name your database tables, how you should name your fields, which database and server software to use, how to scale your application, what you’re going to need, and what is a vestige of web development’s past. If you subscribe to its world view, you’ll probably get along with Rails quite well.

Like a programming language, a framework needs to be something you’re comfortable with—something that reflects your personal style and mode of working. It’s often said in the Rails community that if you’re getting pushback from Rails, it’s probably because you haven’t experienced enough pain from doing web development the old-school way. This isn’t meant to deter developers, rather it’s meant to say that in order to truly appreciate Rails, you might need a history lesson in the technologies from whose ashes Rails has risen; sometimes until you’ve experienced the hurt, you can’t appreciate the cure.