Ruby on Rails vs Express

If you are weighing Rails against Express, the choice can feel overwhelming. I faced the same dilemma on a project where I needed to decide whether to stick with Rails or switch to the Express.js stack. Rails promises productivity by handling complexity through conventions. Express offers freedom by giving you only a web server and leaving every architectural decision to you.

To make the comparison real, I built the same shopping cart, authentication, and payment flows in both frameworks. What I learned highlights exactly when Rails accelerates development and when Express gives you the control you need.

What is Ruby on Rails?

Ruby on Rails is a full-stack web framework that follows the "convention over configuration" principle. Created by David Heinemeier Hansson in 2003, Rails provides everything you need to build web applications: an ORM, routing system, templating engine, and deployment tools.

The framework makes decisions for you about project structure, database interactions, and common patterns. This opinionated approach lets you focus on building features rather than configuring tools.

Rails includes ActiveRecord for databases, ActionView for templates, ActionController for handling requests, and dozens of other components that work together seamlessly.

What is Express.js?

Express.js is a minimal web framework for Node.js that provides basic server functionality without making assumptions about how you build your application. Created by TJ Holowaychuk in 2010, Express gives you routing, middleware, and request handling - then lets you choose everything else.

The framework follows a "unopinionated" philosophy where you decide the database, templating system, authentication method, and project structure. This flexibility lets you build applications that match your exact requirements.

Express provides the foundation for handling HTTP requests and responses, but leaves architectural decisions up to you and your chosen libraries.

Rails vs Express: quick comparison

Setting up and getting started

That difference between "conventions" and "flexibility" became obvious within the first 10 minutes of creating new projects in both frameworks. Rails immediately showed me its opinionated approach, while Express left me staring at an empty folder wondering what to do next.

Rails provides a complete application generator that creates everything you need:

# Install Rails and create new application
gem install rails
rails new ecommerce_app --database=postgresql
cd ecommerce_app

# Generate a complete model, view, controller
rails generate scaffold Product name:string price:decimal description:text
rails db:migrate

# Start the development server
rails server

Rails created 50+ files organized in a standard MVC structure. The scaffold generator built complete CRUD functionality for products, including database migrations, controllers, views, and routes. Within minutes, I had a working web application with forms, validation, and database persistence.

Express starts with minimal setup and grows based on your decisions:

# Initialize Node.js project and install Express
npm init -y
npm install express

# Create basic server file
touch app.js

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World');
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Express gave me a basic server that responds to HTTP requests. To build the same product functionality as Rails, I needed to choose and configure a database library, templating system, body parser, and routing structure. Each decision required research and configuration.

Building the same feature in both frameworks

After Rails generated 50+ files automatically while Express gave me a basic "Hello World" server, I wanted to see how this setup difference played out when building actual features. So I implemented the same product management system in both frameworks.

Rails follows MVC conventions with integrated components:

# app/models/product.rb
class Product < ApplicationRecord
  validates :name, presence: true
  validates :price, presence: true, numericality: { greater_than: 0 }

  scope :available, -> { where(available: true) }
end

class ProductsController < ApplicationController
  def index
    @products = Product.available
  end

  def show
    @product = Product.find(params[:id])
  end

  def create
    @product = Product.new(product_params)
    if @product.save
      redirect_to @product, notice: 'Product created successfully'
    else
      render :new
    end
  end

  private

  def product_params
    params.require(:product).permit(:name, :price, :description)
  end
end

Rails.application.routes.draw do
  resources :products
end

Rails provided integrated solutions for data validation, database queries, request handling, and routing. The conventions meant I didn't need to decide how to structure controllers or name route paths - Rails made those decisions for me.

Express required choosing and configuring each piece separately:

const mongoose = require('mongoose');

const productSchema = new mongoose.Schema({
  name: { type: String, required: true },
  price: { type: Number, required: true, min: 0 },
  description: String,
  available: { type: Boolean, default: true }
});

module.exports = mongoose.model('Product', productSchema);

const express = require('express');
const Product = require('../models/Product');
const router = express.Router();

