Ruby
Article
By Glenn Goodrich

Why Learning Rails Is Still a Great Choice in 2016

By Glenn Goodrich

Rails: Novice to Ninja

Rails has been around for over 12 years. That’s an eternity in any kind of technology. The list of any software-related items that have survived that long has to consist of just a few. Sitting here thinking about it, I can only come up with:

  • Linux
  • Vi/Vim (which I am using to write this post)

Ok, well, I seem to be terrible at lists. I am sure there’s more, but the point remains: Rails has been around for ages. It has hair on it.

Knowing, as we do, that software is changing at the speed of light, especially in the web space, how can something like Rails persevere? Is there any way that it’s still relevant as a web framework? I mean, with Concurrent-this and Functional-that always dominating the headlines, how is this framework based on an object-oriented language still worth learning?

That’s what I am going to postulate today. Rails is still, very much, worth learning.

Disclaimer: I have updated SitePoint’s book Rails: Novice to Ninja for Rails 5, so I have a vested interest in the viability of Rails…

Doctrine and Vision

Rails has a doctrine. No, really, it does. It’s right here. I don’t know about you, but anytime I see such and such Doctrine, I think of mindless lemmings being forced into slavery by some tyrannical megalomaniac. I’ve probably read one too many post-apocalyptic sci-fi thrillers, though. The Rails Doctrine, however is all good. Here are the tenets:

  • Optimize for programmer happiness
  • Convention over Configuration
  • The menu is omakase
  • No one paradigm
  • Exalt beautiful code
  • Provide sharp knives
  • Value integrated systems
  • Progress over stability
  • Push up a big tent

Now, I am not going to run through all of these, but I want you to read them. You know what they don’t really say? “Make a website.” The list has words like “happiness”, “beautiful”, “progress”, “value”. This is for a web framework. Think about this for a second.

These are noble and worthwhile tenets for just about any job where things are built. They set the tone for the direction of the framework and the community around it. While you may not agree with all of them, at least you know what they are. They’re written down for everyone to see.

Consider the thought that went into building this list. Any framework that puts that kind of thought into the principles that drive it has to be mature and intelligent. I love these principles and knowing they drive Rails makes me happy to use it.

Immediate Success

Ruby on Rails es gud, ja?

It is a long-standing, well-known truth that Rails allows developers to sprint out of the gates. If you want to stand something up quickly as a proof-of-concept, you’ll be hard pressed to find anything better than Rails for the job. As such, Rails has been the choice of startups for generations.

But, it’s not just for startups. When you’re trying to learn something new in tech, it often takes ages to see anything real come out of your learnings. You have to get past a certain point, likely beyond “newbie” status to use it. This kind of commitment can be hard to sustain when you’re switching careers or have other responsibilities. If you are new to web development, Rails gives you success early. Very early. You don’t have to learn a whole programming language, just enough to get going. In fact, so many people come to Ruby through Rails that Rails is often confused with the language itself.

Learn Rails because you’ll be able to see progress instantly. And that will keep you learning.

Learn the Way of the Web

Another aspect of Rails that is chanted, mantra-esque, by its creators and users is “Convention Over Configuration”. This means, essentially, that Rails has adopted conventions (ways of doing things) that presume certain configurations. For example, you don’t have to pick a database when starting with Rails. Rails will use SQLite by convention if you don’t configure another database. While this certainly contributes to my previous point of immediate success, it also shows you how the web works.

Wait, what do I mean by that? Well, I mean that most websites need to store data, so Rails has a convention for that. The vast majority of web applications out there use session-based authentication, so Rails has a convention for that. Once you learn the conventions, you now have a list of things web applications need. You have a list of the “ways of the web”. Here’re some more examples:

  • RESTful endpoints
  • Asset compression and building
  • Database migrations
  • Package and dependency management
  • Testing

There’s more, but you get the idea. You can take this list and tweak the configuration to see other approaches. You can outright remove or replace these conventions with gems or your own code. When you’re ready, you can dig deeper into each convention and learn why it exists. These deeper dives will end up teaching you something fundamental about web application development and deployment. What’s better, is you can use the conventions until you’re ready, learning at your pace while still producing a solid web app.

Stand on the Shoulders of Giants

Building on the last point, Rails was built by some of the giants of web development. Rails started life as the framework used to build Basecamp, which is a very successful, high traffic offering. This means that the problems that spring up when creating a data-driven, high-traffic site were solved for Basecamp, and we get to reap those benefits.

In 12 years, Rails has been used for many successful sites. Many of the people involved with these sites have churned out incredible open source gems to solve problems that plagued them on their journey. One of the best examples is Devise, the de facto gem for authentication in Rails. Using Devise (and other gems), you can allow your users to authenticate in many, many ways. Email/password, Twitter, Facebook, Github, JWT, and the list goes on. Devise is only one example of thousands.

