# Slim: a Ruby template language that trades closing tags for indentation

> Slim compiles indentation-based markup into HTML through Temple and Tilt, with automatic escaping on by default. Here is how it installs, what it costs you, and when ERB is still the better answer.

**slim-template/slim** — Slim is a template language whose goal is to reduce the syntax to the essential parts without becoming cryptic.

- Repository: https://github.com/slim-template/slim
- Website: https://slim-template.github.io
- Stars: 5,376 · Forks: 497
- Language: Ruby
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/slim-template-slim

## The problem Slim removes: closing tags and the mistakes they invite

Slim is a template language for Ruby whose stated goal is to reduce view syntax to the essential parts without becoming cryptic. The README frames the origin as an exercise in seeing how much could be removed from a standard HTML template: angle brackets, closing tags, and the rest. What remains is indentation, a small set of leading line indicators, and Ruby where you need it.

The audience is Ruby developers writing server-rendered views. The README says Slim supports Rails 5 and later, and that through Tilt it works with Sinatra or plain Rack. It is not a general-purpose templating library for other languages, and it is not a client-side renderer. If your HTML is produced by a JavaScript framework at runtime, Slim has nothing to do here.

The practical argument is not brevity for its own sake. Unclosed tags and mismatched nesting are the failure mode of hand-written HTML, and Slim's indentation rule makes that class of error structurally harder to write. The README claims this "pretty much guarantees that you write well-formed HTML and XML". That is the project's own wording, not a measured result.

## How Slim compiles a template: Temple, Tilt, and the plugin layer

Slim does not parse HTML. It parses its own syntax and compiles it, and the README names the components: Slim uses Temple for parsing and compilation, and is integrated into Tilt so Sinatra and Rack can use it. That split matters when you want to change behaviour. The README states that Temple's architecture allows extending the parsing and compilation process without monkey-patching, and that the logic-less plugin and the translator plugin (which provides I18n) are built on that extension point.

So the data flow is: a .slim file goes in, Temple turns it into a compiled representation, and the output is HTML with Ruby evaluated where you asked for it. The line indicators are the surface of that pipeline. A pipe copies a line verbatim with no processing. A dash marks control code. An equals sign emits an evaluated expression with escaping. A leading `<` lets you write raw HTML inline and behaves, per the README, like an implicit pipe.

Two details in the README are easy to miss and worth knowing before you write anything. First, indentation depth is not fixed: the README says you can indent two spaces and then five, and that nesting only requires one space of additional indent. Second, escaping is automatic by default, with support for Rails' html_safe?.

One design consequence deserves a plain statement. Because indentation carries structure, a reformatting tool that normalizes whitespace can change what your template renders. That is not a bug in Slim; it is the price of the syntax, and the README does not discuss it.

## Installing Slim and rendering your first template

The README gives one install command. Run it and the gem is available to your Ruby environment.

```bash
gem install slim
```

In a project, the README offers two equivalent routes: add the gem to your Gemfile, or require it directly.

```ruby
gem 'slim'
```

```ruby
require 'slim'
```

After that, the README's instruction is short: use the .slim extension and you are ready. In a Rails application the extension is what wires the file into the view pipeline; in Sinatra or Rack, Tilt handles the lookup.

The syntax example in the README is the fastest way to see what the language actually looks like. This is an excerpt from it, with the doctype, a nested head, an id shortcut, a class shortcut, a control block and a Ruby expression:

```slim
doctype html
html
  head
    title Slim Examples
    meta name="keywords" content="template language"
  body
    h1 Markup examples

    #content
      p This example shows you how a basic Slim file looks.

    - if items.any?
      table#items
        - for item in items
          tr
            td.name = item.name
            td.price = item.price
    - else
      p No items found. Please add some inventory.
```

What you should see when this renders: a full HTML document where `#content` becomes a div with that id, `table#items` becomes a table with that id, and each row is produced by the `for` loop over `items`. The `-` lines emit nothing themselves; they only control flow. The `=` lines emit the escaped value of `item.name` and `item.price`.

One more thing to try while you are learning the indicators, because it is the part people get wrong. The README documents `|<`, `|>`, and `|<>` for adding leading, trailing, or both kinds of whitespace around verbatim text:

```slim
| This line will not have any extra white space.
|< This line will have a leading white space.
|> This line will have a trailing white space.
```

If you find yourself fighting whitespace between inline elements, these are the tools, not string concatenation.

## Where Slim is the wrong choice

Slim is a poor fit when the people editing templates are not programmers. The syntax embeds Ruby by design, and the logic-less plugin exists precisely because some users want the Slim syntax without Ruby in their templates. If your workflow hands templates to designers who work in a visual editor, indentation-as-structure will fight every round trip through that editor.