router.get('/', async (req, res) => {
  try {
    const products = await Product.find({ available: true });
    res.render('products/index', { products });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

router.post('/', async (req, res) => {
  try {
    const product = new Product(req.body);
    await product.save();
    res.redirect(`/products/${product._id}`);
  } catch (error) {
    res.render('products/new', { error: error.message });
  }
});

module.exports = router;

const express = require('express');
const mongoose = require('mongoose');
const productRoutes = require('./routes/products');

const app = express();
app.use(express.urlencoded({ extended: true }));
app.set('view engine', 'ejs');
app.use('/products', productRoutes);

Express gave me complete control over the implementation. I chose Mongoose for MongoDB, EJS for templates, and custom error handling. Each decision required understanding the trade-offs between different libraries and approaches.

Database integration and ORM

Seeing Rails handle everything with Product.new(product_params) while Express required me to choose between Mongoose, Sequelize, and a dozen other options made me realize the database layer would be where these philosophical differences really showed up.

Rails includes ActiveRecord, a full-featured ORM with conventions for everything:

# Database migrations are built-in
class CreateProducts < ActiveRecord::Migration[7.0]
  def change
    create_table :products do |t|
      t.string :name, null: false
      t.decimal :price, precision: 8, scale: 2
      t.text :description
      t.boolean :available, default: true
      t.timestamps
    end
  end
end

# Models provide rich query interfaces
class Product < ApplicationRecord
  has_many :order_items
  has_many :orders, through: :order_items

  scope :expensive, -> { where('price > ?', 100) }
  scope :recent, -> { where('created_at > ?', 1.week.ago) }
end

# Controllers use ActiveRecord naturally
def bestsellers
  @products = Product.joins(:order_items)
                     .group('products.id')
                     .order('COUNT(order_items.id) DESC')
                     .limit(10)
end

ActiveRecord handled database connections, migrations, relationships, and complex queries with minimal configuration. The conventions meant that associations and query methods worked predictably across the entire application.

Express required choosing between different database solutions and ORMs:

// Option 1: Mongoose with MongoDB
const mongoose = require('mongoose');

const productSchema = new mongoose.Schema({
  name: String,
  price: Number,
  orders: [{ type: mongoose.Schema.Types.ObjectId, ref: 'Order' }]
});

productSchema.statics.getBestsellers = function() {
  return this.aggregate([
    { $lookup: { from: 'orders', localField: 'orders', foreignField: '_id', as: 'orderData' } },
    { $project: { name: 1, price: 1, orderCount: { $size: '$orderData' } } },
    { $sort: { orderCount: -1 } },
    { $limit: 10 }
  ]);
};

// Option 2: Sequelize with PostgreSQL
const { Sequelize, DataTypes } = require('sequelize');
const sequelize = new Sequelize('database', 'username', 'password');

const Product = sequelize.define('Product', {
  name: { type: DataTypes.STRING, allowNull: false },
  price: { type: DataTypes.DECIMAL(8, 2), allowNull: false }
});

Product.getBestsellers = async function() {
  return await Product.findAll({
    include: [{ model: OrderItem, include: [Order] }],
    group: ['Product.id'],
    order: [[sequelize.fn('COUNT', sequelize.col('OrderItems.id')), 'DESC']],
    limit: 10
  });
};

Express gave me the choice between MongoDB with Mongoose, PostgreSQL with Sequelize, or dozens of other combinations. Each option had different syntax, capabilities, and trade-offs. The flexibility was powerful but required more decision-making and learning.

Development workflow and tooling

After spending an hour researching whether to use Mongoose or Sequelize while Rails' ActiveRecord just worked out of the box, I started wondering how this decision-making overhead would affect my daily development workflow.

Rails optimizes the development experience with integrated tools and conventions:

# Rails provides built-in development tools
rails generate model Order user:references total:decimal
rails generate controller Orders index show create
rails generate migration AddStatusToOrders status:string

# Built-in console for debugging and testing
rails console
> Product.expensive.recent.count
> User.find_by(email: 'test@example.com').orders

# Integrated testing framework
rails test
rails test:models
rails test:controllers

# Asset pipeline and deployment helpers
rails assets:precompile
rails db:setup

Rails included generators for common tasks, an interactive console for debugging, built-in testing tools, and deployment helpers. The development workflow felt consistent because every Rails application used the same patterns and tools.

Express development workflows vary based on chosen libraries and personal preferences:

# Development workflow depends on chosen tools
npm install --save-dev nodemon jest supertest
npm install mongoose express-session connect-mongo

# Custom npm scripts for development
npm run dev    # nodemon app.js
npm run test   # jest
npm run build  # webpack or custom build process

# Database management varies by choice
mongosh        # MongoDB shell
psql           # PostgreSQL shell
npm run migrate # Custom migration scripts

Express development required assembling your own toolchain. I chose nodemon for auto-restarting, Jest for testing, and custom scripts for database tasks. The flexibility allowed optimization for specific needs but required more initial setup and decision-making.

Handling authentication and authorization

The workflow difference became really clear when I needed to add user authentication. Rails had rails generate devise:install while Express left me staring at a blank authentication system wondering where to even start.

Rails provides built-in authentication helpers and established patterns:

# Gemfile - use established authentication gem
gem 'devise'

# Generate authentication
rails generate devise:install
rails generate devise User
rails db:migrate

# Controllers get authentication for free
class ProductsController < ApplicationController
  before_action :authenticate_user!
  before_action :authorize_admin!, only: [:create, :update, :destroy]

  private

  def authorize_admin!
    redirect_to root_path unless current_user.admin?
  end
end

# Views have authentication helpers
<% if user_signed_in? %>
  <p>Welcome, <%= current_user.email %>!</p>
  <%= link_to 'Sign out', destroy_user_session_path, method: :delete %>
<% else %>
  <%= link_to 'Sign in', new_user_session_path %>
<% end %>

Rails authentication felt almost magical. Devise provided complete user management with sign-up, sign-in, password reset, and session handling. The helpers integrated seamlessly with controllers and views using Rails conventions.

Express required choosing and implementing authentication from scratch or with libraries:

// Choose authentication strategy (Passport, custom, etc.)
const passport = require('passport');
const LocalStrategy = require('passport-local').Strategy;
const session = require('express-session');
const bcrypt = require('bcrypt');

// Configure authentication middleware
app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false
}));