Rails is built by giants and a community of giants has built up around it.

--ADVERTISEMENT--

You and What Army?

This community becomes your community when you start down the path with Rails. If you head over to Rubygems and search for “rails” you’ll see a result of roughly 160 pages of gems. 160 pages!! And more gems come out every week.

Also, searching for Rails help on the internet yields innumerable options. There are forums on SitePoint and elsewhere to ask questions. There’s a Slack group. You can’t swing a dead cat on the internet without hitting at least 12 Rails resources for answers. MEEYOOOOW!

Also, the number of books and videos and blogs about Rails is never ending. Did I mention that we’ve got a book coming out in just a few days on Rails 5….coughs.

The point is, there’s an army of folks working with Rails out there to help you. So, when someone says “Yeah? You and what army?”, you’ll have a great answer.

Ruby is Beautiful

In my opinion, one of the best reasons to learn Rails is because it is based on Ruby. In my multiple decades of programming, I have gone through many languages. Some that don’t even really exist anymore (Powerbuilder, anyone? How about magik? OK, QuickBasic then…) While some languages simply died, I abandoned others because of frustrations with the language.

With Ruby, it was love at first sight, and some 10 years later, I am still deeply in love. While all this love talk, no doubt, makes Ruby uncomfortable, I don’t care. Ruby is a beautiful language, and I will shout it from the server-tops.

In an article back in the early days of Ruby, Yukihiro Matsumoto (the creator of Ruby) wrote “…Ruby is designed to make programmers happy.” Don’t you want to use a language whose designer had that as an objective? I do. Oh, and he did a pretty good job reaching that goal.

It’s Still Got It

Well, at the end of this giant Rails love fest, you’re probably saying, “Well, that’s great, but can I make money with Rails?” Rather than give you my opinion, other that to say I write Ruby and Rails professionally almost every day, I’ll cite some real data:

You can find many articles and lists like those. Maybe the best way to answer this is to point you to an article written by Fabio Akita called “Rails Has Won: The Elephant in the Room”. This post isn’t the most complimentary article on Rails, but the title is true. Rails has kind of won. Beginners can learn it and experts can build great things with it. Rails is still making major changes to keep up with the ever-changing web development landscape.

While I mentioned I hope everyone wants to learn Rails and so they buy my book and I make loads of cash and retire to a life on non-stop Pokemanning, the book really doesn’t affect my view on Rails. I’ve been using Rails since 2006. In that time, other frameworks have made it into my toolbox and been discarded. Rails has stayed. It is truly the best tool I have for building most web applications. So, should you learn it? Seems like kind of a silly question now, doesn’t it?

How Can I Learn Ruby and Rails?

As mentioned earlier, I have recently released the third edition of my book Rails: Novice to Ninja. If you’re a SitePoint member you can find this on site now. Alternatively, you can also purchase an eBook or sleek paperback. For a sneak peak, check out this sample chapter.

