Rails lets us focus on the hard stuff

I went to tour a local chocolate factory, and things did not go as planned. The place was hopping, all of the walk-in spots on the tour were taken, and they didn’t take reservations in advance. My disappointment was lifted by free samples and a nearby brewery, but I remember someone at the factory saying, “There has to be a better way.”

Inspired to create something that would help them, I e-mailed the factory. Two weeks later, I had built a reservations platform in Rails 5, and they were using it.

Rails lets developers focus on the hard stuff. Few other frameworks would let me completely focus on business needs and get something out so quickly.

What’s the hard stuff?

Here’s what shouldn’t be hard when first building an application:

  • Accounting for low-bandwidth connections
  • Supporting a wide array of browsers
  • Implementing a test framework and writing tests
  • Choosing and configuring build tools
  • Setting up a database
  • Setting up hosting
  • Adding basic security (CSRF protection, user authentication)
  • Making big decisions about JavaScript – choosing an MVC, for instance

Here’s what should be hard:

  • Creating a great user experience
  • Making sure the features make sense for the intended customers
  • Defining a data model that makes sense
  • Writing maintainable code

Working on an app on nights and weekends taught me the value of focusing on what should be hard and letting Rails handle the rest.

CSRF protection? Stick to Rails conventions. Testing? Use RSpec, a de-facto Rails community default. User auth? Add a gem like Devise. Build tools? Use built-in Sprockets. Hosting? It’s a breeze with Heroku and Rails 5. Accounting for low-bandwidth connections? Try Turbolinks (more on this below).

Staying focused on business needs, and letting Rails handle the rest, was the only way to ship.

Rails’ nice surprises

I was overseas recently and the internet sucked. Many web sites didn’t load at all. Some would show a layout but no text; others would show a nav bar and nothing else.

My reservation platform loaded quickly. Navigating the app was zippy.

How was this possible? Believe it or not, the improved Turbolinks. Avoiding full-page reload more than halves load time on bad connections. It took no effort on my part; it’s a Rails default.

A time and a place

A couple of years ago, I implemented React at Cook Smarts, a meal planning app. It transformed our JavaScript from spaghetti to well-structured, understandable code with fewer bugs.

Nonetheless, most of Cook Smarts remained vanilla Rails, views and all. We used React surgically, only when a very high level of interactivity was necessary.

Why stick with vanilla Rails? To keep the focus on what should be hard, building new features, rather than restructuring our app to JavaScript MVC with questionable benefits for users.

Frameworks like Rails get this. Next time you build an app, consider a framework that keeps your focus on what should be hard.

Hired.com brings Rails job offers to you. Free for candidates. Salaries from $75,000 to $250,000. Sign up now!

3 thoughts on “Rails lets us focus on the hard stuff”

  1. What are you comparing Rails with? Web frameworks from other languages, or other web frameworks in Ruby?

    I would like to revisit your list:

    * Accounting for low-bandwidth connections
    – If you use a JavaScript framework like React, it will even have better performance than Turbolinks, because you can push the whole frontend to a CDN.

    * Supporting a wide array of browsers
    – What does Rails do here? That’s completely dependent on how you write your frontend code, which Rails doesn’t affect.

    * Implementing a test framework and writing tests
    – Test frameworks are generic and can be used for any Ruby project. You can test sending requests for any Rack application with rack-test, rack-test_app or rack_toolkit gems

    * Choosing and configuring build tools
    – With Roda and Hanami you also have automatic compilation. But in any case it’s much better to use Node.js tools like Webpack.

    * Setting up a database
    – Creating and setting up a database is actually really easy without a config/database.yml.

    * Setting up hosting
    – Heroku knows how to deploy any Rack application

    * Adding basic security (CSRF protection, user authentication)
    – We have rack_csrf gem for adding CSRF protection to any Rack application. For user authentication you have rodauth gem, also works with any Rack application

    * Making big decisions about JavaScript – choosing an MVC, for instance
    – With any web framework you can choose whether you want to write vanilla JavaScript or use a JavaScript framework

    1. Wow, thanks so much for taking the time to write this comment. Looking through the tools you’ve outlined has been really helpful.

      My point was that Rails allows a new app to skip most of the decisions outlined here and get right down to solving business problems.

      I never claimed that Rails makes things possible that you couldn’t do yourself. Rails does, however, make a set of decisions for you, and I’ve found those decisions to be the right ones for most projects.

      I could set up my own build tools and test frameworks if my project required it. But Rails already decided on Bundler, and installing RSpec is a breeze with built-in Rails hooks.

      The development time associated with Turbolinks is trivial compared to setting up a fully JS front-end. In both cases, the server is involved (with Turbolinks, through PJAX, and with a fully JS front-end, through an API). Without having formally tested this, I’d guess the speed advantages aren’t so different. The difference for me is developer time; I prefer to focus JS time on features that need to be particularly interactive, and to lean on Turbolinks to speed up the rest of the app.

      Rails has a number of front-end components. Turbolinks, ActionCable, and jQuery UJS all fall back for older browsers. As a developer, that means whatever breaks older browsers would be something I’d need to add myself.

      With a Rails 5 app on Heroku, you don’t even need a Procfile, as outlined in the Heroku blog post linked from the article. I value little optimizations like that; they add up.

      I also value not having to install a CSRF gem separately. For me, basic security built into a framework reduces risk.

      Using a full-stack framework like Rails or not depends on personal preference and the needs of an app. For most apps, particularly new ones, though, I’d start there so I could focus more on the business side of the app vs. technical setup.

      1. I agree that choosing a non-Rails web framework means that you have to make more decisions. But I don’t agree that having to make these decisions takes a lot of time, and steers you away from focusing on the business part.

        I guess I’m ok with these decisions because for me the one that Rails makes had been wrong. For example, I mind that it chose ActiveRecord as the default ORM, when Sequel is objectively more advanced and saves me more time.

        I also don’t think that Sprockets should be the default anymore, because Webpack is much more advanced and has an incomparably faster build time (it affects the productivity a lot when your page refreshes are fast).

        Sure, when you’re building something simple in 2 weeks, I agree with Rails you’ll likely be more productive than in other web frameworks. But that’s a different use case than what I’m interested in 🙂

        Anyway, I suppose it’s just a matter of taste. Most of the Rails defaults just don’t suit me anymore, but for you they are suitable and that makes you more productive.

Leave a Reply