The second limitation is the one the README leaves open. There is a CHANGES file in the repository root and the releases are tagged, but the README does not document a rollback procedure or a version-to-version upgrade path. If you need a documented migration story before you commit, this README will not give you one, and you should read CHANGES directly rather than assume.

The third is performance framing. The README claims speed comparable to ERB and Erubis, and then says plainly that you should not trust the numbers and should run the benchmark rake task yourself. That is an honest position, but it also means the project is not asking you to adopt it for speed. If raw render throughput is your deciding criterion, the README itself declines to make that case.

Finally, consider the cost of the syntax itself. Every new contributor has to learn the line indicators, and every code review has to notice indentation changes that look like reformatting. In a codebase with many occasional contributors, ERB's verbosity buys you something.

## Slim against Haml and plain ERB

The README is explicit that Slim's syntax was influenced by Haml and by Jade, and that the team accepts additions from that lineage. So the honest comparison is not Slim versus nothing; it is Slim versus Haml, which shares the indentation model.

The difference in approach is the compilation layer. Slim builds on Temple, and the README describes that architecture as flexible enough to add syntax extensions and plugins without monkey-patching, with the logic-less and I18n translator plugins as working examples. If you want to extend the language or hook into compilation, that is the part of Slim worth examining. Haml has its own engine and its own extension story; the README does not compare the two, so treat any deeper claim as something you need to check yourself.

Against ERB the trade is clearer. ERB keeps HTML intact and inserts Ruby between tags. Slim replaces the tags with structure. ERB is a drop-in for anyone who knows HTML; Slim is a drop-in for the framework, as the README notes, but not for a person who has never seen the syntax. The README also mentions embedded engines like Markdown and Textile, which is a capability ERB does not offer in the same form.

## Maintenance, releases, and what the MIT licence means here

The repository is not archived, and the most recent push recorded is 2026-07-24, which is the same day as the v5.2.2 release. Before that, v5.2.1 is dated 2024-01-20 and v5.2.0 is dated 2023-11-11. Read that sequence for what it is: a long gap between 5.2.0 and 5.2.1, then a long gap before 5.2.2. A template engine that changes slowly is not automatically a problem, since the surface it compiles to is HTML, but it does mean you should not expect frequent releases and you should read CHANGES when one arrives.

The repository root contains a Gemfile, a Rakefile, a slim.gemspec, a bin directory, a doc directory, a test directory, and both README.md and README.jp.md. The README points to the homepage at slim-template.github.io and to API documentation on rubydoc.info for both the latest gem and the main branch. Those are the sources to check when the README is silent, as it is on upgrade mechanics.

Slim is MIT licensed. That is a permissive licence, and the practical implication is that you can use it in closed-source applications. It is not legal advice, and if your organisation has rules about attribution notices or bundled dependency licences, the LICENSE file in the repository is the document to read.

## Conclusion

Adopt Slim if your team writes views by hand in Rails, Sinatra or plain Rack and wants markup that cannot easily be left unclosed, and if you are willing to accept that indentation is now part of your markup's meaning. Do not adopt it if your templates are generated by a visual tool, if your team already edits ERB comfortably, or if you need a documented upgrade path between major versions, because the README does not describe one. Before committing, install the gem, render the syntax example from the README in a scratch Rack app, and check one thing the README leaves open: whether your editor and diff tooling handle significant whitespace the way your team expects.

## FAQ

### How slim is slim?

The README says Slim was developed from the start with performance in mind and claims speed comparable to ERB and Erubis, but it also tells readers not to trust the numbers and to run the benchmark rake task themselves. The project's stated position is that you should choose Slim for its syntax and features, not for speed.

### What does "slim" mean?

In this project the name refers to a template language whose goal is to reduce the view syntax to the essential parts without becoming cryptic. The README describes it as starting from an exercise to see how much could be removed from a standard HTML template, such as angle brackets and closing tags.

### How slim is slim?

The README states that Slim uses Temple for parsing and compilation, and that Temple's architecture allows the parsing and compilation process to be extended without monkey-patching. The logic-less plugin and the I18n translator plugin are built on that extension point.

## Sources

- [License: MIT](https://github.com/slim-template/slim/blob/main/LICENSE)
- [Project website](https://slim-template.github.io)
- [README](https://github.com/slim-template/slim/blob/main/README.md)
- [Releases](https://github.com/slim-template/slim/releases)
- [slim-template/slim on GitHub](https://github.com/slim-template/slim)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/slim-template-slim