Now go out there and learn Ruby. I’m sure you’ll love it as much as I do.

  • Fred@Bootstrap

    Spot on! The best thing about Rails is that it’s just Ruby. Oh, and it also makes you extremely productive. And while new hotnesses come and go (Elixir is the new one, now that node.js has been de-mythified – people realised that it’s just javascript on the server and who wants that- but I’m digressing) Rails for the last dozen years has been the most pleasant and productive way to develop web apps. With version 5 Rails caught up with the modern web app stack and will continue to be the best web app framework for some time yet. Long may it live!

    • ggsp

      Thanks Fred.

  • This article doesn’t talk about what are actual Rails features that will keep it alive. If I want to handle websockets or streaming, I don’t care if it’s done by “convention over configuration” or I have to configure it, I only care that I can actually do it.

    Also, this article makes it sound like Rails is the only web framework that the Ruby ecosystem has, giving the impression that if someone doesn’t think it’s worthwhile to learn Rails, then it’s not worthwhile to learn Ruby in general. That is very harmful for outsiders who are looking into learning Ruby, because it makes the ecosystem appear poor and framework-centric.

    You mention “RESTful endpoints”, “Asset compression and building”, “Database migrations”, “Package and dependency management” and “Testing”, but all of those things are literally available with any other web framework or ORM in Ruby. It’s important to make it clear whether you’re talking about Ruby in general or Rails as a specific web framework.

    • ggsp

      Hey Janko, thanks for the comment. I feel like I should mention that I never say Rails is the only thing worth learning, in Ruby or out. And I don’t really agree that all of those things I mention (and others) are available, by convention, in any other web framework. I do a fair amount of Express and Go work as well, and there are not conventions there that I am aware of. There are packages and approaches, but not built-in conventions.

      To be clear, I am talking about Rails here. I thinks it’s worth learning Sinatra, Express, Hanami, etc. I also think things like Trailblazer are wonderful for the ecosystem. But, this post is aimed at someone wondering if Rails is still a viable web framework, worth their time as they step in the pool. Sorry if that was unclear.

      • I agree that these conventions are not as strong in other Ruby web frameworks as in Rails, mostly because other frameworks encourage using generic libraries rather than shipping with “their own”.

        However, my point is that these conventions alone aren’t what can keep a web framework alive. This is because they are already there from the very beginning. If having these conventions is enough, that would mean if Rails development stopped now, Rails would still keep living. But it wouldn’t, right? Because the important part is also keeping up with development of web and other things, isn’t it?

        I’m not saying that Rails isn’t keeping up (I think that, but that’s not the point now), I’m just saying that we should talk more about advanced things that web frameworks can support to be better.

  • 12 years isn’t that long for good software (how could you forget about the GNU project, or Emacs?). I would expect a rather significant percentage of packages in Debian GNU/Linux are at least 12 years old. Possibly even the majority of them.

    If I wear my sysadmin hat, some of those items from the doctrine don’t sit well with me at all.

    “Convention over Configuration”? I’d prefer “Explicit is better than implicit”.

    “No one paradigm”? Sounds like Perl, and I’ve banged my head against the desk trying to understand some very inconsistent Perl before. Give me “There should be one– and preferably only one –obvious way to do it”. Because “Readability counts”.

    “Value integrated systems”? That flies in the face of *NIX convention, which has been successful for far far longer than Rails. I’ll take “Write programs that do one thing and do it well”.

    “Progress over stability”? They don’t have to be mutually exclusive. However if they are, I’ll take stability any day! New features can be added when it make sense to do so for most people, or added as experimental options for those keen on taking the risk. How about “Now is better than never. Although never is often better than *right* now”?

    Both Python and Unix have been successful for longer than Rails, and (unlike Ruby), Python hasn’t been kept alive by a single web framework. :)

    • It seems to me that much of your issue with these tenets are based on your experience. You are not a new programmer. The conventions help get going, and that is important to some. Also, comparing Unix to a web framework is a bit of a stretch. Many Unix utilities that “do one thing well” have 1.2 million ways to do that one thing. So, if you say Rails creates web apps well as it’s one thing, then the rest is just options.

      The issue with Stability over Progress in this context is if you choose Stability you’re choosing stagnation. The web is moving very fast. By the time you’re “stable”, you’re obsolete. I am sure your sysadmin hat does not fit well with that sentiment. There simply isn’t “one paradigm” for web development.

      This post was not “Learning Rails is a Better Idea Than Learning Python in 2016”, although it seems many Pythonistas get ruffled if anyone says anything positive about Ruby or Rails. I have used Python in my past, and I wasn’t a fan. But, I get why people are fans, I do not think less of them or it b/c of my preference for Ruby. Oh, and if readability counts, you simple cannot do better than Ruby.

      Rails isn’t for everyone. It doesn’t have to be. Thanks for the comment.

      • Sorry for a late response – I missed seeing a reply notification.

        Rails primarily runs on *nix systems, in my experience. Please note that the Unix philosophy does not only address core *nix OS components, but programs that run on it as well – and it continues to hold up well today. See all the backlash over systemd as an example.

        I’m struggling to think of what you mean by “1.2 million ways to do one thing”. Tools that support regular expressions maybe? Even then, different ways to do something mostly relate to having different standards that may need to be supported. eg. Perl compatibility, POSIX extended.

        I don’t buy into the idea that stable = stagnation. That statement is worthy of an entire article, but for now let’s just agree to disagree.

        As a sysadmin, stability is a primary consideration when selecting software. I’ve never had software that became “obsolete”. The closest I can think of is a project that the maintainer decided to abandon, which I simply forked and maintained myself. In this case, the project had been around for a while and did something which alternatives did not. I see no problem with this.

        > Oh, and if readability counts, you simple cannot do better than Ruby.

        I couldn’t disagree more. When you have so many ways to write exactly the same thing, there’s a good chance that you’ll have to learn multiple ways to read projects by different authors.

        Likewise, if you’re a contributor to multiple projects, each may have their own wildly different coding styles which require you to adjust. By contrast, a language which removes a lot of the “personal writing preference” flexibility helps ensure some level of consistency across independent projects.

        I do agree with your last line however, and appreciated reading your thoughts. Thanks Glenn.

        • Yup, we can agree to disagree on a few points. Still, I really liked reading your POV and I can see some of your perspective. Thanks for the dialogue.

Recommended
Sponsors
Get the latest in Ruby, once a week, for free.