ERB vs Slim: Which Rails Template Language Should You Use?

When building Rails views, the template language shapes how you write and think about markup. ERB feels like regular HTML with bits of Ruby dropped in using <% %> tags. Slim, on the other hand, cuts out the clutter by removing angle brackets and closing tags and using indentation with shorthand syntax instead. This choice comes down to how you like to work: do you prefer copy-pasting HTML directly, or typing as little as possible?

ERB (Embedded Ruby) has been Rails’ default since 2004. It wraps Ruby in standard HTML, so anyone familiar with HTML can jump right in. Slim, released in 2010, takes a minimalist approach with no closing tags, no brackets, and structure defined by whitespace. The result is faster typing but a steeper learning curve.

Modern Rails teams usually decide based on who’s writing templates. ERB keeps everything familiar for designers and front-end devs. Slim favors developers who live in Ruby and want cleaner, shorter templates. Your choice affects collaboration, tooling, and how easily you move between design prototypes and working code.

What is ERB?

ERB processes templates by running Ruby inside <% %> tags while leaving everything else as plain HTML. You use <%= %> to output results or <% %> for logic that doesn’t print anything. It looks exactly like an HTML file with a few Ruby expressions sprinkled in.

Rails includes ERB out of the box. You don’t need to install anything — just create .html.erb files and start mixing Ruby with HTML. Because ERB doesn’t change the markup, designers and developers can both work on the same file without confusion.

Example:

<div class="user-dashboard">
  <h1>Welcome, <%= @user.name %>!</h1>

  <% if @user.notifications.any? %>
    <ul>
      <% @user.notifications.each do |notification| %>
        <li class="<%= notification.read? ? 'read' : 'unread' %>">
          <%= notification.message %>
        </li>
      <% end %>
    </ul>
  <% end %>
</div>

You can see both the structure and logic clearly — it’s just HTML with Ruby where you need it.

What is Slim?

Slim replaces standard HTML syntax with indentation and shorthand. You write fewer characters, skipping angle brackets and closing tags, while indentation defines the structure.

You’ll need to install the slim-rails gem, but once it’s set up, Rails treats .html.slim files like any other template.

Example:

.user-dashboard
  h1 Welcome, #{@user.name}!

  - if @user.notifications.any?
    ul
      - @user.notifications.each do |notification|
        li class=(notification.read? ? 'read' : 'unread')
          = notification.message

Each line represents an element, and indentation shows nesting. The syntax looks clean once you get used to it, but it’s different enough from HTML that designers or beginners might find it harder to follow.

ERB vs Slim: quick comparison

HTML familiarity

The syntax difference became immediately apparent when I rebuilt a landing page. ERB preserved the original HTML structure exactly:

<!-- ERB - standard HTML structure -->
<section class="hero">
  <div class="container">
    <div class="hero-content">
      <h1 class="hero-title">
        <%= @page_title %>
      </h1>
      <p class="hero-subtitle">
        <%= @page_subtitle %>
      </p>

      <% if @show_cta %>
        <div class="cta-buttons">
          <a href="<%= signup_path %>" class="btn btn-primary">
            Get Started
          </a>
          <a href="<%= learn_more_path %>" class="btn btn-secondary">
            Learn More
          </a>
        </div>
      <% end %>
    </div>

    <div class="hero-image">
      <img src="<%= asset_path(@hero_image) %>" alt="<%= @hero_image_alt %>">
    </div>
  </div>
</section>

I copied the HTML directly from our designer's prototype. The structure matched exactly—same tags, same nesting, same attributes. I added <%= %> tags where dynamic content was needed. The designer could open the file and immediately understand the layout. When we needed changes, they modified the HTML directly and I added Ruby where necessary.

Slim required complete conversion from HTML:

/ Slim - converted structure
section.hero
  .container
    .hero-content
      h1.hero-title
        = @page_title
      p.hero-subtitle
        = @page_subtitle

      - if @show_cta
        .cta-buttons
          a.btn.btn-primary href=signup_path
            | Get Started
          a.btn.btn-secondary href=learn_more_path
            | Learn More

    .hero-image
      img src=asset_path(@hero_image) alt=@hero_image_alt

