Why Rails Blueprint Uses Slim + Bootstrap: The Token Economics of AI-Assisted Development

October 25, 2025 • By Vladimir Elchinov

We measured 10 tech stacks to answer one question: which choices optimize for AI context windows? The data surprised us.

I've never been a fan of React.
Not for ideological reasons - it's a solid framework. But I always felt like I was writing more code to accomplish less. More ceremony, more boilerplate, more configuration.
When we built Rails Blueprint, we went with Slim templates and Bootstrap. It felt right. Concise, readable, productive.
But I wondered: was I just being stubborn? Maybe the "modern" stack really was better, and I was missing out?
So I decided to measure it.
I built the same CRUD feature in 10 different tech stacks - every combination of Rails/React, Slim/ERB, and Bootstrap/Tailwind/Styled Components. Then I counted every token.
The results validated what I'd felt intuitively: Rails Blueprint isn't just DRY. It's context-optimized.
Here's what the data shows.

The Experiment

What I Built

A task management feature with full CRUD operations, filtering by status and priority, form validation, and proper styling. Production-quality code, not a toy example.

The 10 Stacks Tested

  • Rails + Slim + Bootstrap
  • Rails + Slim + Tailwind 
  • Rails + ERB + Bootstrap
  • Rails + ERB + Tailwind
  • React + JavaScript + Bootstrap
  • React + JavaScript + Tailwind
  • React + JavaScript + Styled Components
  • React + TypeScript + Bootstrap
  • React + TypeScript + Tailwind
  • React + TypeScript + Styled Components

How I Measured

Lines of code, file size, and estimated tokens using standard tokenization (characters ÷ 4). I excluded tests, migrations, and config files - just the application code that would go into an AI's context window.

The Results

| Stack | Files | Lines | Tokens | vs Rails Blueprint |
|-------|-------|-------|--------|-------------------|
| Rails + Slim + Bootstrap | 7 | 338 | 3,026 | baseline ✅ |
| Rails + Slim + Tailwind | 7 | 306 | 3,603 | +19% |
| Rails + ERB + Bootstrap | 7 | 439 | 3,991 | +32% |
| Rails + ERB + Tailwind | 7 | 381 | 4,313 | +43% |
| React + JS + Bootstrap | 6 | 848 | 6,545 | +116% |
| React + JS + Tailwind | 6 | 799 | 6,705 | +122% |
| React + TS + Bootstrap | 7 | 897 | 7,103 | +135% |
| React + TS + Tailwind | 7 | 883 | 7,412 | +145% |
| React + JS + Styled Components | 6 | 1,321 | 7,986 | +164% |
| React + TS + Styled Components | 7 | 1,376 | 8,625 | +185% ❌ |

Key Findings


1. Rails vs React: A Consistent 2x Difference

The best React configuration (JavaScript + Bootstrap at 6,545 tokens) uses 2.16x more tokens than the best Rails configuration (Slim + Bootstrap at 3,026 tokens).
But here's what really stood out: even the worst Rails configuration beat the best React configuration.
  • Worst Rails (ERB + Tailwind): 4,313 tokens
  • Best React (JS + Bootstrap): 6,545 tokens
Rails wins by 1.5x even when you make suboptimal choices.

2. Every Layer Matters

Within Rails:
  • Slim → ERB: +20-32% more tokens
  • Bootstrap → Tailwind: +8-19% more tokens
  • Both together: +43% more tokens
Within React:
  • JavaScript → TypeScript: +8-11% more tokens
  • Bootstrap → Styled Components: +21-22% more tokens
  • All worst choices: +185% more tokens
Each choice compounds. Make the right choices at every layer, or pay the cumulative tax.

3. Styled Components Consistently Worst

Across both JavaScript and TypeScript, Styled Components added 21-22% more tokens compared to Bootstrap. CSS-in-JS means every styled element embeds 20-50 lines of styling directly in your component files.
When Claude reads your code, it has to parse all of that just to understand what your component does.

4. TypeScript's Cost is Modest

TypeScript only added 8-11% more tokens compared to JavaScript. That's actually less than I expected, and arguably worth it for the type safety.
The real token drains aren't type annotations - they're framework overhead and styling approaches.

Why This Matters

When you're working with Claude Code, Cursor, or any AI coding assistant, context is everything.
These tools have limited context windows - typically 100-200k tokens. Every token you spend on framework boilerplate, imports, state management, and embedded styles is a token you can't spend on:
  • Your business logic
  • Related files in the codebase 
  • Understanding the full context of your feature

In Practical Terms

With Rails Blueprint (3,026 tokens per feature), you can fit approximately 33 features in a 100k token context window.
With React + TypeScript + Styled Components (8,625 tokens per feature), you can fit approximately 12 features.
When you're refactoring, debugging, or building new features, having 3x more code visible to your AI assistant makes a meaningful difference.

Real-World Validation

This experiment confirmed what I'd already seen in production.
We built Blueprint MCP browser extensions twice:
  • Chrome version (React + TypeScript): 32,000 tokens of source code
  • Firefox version (Vanilla JavaScript): 15,700 tokens of source code
Same functionality. 2x difference in token count.
The pattern is consistent: explicit, verbose, framework-heavy code consumes more AI context.

What Creates The Difference?