passport.use(new LocalStrategy(
  { usernameField: 'email' },
  async (email, password, done) => {
    try {
      const user = await User.findOne({ email });
      if (!user || !await bcrypt.compare(password, user.password)) {
        return done(null, false, { message: 'Invalid credentials' });
      }
      return done(null, user);
    } catch (error) {
      return done(error);
    }
  }
));

// Authentication middleware
const requireAuth = (req, res, next) => {
  if (req.isAuthenticated()) {
    return next();
  }
  res.redirect('/login');
};

const requireAdmin = (req, res, next) => {
  if (req.user && req.user.role === 'admin') {
    return next();
  }
  res.status(403).send('Forbidden');
};

// Use in routes
app.get('/products/admin', requireAuth, requireAdmin, (req, res) => {
  // Admin-only product management
});

Express authentication required understanding sessions, password hashing, middleware, and security best practices. The flexibility allowed custom implementations but demanded more security knowledge and careful implementation.

Testing approaches

After watching Devise generate complete authentication in Rails while I spent a few hours implementing Passport.js authentication in Express, I was curious how this complexity difference would play out in testing both applications.

Rails includes testing as a core framework feature with established conventions:

require 'test_helper'

class ProductTest < ActiveSupport::TestCase
  test "should not save product without name" do
    product = Product.new(price: 10.99)
    assert_not product.save
    assert_includes product.errors.full_messages, "Name can't be blank"
  end

  test "should calculate total with tax" do
    product = Product.new(name: "Test", price: 100)
    assert_equal 108.25, product.total_with_tax(0.0825)
  end
end

require 'test_helper'

class ProductsControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get products_url
    assert_response :success
    assert_select 'h1', 'Products'
  end

  test "should create product when authenticated" do
    sign_in users(:admin)
    assert_difference('Product.count') do
      post products_url, params: { product: { name: 'New Product', price: 25.99 } }
    end
    assert_redirected_to product_url(Product.last)
  end
end

Rails testing felt integrated and conventional. The framework provided fixtures, helper methods, and assertions designed specifically for web applications. Testing database models, controllers, and views followed predictable patterns.

Express testing required choosing testing libraries and establishing your own patterns:

// Choose testing framework (Jest, Mocha, etc.)
const request = require('supertest');
const app = require('../app');
const Product = require('../models/Product');

describe('Product API', () => {
  beforeEach(async () => {
    await Product.deleteMany({});
  });

  test('POST /products creates a new product', async () => {
    const productData = {
      name: 'Test Product',
      price: 25.99,
      description: 'A test product'
    };

    const response = await request(app)
      .post('/products')
      .send(productData)
      .expect(201);

    expect(response.body.name).toBe(productData.name);

    const product = await Product.findById(response.body._id);
    expect(product).toBeTruthy();
  });

  test('GET /products returns available products', async () => {
    await Product.create([
      { name: 'Product 1', price: 10, available: true },
      { name: 'Product 2', price: 20, available: false }
    ]);

    const response = await request(app)
      .get('/products')
      .expect(200);

    expect(response.body).toHaveLength(1);
    expect(response.body[0].name).toBe('Product 1');
  });
});

Express testing offered complete flexibility but required more setup. I chose Jest for the test runner, Supertest for HTTP testing, and custom helper functions for database setup. The testing approach varied significantly between different Express applications.

Final thoughts

This article compared Rails and Express and showed how each serves a different purpose. Rails is the fastest path to building complete applications, while Express gives you unmatched control for custom performance and architecture.

The trade-off is that with Express you often end up rebuilding features that Rails already provides, which can slow you down if productivity is your main goal.

Got an article suggestion? Let us know

Next article

NVM vs Mise: Choosing the Right Node.js Version Manager

Compare NVM and Mise for Node.js version management. Learn key differences in performance, multi-language support, and auto-switching to choose the right tool.

→

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.