The HTML from our designer needed manual conversion. I removed all angle brackets, stripped closing tags, converted attributes to Slim syntax, and added pipe markers for text. The designer couldn't read Slim files—they looked nothing like the HTML prototypes. When design changes came, I manually translated them to Slim syntax. The conversion added friction to our design-to-implementation workflow.

Handling dynamic attributes

That landing page highlighted attribute syntax differences. ERB uses standard HTML attribute patterns:

<!-- ERB - HTML attributes -->
<div class="card <%= @featured ? 'featured' : '' %> <%= @urgent ? 'urgent' : '' %>">
  <input
    type="text"
    name="user[email]"
    value="<%= @user.email %>"
    placeholder="Enter your email"
    <%= 'required' if @user.new_record? %>
    <%= 'disabled' if @user.locked? %>
    data-controller="email-validator"
    data-email-validator-url-value="<%= validation_path %>"
  />
</div>

Dynamic classes concatenated as strings. Conditional attributes needed ternary operators or conditional rendering. Data attributes followed HTML5 conventions with data- prefixes. The syntax was verbose but familiar—anyone who knew HTML could understand it. Complex attribute logic became messy, pushing me toward helper methods.

Slim provides more flexible attribute syntax:

/ Slim - flexible attributes
.card class=[(@featured ? 'featured' : nil), (@urgent ? 'urgent' : nil)]
  input type="text" name="user[email]" value=@user.email placeholder="Enter your email" required=@user.new_record? disabled=@user.locked? data-controller="email-validator" data-email-validator-url-value=validation_path

/ Or with parentheses for readability
.card class=[(@featured ? 'featured' : nil), (@urgent ? 'urgent' : nil)]
  input(
    type="text"
    name="user[email]"
    value=@user.email
    placeholder="Enter your email"
    required=@user.new_record?
    disabled=@user.locked?
    data-controller="email-validator"
    data-email-validator-url-value=validation_path
  )

Class arrays automatically filtered nil values. Boolean attributes took Ruby booleans directly. The = after attribute names evaluated Ruby expressions. Space-separated attributes looked cleaner but required learning Slim's conventions. The flexibility reduced verbosity but created a learning curve.

Text content patterns

The attribute handling connected to text content approaches. ERB treats text as first-class HTML content:

<!-- ERB - natural text handling -->
<h1>Welcome to Our Platform</h1>

<p>
  We provide comprehensive solutions
  for modern businesses looking to
  scale their operations efficiently.
</p>

<div class="message">
  Thank you for signing up,
  <%= @user.name %>!
  Your account is now active.
</div>

<pre class="code-block">
<%= @formatted_code %>
</pre>

Text appeared naturally within HTML tags. Multi-line text worked without special markers. Mixing static text with Ruby interpolation felt natural—just drop in <%= %> tags where needed. The text handling matched how HTML works natively.

Slim requires explicit text markers for multi-line content:

/ Slim - text with markers
h1 Welcome to Our Platform

p
  | We provide comprehensive solutions
    for modern businesses looking to
    scale their operations efficiently.

.message
  | Thank you for signing up,
  = @user.name
  | !
  | Your account is now active.

pre.code-block
  = @formatted_code

Single-line text after elements worked directly. Multi-line text required pipe | markers on each line. Mixing text and Ruby needed careful marker placement. Without pipes, Slim interpreted lines as elements. The explicit markers controlled text precisely but added characters and syntax rules to remember.

Partial rendering

Text handling influenced partial design. ERB renders partials using standard Rails helpers:

<!-- ERB - rendering partials -->
<div class="products-section">
  <h2>Featured Products</h2>

  <%= render partial: 'products/card',
             collection: @featured_products,
             locals: { show_price: true, show_actions: true } %>
</div>