Let's look at a concrete example. Here's a simple task card component:

Rails + Slim + Bootstrap (15 lines, ~120 tokens)

.card.mb-4
  .card-body
    h5.card-title = task.title
    p.card-text = task.description
    - if task.completed?
      span.badge.bg-success Completed
    - else
      span.badge.bg-warning In Progress
    .mt-3
      = link_to 'Edit', edit_task_path(task), class: 'btn btn-primary'
lang-slim

React + TypeScript + Styled Components (80+ lines, ~650 tokens)

import React from 'react';
import { useNavigate } from 'react-router-dom';
import styled from 'styled-components';

interface Task {
  id: string;
  title: string;
  description: string;
  completed: boolean;
}

interface TaskCardProps {
  task: Task;
}

const Card = styled.div`
  background: white;
  border-radius: 8px;
  padding: 24px;
  margin-bottom: 16px;
  box-shadow: 0 2px 4px rgba(0,0,0,0.1);
`;

const Title = styled.h5`
  font-size: 20px;
  margin-bottom: 8px;
`;

const Description = styled.p`
  color: #666;
  margin-bottom: 16px;
`;

const Badge = styled.span<{ variant: 'success' | 'warning' }>`
  display: inline-block;
  padding: 4px 12px;
  border-radius: 4px;
  font-size: 14px;
  background: ${props => props.variant === 'success' ? '#28a745' : '#ffc107'};
  color: white;
`;

const Button = styled.button`
  padding: 8px 16px;
  background: #007bff;
  color: white;
  border: none;
  border-radius: 4px;
  cursor: pointer;
`;

export const TaskCard: React.FC<TaskCardProps> = ({ task }) => {
  const navigate = useNavigate();
  
  return (
    <Card>
      <Title>{task.title}</Title>
      <Description>{task.description}</Description>
      <Badge variant={task.completed ? 'success' : 'warning'}>
        {task.completed ? 'Completed' : 'In Progress'}
      </Badge>
      <Button onClick={() => navigate(`/tasks/${task.id}/edit`)}>
        Edit
      </Button>
    </Card>
  );
};
lang-typescript
Same visual result. 5x more code.
The React version needs:
  • Import statements (4 lines)
  • Type definitions (10 lines)
  • Styled component definitions (40 lines)
  • Component boilerplate (10 lines)
Rails gets the same result with conventions, external CSS, and concise templates.

Optimizing Rails Blueprint

Based on this data, here's why Rails Blueprint makes the choices it does:

1. Slim over ERB

Saves 20-32% tokens. Slim's concise syntax means less visual noise and smaller files. When Claude reads a Slim template, it sees structure clearly without HTML ceremony.

2. Bootstrap over Tailwind

Saves 8-19% tokens in Rails. Semantic classes like btn btn-primary use fewer tokens than utility strings like px-4 py-2 bg-blue-600 text-white rounded hover:bg-blue-700.

3. MVC Architecture

Rails' separation of concerns means:
  • State lives in the database, not in client-side hooks
  • Styling lives in external CSS, not embedded in components
  • Logic lives in controllers and models, not scattered across components
Each file has a single responsibility, making it easier for AI to understand.

When React Still Makes Sense

This isn't about "Rails vs React" as a universal judgment. React excels at:
  • Highly interactive UIs (Figma, Google Docs, real-time editors)
  • Complex client-side state that can't live server-side
  • Applications that need to feel like native desktop apps
But for the majority of web applications - CRUD apps, dashboards, content platforms, SaaS tools - the React overhead doesn't provide proportional benefits, and the context cost is measurable.

Recommendations


If You're Starting a New Project

  • Consider Rails + Slim + Bootstrap for typical CRUD applications
  • The 2-3x context efficiency will compound over the life of your project

If You're Already in React

  • Prefer JavaScript over TypeScript if context budget is tight (though TS only costs 9%)
  • Use Bootstrap over Styled Components (saves 21%)
  • Avoid Tailwind's utility-class verbosity when possible

If You're Already in Rails

  • Switch from ERB to Slim (saves 20-32%)
  • Use Bootstrap over Tailwind (saves 8-19%)
Every percentage point matters when you're pushing context limits.

Try Rails Blueprint

Rails Blueprint embodies these optimizations:
  • Slim templates throughout
  • Bootstrap for semantic styling
  • Rails conventions over configuration
  • Command pattern for business logic
  • Ready to deploy in 15 minutes
It's not just opinionated. It's context-optimized for AI-assisted development.

Appendix: Methodology


Feature Specification

  • Task model with title, description, status, priority, due_date
  • Full CRUD: index, show, new, edit, destroy
  • Filtering by status and priority
  • Form validation and error handling
  • Styled with consistent design system

Measurement

  • Counted all application code files
  • Excluded: tests, migrations, config, package.json, node_modules
  • Token estimation: character count ÷ 4 (industry standard)
  • Measured using Claude Code generation

Code Available

All 10 implementations available on GitHub: https://github.com/railsblueprint/stack-comparison/

Discussion

Have you measured token efficiency in your projects? What patterns have you noticed?
Join the conversation on Twitter: https://x.com/railsblueprint
Or try Rails Blueprint and see the difference yourself: railsblueprint.com

Start creating your next app now