You've spent the last few lessons mastering the Ruby language itself, but now we're getting to the part most people actually care about: putting that code on the web. When you look at the Ruby ecosystem, you're going to see two names pop up constantly: Sinatra and Ruby on Rails. I like to think of Sinatra as a scalpel and Rails as a fully equipped surgical suite. Both get the job done, but the experience of using them is night and day.

To show you what I mean, let's build a very simple "Quick-Note" app. The goal is basic: a page that lists a few notes and a way to add a new one. I'll walk you through how I'd approach this in both frameworks so you can feel the difference in "weight."

The lean approach with Sinatra

If I just need a couple of endpoints and don't want to deal with a massive folder structure, I go with Sinatra. It's a Domain Specific Language (DSL) that stays out of your way. Here is how I'd start the Quick-Note app:

require 'sinatra'

notes = ["Buy milk", "Finish Ruby course", "Call mom"]

get '/' do
  erb :index, locals: { notes: notes }
end

post '/notes' do
  notes << params[:note]
  redirect '/'
end

In about ten lines of code, I've defined my data, my main page route, and the logic to handle a form submission. It's incredibly intuitive. You see a URL, you define a block of code, and that's it. No complex configuration, no magic hidden in five different directories.

Hitting a wall with Sinatra's minimalism

Here is where I usually trip up when I'm moving too fast. I ran the code above, but when I hit the page in my browser, I got a sinatra.erb: template not found error. I had written the Ruby logic, but I completely forgot that Sinatra expects a very specific folder structure for its views.

I had just put index.erb in the root folder. Sinatra doesn't look there; it looks for a folder specifically named views. I had to stop, create the directory, and move the file: mkdir views && mv index.erb views/. It's a small mistake, but it highlights the trade-off: Sinatra gives you freedom, but it doesn't hold your hand. You are responsible for the organization.

Scaling up with the Rails framework

Now, imagine this Quick-Note app needs a database, user accounts, password encryption, and an admin dashboard. If I stayed with Sinatra, I'd be spending my whole week manually installing gems and wiring them together. This is where Rails shines. Rails is built on "Convention over Configuration." It assumes there is a "right way" to do things, and if you follow its rules, it does the heavy lifting for you.

In Rails, I wouldn't just write a script; I'd generate a scaffold. One command—rails generate scaffold Note content:text—creates the database migration, the model, the controller, and the views. I don't have to worry about where the index.erb (or index.html.erb) goes because Rails has already decided that for me.

While the Sinatra version was one file, the Rails version is dozens of files. At first, that feels like overkill. But when you're working on a team, that structure is a godsend. Any Rails developer can jump into any Rails project and know exactly where the routes are defined and where the logic lives. In a large Sinatra app, every developer organizes things differently, which can lead to a total mess as the project grows.

Which one should you actually use?

I'll be honest: you'll use Rails more often in a professional setting because most companies are building complex, data-driven applications. However, don't sleep on Sinatra. It's perfect for building small APIs, internal tools, or "microservices" that only do one thing. If you can describe your app in one sentence (e.g., "It's a page that redirects links"), use Sinatra. If you describe it in a paragraph ("It's a marketplace where users can list items, message each other, and process payments"), use Rails.

📋 Practical Task

Build a Personal Quote Gallery with Sinatra

Your task is to create a minimal Sinatra application that displays a collection of your favorite quotes. You will need to practice the "lean" approach we discussed in the lesson.

• Create a directory for your project and a views folder inside it.
• Create a file named app.rb. In this file, define an array of strings containing at least three quotes.
• Create a GET / route that renders an index.erb template, passing the quotes array into the view.
• In index.erb, use a Ruby loop (like .each) to display each quote in an unordered list (<ul>).
• Create a POST /quotes route that allows you to append a new quote to the array via a form submission, then redirects the user back to the home page.

Goal: Successfully run the app and add a new quote through the browser without encountering a "template not found" error.