<!-- _card.html.erb partial -->
<article class="product-card">
  <img src="<%= product.image_url %>" alt="<%= product.name %>">

  <div class="product-info">
    <h3><%= product.name %></h3>
    <p><%= product.description %></p>

    <% if show_price %>
      <p class="price"><%= number_to_currency(product.price) %></p>
    <% end %>

    <% if show_actions %>
      <div class="actions">
        <%= link_to 'View', product_path(product), class: 'btn' %>
        <%= link_to 'Add to Cart', add_to_cart_path(product), class: 'btn btn-primary' %>
      </div>
    <% end %>
  </div>
</article>

The partial call looked like standard Ruby. The partial file contained standard HTML with ERB tags. Local variables passed through the locals hash. The consistency between view and partial syntax made code organization straightforward.

Slim renders partials identically but with different internal syntax:

/ Slim - rendering partials
.products-section
  h2 Featured Products

  = render partial: 'products/card', collection: @featured_products, locals: { show_price: true, show_actions: true }

/ _card.html.slim partial
article.product-card
  img src=product.image_url alt=product.name

  .product-info
    h3 = product.name
    p = product.description

    - if show_price
      p.price = number_to_currency(product.price)

    - if show_actions
      .actions
        = link_to 'View', product_path(product), class: 'btn'
        = link_to 'Add to Cart', add_to_cart_path(product), class: 'btn btn-primary'

The partial call matched ERB—Rails' rendering API works independently of template language. Inside the partial, Slim's terse syntax reduced line count. I mixed ERB and Slim partials freely when migrating—Rails detected file extensions automatically. The interoperability enabled gradual conversion.

Form building

Partial rendering extended to form helpers. ERB uses standard HTML-like form syntax:

<!-- ERB - form helpers -->
<%= form_with model: @product, local: true do |f| %>
  <div class="form-group">
    <%= f.label :name %>
    <%= f.text_field :name, class: 'form-control', placeholder: 'Product name' %>

    <% if @product.errors[:name].any? %>
      <span class="error"><%= @product.errors[:name].first %></span>
    <% end %>
  </div>

  <div class="form-group">
    <%= f.label :category %>
    <%= f.select :category_id,
                 options_for_select(@categories.map { |c| [c.name, c.id] }, @product.category_id),
                 { include_blank: 'Select a category' },
                 { class: 'form-control' } %>
  </div>

  <div class="form-group">
    <%= f.label :description %>
    <%= f.text_area :description, rows: 5, class: 'form-control' %>
  </div>

  <div class="form-actions">
    <%= f.submit 'Save Product', class: 'btn btn-primary' %>
    <%= link_to 'Cancel', products_path, class: 'btn btn-secondary' %>
  </div>
<% end %>

The form looked like HTML with Ruby helper calls. The <div> tags provided structure. Form field helpers generated standard HTML inputs. Error handling used familiar conditional rendering. The structure matched how HTML forms work.

Slim renders forms with less markup:

/ Slim - form helpers
= form_with model: @product, local: true do |f|
  .form-group
    = f.label :name
    = f.text_field :name, class: 'form-control', placeholder: 'Product name'

    - if @product.errors[:name].any?
      span.error = @product.errors[:name].first

  .form-group
    = f.label :category
    = f.select :category_id, options_for_select(@categories.map { |c| [c.name, c.id] }, @product.category_id), { include_blank: 'Select a category' }, { class: 'form-control' }

  .form-group
    = f.label :description
    = f.text_area :description, rows: 5, class: 'form-control'

  .form-actions
    = f.submit 'Save Product', class: 'btn btn-primary'
    = link_to 'Cancel', products_path, class: 'btn btn-secondary'

Form helper calls worked identically—the API doesn't change. The .form-group replaced <div class="form-group">. Field helpers used the same arguments. Error handling used Slim's conditional syntax. The logic stayed identical while syntax changed.

Conditional rendering

Form error handling highlighted conditional patterns. ERB uses Ruby's control structures within HTML:

<!-- ERB - conditionals -->
<% if @user.premium? %>
  <div class="premium-features">
    <h3>Premium Benefits</h3>
    <ul>
      <li>Unlimited projects</li>
      <li>Priority support</li>
      <li>Advanced analytics</li>
    </ul>
  </div>
<% elsif @user.trial? %>
  <div class="trial-banner">
    <p>You have <%= @user.trial_days_remaining %> days left in your trial.</p>
    <%= link_to 'Upgrade Now', upgrade_path, class: 'btn btn-primary' %>
  </div>
<% else %>
  <div class="free-tier">
    <p>Upgrade to unlock more features</p>
    <%= link_to 'View Plans', plans_path, class: 'btn' %>
  </div>
<% end %>

<!-- Inline ternary for simple cases -->
<span class="badge <%= @active ? 'badge-success' : 'badge-default' %>">
  <%= @active ? 'Active' : 'Inactive' %>
</span>

The <% if %>, <% elsif %>, <% else %>, and <% end %> marked conditional blocks. HTML stayed between the Ruby tags. Ternary operators worked inline for simple conditional values. The structure matched standard Ruby with HTML interspersed.

Slim uses the same Ruby conditionals without closing tags:

/ Slim - conditionals
- if @user.premium?
  .premium-features
    h3 Premium Benefits
    ul
      li Unlimited projects
      li Priority support
      li Advanced analytics
- elsif @user.trial?
  .trial-banner
    p You have #{@user.trial_days_remaining} days left in your trial.
    = link_to 'Upgrade Now', upgrade_path, class: 'btn btn-primary'
- else
  .free-tier
    p Upgrade to unlock more features
    = link_to 'View Plans', plans_path, class: 'btn'

/ Inline ternary
span class=(@active ? 'badge-success' : 'badge-default')
  = @active ? 'Active' : 'Inactive'

The conditionals used identical Ruby keywords. Indentation determined block scope instead of end keywords. The HTML-like markup disappeared, replaced by Slim's terse syntax. Logic stayed the same while presentation changed dramatically.

Iteration patterns

Conditional rendering connected to loop structures. ERB iterates using Ruby blocks:

<!-- ERB - iteration -->
<ul class="notification-list">
  <% @notifications.each_with_index do |notification, index| %>
    <li class="notification <%= 'unread' if notification.unread? %>"
        data-notification-id="<%= notification.id %>"
        data-index="<%= index %>">

      <div class="notification-icon">
        <% case notification.type %>
        <% when 'message' %>
          <i class="icon-message"></i>
        <% when 'alert' %>
          <i class="icon-alert"></i>
        <% else %>
          <i class="icon-info"></i>
        <% end %>
      </div>

      <div class="notification-content">
        <p><%= notification.message %></p>
        <time><%= time_ago_in_words(notification.created_at) %> ago</time>
      </div>
    </li>
  <% end %>
</ul>

The <% each_with_index do %> started the iteration. HTML content lived inside the block. The block variable accessed current items. Case statements nested within loops. Everything closed with <% end %>. Standard Ruby iteration with HTML between tags.

Slim iterates identically without end keywords:

/ Slim - iteration
ul.notification-list
  - @notifications.each_with_index do |notification, index|
    li.notification class=('unread' if notification.unread?) data-notification-id=notification.id data-index=index

      .notification-icon
        - case notification.type
        - when 'message'
          i.icon-message
        - when 'alert'
          i.icon-alert
        - else
          i.icon-info

      .notification-content
        p = notification.message
        time
          = time_ago_in_words(notification.created_at)
          |  ago

The iteration used the same Ruby block syntax. Indentation closed the block automatically. Case statements worked identically. The Slim version looked denser without HTML angle brackets but followed the same logical structure.

JavaScript and CSS embedding

Loop structures influenced how I embedded other languages. ERB requires explicit script and style tags:

<!-- ERB - embedded JavaScript -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    const userId = <%= @user.id %>;
    const userName = '<%= j @user.name %>';
    const preferences = <%= raw @user.preferences.to_json %>;

    console.log(`User ${userName} loaded with ID ${userId}`);

    if (preferences.darkMode) {
      document.body.classList.add('dark-theme');
    }
  });
</script>

<!-- ERB - embedded CSS -->
<style>
  .user-<%= @user.id %> {
    background-color: <%= @user.theme_color %>;
    border-color: <%= @user.accent_color %>;
  }

  <% if @user.premium? %>
  .premium-badge {
    display: block;
  }
  <% end %>
</style>

I wrote <script> and <style> tags manually. Ruby interpolation worked inside JavaScript and CSS. The j helper escaped JavaScript strings. The raw helper output JSON safely. Mixing languages worked but lacked syntax highlighting in most editors.

Slim provides filters for embedded content:

/ Slim - filtered content
javascript:
  document.addEventListener('DOMContentLoaded', function() {
    const userId = #{@user.id};
    const userName = '#{j @user.name}';
    const preferences = #{raw @user.preferences.to_json};

    console.log(`User ${userName} loaded with ID ${userId}`);

    if (preferences.darkMode) {
      document.body.classList.add('dark-theme');
    }
  });

css:
  .user-#{@user.id} {
    background-color: #{@user.theme_color};
    border-color: #{@user.accent_color};
  }

  - if @user.premium?
    .premium-badge {
      display: block;
    }

The javascript: and css: filters wrapped content automatically. Interpolation used #{} directly. Conditionals worked inside filtered content. Some editors provided syntax highlighting within filters. The filter approach felt cleaner for substantial embedded code.

Output escaping

Embedded content highlighted escaping behavior. ERB escapes HTML by default:

<!-- ERB - automatic escaping -->
<p><%= @product.description %></p>
<!-- If description contains "<script>alert('xss')</script>" -->
<!-- Renders: <p>&lt;script&gt;alert('xss')&lt;/script&gt;</p> -->

<!-- Raw unescaped output -->
<div class="rich-content">
  <%= raw @post.html_content %>
</div>

<!-- Or use html_safe -->
<div class="rich-content">
  <%= @post.html_content.html_safe %>
</div>

<!-- Helper for safe JSON -->
<div data-config="<%= @config.to_json %>">

The <%= %> escaped HTML automatically, preventing XSS attacks. The raw helper rendered trusted HTML without escaping. The html_safe method marked strings as safe. The explicit raw call made unescaped content visible during code review.

Slim escapes identically with different raw syntax:

/ Slim - automatic escaping
p = @product.description
/ Renders: <p>&lt;script&gt;alert('xss')&lt;/script&gt;</p>

/ Raw unescaped output
.rich-content
  == @post.html_content

/ Interpolation also escapes
div data-config=@config.to_json

The = escaped all output. The == (double equals) rendered raw HTML. Interpolation with #{} escaped automatically. The shorter == syntax was less obvious than ERB's raw helper during review.

Comment types

Escaping behavior connected to commenting approaches. ERB uses HTML and Ruby comments:

<!-- ERB - comments -->

<!-- HTML comment - visible in page source -->
<div class="feature">
  <!-- This appears when viewing source -->
  <h2>Feature Title</h2>
</div>

<%# Ruby comment - stripped before rendering %>
<div class="stats">
  <%# This never appears in HTML %>
  <%# Used for developer notes %>
  <span><%= @user.stat_count %></span>
</div>

<%#
  Multi-line Ruby comment
  requires the closing tag
  on a separate line
%>

HTML comments <!-- --> appeared in rendered output. Ruby comments <%# %> got removed during preprocessing. The distinction was useful—HTML comments for debugging in browser dev tools, Ruby comments for developer notes in code. Multi-line Ruby comments needed careful tag placement.

Slim provides similar comment styles:

/ Slim - comments

/ HTML comment - visible in page source
.feature
  / This appears when viewing source
  h2 Feature Title

/! Multi-line HTML comment
   that spans several lines
   without repeating markers
   appears in output

