Lightweight cruiser or full-fledged beast? You decide.

In a recent interview, I was asked a question about when I would chose to use a lightweight framework like Sinatra over a larger framework like Rails. This got me thinking since I really haven’t touched Sinatra in over a year when it was the first web framework I learned at Turing School. I’ve grown tremendously in my career and as a developer since then, but I didn’t truly appreciate it at the time. I think now I can offer some perspective that may be helpful to developers even younger in their careers than me.

To start, before diving into Sinatra, I’ll start with a simple explanation about what Ruby on Rails is, Rails for short, since you’ve probably heard of it.

Rails is an MVC (Model-View-Controller) web framework written in Ruby in 2004 by David Heinemeier Hansson (DHH). It was created to essentially drive developer happiness just like Ruby and make it very easy to create and manage large scale web apps. One thing to note about Rails though, is the magic. There is lots of what seems like magic under the hood and it has a very steep learning curve to understand all that is happening automatically for you.

Moving on, if you’re not familiar with Sinatra, it’s a web framework also built with Ruby, but without all the magic. What’s beautiful about Sinatra is its simplicity. It’s as small or as large as you need it to be and you can easily add routes or additional gems/functionality as needed. You can create a simple web app in just 5 lines, as you see I did below, and it’s very easy to understand what’s going on.

After installing the Sinatra gem, I created a Ruby file called ‘hello.rb’, required the gem, created a get route at the root or ‘/’ that displays ‘Hello World!’ After that, from your command line you just run, ‘ruby hello.rb’ or whatever you named it and a server is started at http://localhost:4567.

That’s it.

If you visit the browser at that address, you’ll see the text ‘Hello World!’ This app we created may not do much but it is a web app nonetheless. This example shows exactly why you might choose Sinatra over Rails. If I’m making a simple app with limited functionality, routes and users, I may just want to use Sinatra. As an example, I’ll use one that I created in the past called Burrito Finder. If all this app was doing was say making a single API call then outputting that data, it might be a bit overkill to make a Rails app. I did actually create the app with Rails, but now as I look back, it’s not too complicated and probably could have been built in Sinatra, Rails does make it easy though to have it fully tested with an integrated test suite and it comes with a database and Active Record out of the box. My Burrito Finder app is backed by a PostgreSQL database that stores user data, deals with authentication with Facebook OAuth, and has some JavaScripts and even a map with Mapbox on the front-end, but still not a ton of functionality that couldn’t have been done in Sinatra.

Apps can only get larger and more complicated from here. At my previous job, I worked on a platform for MVNOs, which are smaller wireless carriers that piggyback off large carriers like Sprint, purchasing data and voice airtime from them. Our app helped manage their businesses from activating and deactivating cellular devices on their network to managing customers, billing and data usage. It was probably the largest Rails app I’ve ever worked in since it’s been in development for a few years, is backed by thousands of tests and has an extremely complex database. If this app was built in a framework like Sinatra, it would just be a mess and extremely hard to manage.

When you start getting into an app like I was just describing, a framework like Sinatra would not only be more complicated for an app of that size, but also cause some issues with performance.

I wouldn’t limit this line of thinking to just the Ruby ecosystem, as there are plenty of other frameworks both on the front-end and backend where you can make similar arguments. Recently I’ve been learning a bit about another backend framework called Flask, which is similar to Sinatra but built with Python. The same arguments would hold true and you typically see people developing large web apps in Python being built with Django.

As far as lightweight vs. heavyweight frameworks on the front-end, two that I’ve been learning about lately have been React and Ember. While both require knowledge of JavaScript, a React app can get up and running in much less code and knowledge than an Ember app. Okay, React is actually a library and not a full-fledged framework, so you’ll have to build your own foundation and some glue code to get it all wired up, but it has the same philosophy as Sinatra. It can be as little or as much as you need it to be, using add ons like using Flux architecture or the numerous components and add-ons already created by the community. React now even has a way to quickly get started without any configuration.

With Ember, you have an MVC experience closer to Rails, where there is a command line interface with generators, a built-in dev server and a test suite. There’s lots of magic, but again it has a steep learning curve. Once you understand it though, it’s a great tool for creating and managing complicated UIs and has an add-on system with tons of support from the Ember community.

As developers, our job is to create amazing experiences and apps with whatever the best tool for the job is. You may initially only learn Rails or how to make simple apps made up of an HTML page, a stylesheet and some simple JavaScripts with jQuery, but as you grow, you’ll understand that there are more ways than one to do something and the way you know isn’t always the best way.

Sometimes something like a bicycle will get the job done when others you need a Ducati.