-# Code comment - stripped
.stats
  -# Never appears in HTML
  -# Developer notes only
  span = @user.stat_count

The / created HTML comments in output. The /! created multi-line HTML comments. The -# created silent comments removed before rendering. Slim encouraged HTML comments over silent ones since / was shorter to type.

Whitespace control

Commenting patterns revealed whitespace handling. ERB outputs whitespace literally:

<!-- ERB - whitespace in output -->
<ul>
  <% @items.each do |item| %>
    <li><%= item.name %></li>
  <% end %>
</ul>

<!-- Renders with blank lines: -->
<ul>

    <li>First</li>

    <li>Second</li>

</ul>

<!-- Suppress trailing newline with -%> -->
<ul>
  <% @items.each do |item| -%>
    <li><%= item.name %></li>
  <% end -%>
</ul>

Blank lines from Ruby tags appeared in output HTML. For most layouts this didn't matter—browsers collapse whitespace. For inline elements or preformatted content, extra whitespace caused issues. The -%> suppressed trailing newlines. I used it sparingly or wrote compact templates.

Slim controls whitespace through syntax:

/ Slim - whitespace control
ul
  - @items.each do |item|
    li = item.name

/ Renders cleanly:
<ul>
  <li>First</li>
  <li>Second</li>
</ul>

/ Control inline spacing with markers
p
  | Text
  strong emphasis
  |  continues

Slim generated clean HTML without spurious newlines. The output matched template structure. The pipe | controlled text spacing precisely. The quote ' preserved multi-line whitespace. The explicit control prevented whitespace bugs without thinking about them.

Helper methods

Whitespace handling extended to helper usage. ERB calls helpers like Ruby methods:

<!-- ERB - helper methods -->
<%= link_to 'View Profile', user_path(@user),
            class: 'user-link',
            data: { turbo: true, controller: 'tooltip' } %>

<%= content_tag :div, class: 'alert alert-success' do %>
  <p><%= flash[:success] %></p>
<% end %>

<%= render 'shared/header', title: @page_title %>

<div class="formatted-text">
  <%= simple_format(@post.body) %>
</div>

<%= image_tag @product.image_url,
              alt: @product.name,
              class: 'product-image',
              loading: 'lazy' %>

Helper calls looked like standard Ruby with hash arguments. Block helpers used do...end syntax. Output helpers automatically escaped content. The standard Ruby calling conventions applied without modification.

Slim calls helpers identically:

/ Slim - helper methods
= link_to 'View Profile', user_path(@user), class: 'user-link', data: { turbo: true, controller: 'tooltip' }

= content_tag :div, class: 'alert alert-success' do
  p = flash[:success]

= render 'shared/header', title: @page_title

.formatted-text
  = simple_format(@post.body)

= image_tag @product.image_url, alt: @product.name, class: 'product-image', loading: 'lazy'

Helper invocation matched ERB completely. Arguments passed identically. Block syntax worked the same. The only difference was surrounding markup—Slim's terse elements versus ERB's HTML tags.

Performance characteristics

Helper compatibility revealed similar performance. ERB compiles to Ruby methods:

# ERB compilation output
def _app_views_users_show_html_erb___12345(local_assigns, output_buffer)
  user = local_assigns[:user]

  output_buffer.safe_append("<div class=\"user-profile\">\n")
  output_buffer.safe_append("  <h1>")
  output_buffer.safe_append(ERB::Util.html_escape(user.name))
  output_buffer.safe_append("</h1>\n")
  output_buffer.safe_append("</div>\n")

  output_buffer
end

Rails compiled ERB templates to Ruby methods once at startup in production. Subsequent renders called compiled methods directly. No parsing overhead after initial compilation. Runtime performance matched hand-written string concatenation.

Slim compiles similarly:

# Slim compilation output
def _app_views_users_show_html_slim___67890(local_assigns, output_buffer)
  user = local_assigns[:user]

  output_buffer.safe_append("<div class=\"user-profile\">\n")
  output_buffer.safe_append("  <h1>")
  output_buffer.safe_append(Temple::Utils.escape_html(user.name))
  output_buffer.safe_append("</h1>\n")
  output_buffer.safe_append("</div>\n")

  output_buffer
end

Compiled output looked nearly identical. Slim parsed its syntax, generated Ruby, then Rails compiled to methods. The parsing step added minimal overhead—happened once at boot. Benchmarks showed Slim marginally faster—around 5-8% in complex templates. The difference came from Slim's optimized parser, not architecture.

Tooling ecosystem

Performance parity made tooling important. ERB enjoys universal support:

# ERB - universal tooling
- Editors: Built-in support in VSCode, Sublime, Vim, RubyMine, Emacs
- Syntax highlighting: Excellent, HTML + Ruby
- Linting: Standard HTML validators work (HTMLHint, etc.)
- Formatting: Prettier, ERB formatters available
- HTML validators: All standard tools compatible
- Copy-paste: Direct from browsers, design tools
- Learning resources: Abundant tutorials, Stack Overflow
- Community: Massive user base

Every editor I used supported ERB through HTML modes with Ruby extensions. Syntax highlighting worked perfectly. HTML validators like HTMLHint caught structural errors. I copied HTML from browser dev tools or Figma and pasted directly. The tooling maturity came from ERB's age and HTML compatibility.

Slim requires dedicated tooling:

# Slim - specialized tooling
- Editors: Plugins required (quality varies)
- Syntax highlighting: Good with correct plugin
- Linting: slim-lint gem needed
- Formatting: Limited auto-formatting
- HTML validators: Don't work on Slim syntax
- Copy-paste: Must convert HTML to Slim
- Learning resources: Less content available
- Community: Smaller but active

I installed Slim plugins for each editor. Quality varied significantly—VSCode's plugin was solid, Sublime's lagged behind. Autocomplete worked for Slim syntax but not always for attributes. HTML copied from elsewhere needed conversion. The specialized tooling created more setup friction.

Format conversion

Tooling differences affected migration approaches. Converting ERB to Slim:

# Install conversion tool
gem install html2slim

# Convert single file
html2slim app/views/products/show.html.erb app/views/products/show.html.slim

# Convert entire directory
html2slim app/views app/views

The html2slim tool automated conversion reasonably well. Simple templates converted cleanly. Complex templates with intricate Ruby logic or unusual HTML needed manual fixes. I converted high-traffic views first, leaving stable templates in ERB. Gradual migration avoided disrupting development.

Converting Slim back to ERB:

# Install reverse converter
gem install slim2erb

# Convert files back
slim2erb app/views/products/show.html.slim app/views/products/show.html.erb

The slim2erb tool existed but saw less use. Conversion handled syntax differences but struggled with complex Ruby expressions and whitespace edge cases. Manual cleanup was often necessary.

Final thoughts

If you want your templates to stay close to regular HTML, ERB is the better choice. It works just like writing standard HTML with bits of Ruby mixed in. You don’t need to learn anything new, you can copy markup directly from design tools, and every code editor supports it. This makes it easy to read, easy to share, and ideal when you often work with existing HTML layouts.

However, if you’d rather write less code and keep your templates compact, Slim may suit you better. Its short, indentation-based syntax reduces typing and helps you avoid mismatched tags. Everything looks cleaner and more organized once you get used to it. Slim works best when you’re already comfortable writing Ruby and prefer a faster, more minimal way to build views.

In the end, the choice depends on what you value more: ERB gives you familiarity and full HTML compatibility, while Slim offers speed and simplicity through a shorter syntax.

Got an article suggestion? Let us know

Next article

Sidekiq: Background Job Processing in Ruby

Learn how to use Sidekiq for background job processing in Ruby. This step-by-step guide covers setup, worker creation, multiple queues, scheduling with sidekiq-cron, and monitoring jobs through the Sidekiq web dashboard using Redis for fast, reliable performance.

→

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