{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/dev-37signals-com/2024-12-12-a-vanilla-rails-stack-is-plenty/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps.\n\nIf you have the luxury of starting a new Rails app today, here’s our recommendation: go vanilla.\n\n- Fight hard before adding Ruby dependencies. Keep that Gemfile that Rails generates as close to the original one as possible.\n- Fight even harder before adding Javascript dependencies. You don’t need React or any other front-end frameworks, nor a JSON API to feed those.\n- [Hotwire](https://hotwired.dev/) is a fantastic, pragmatic, and ridiculously productive technology for the front end. Use it.\n- The same goes for mobile apps: use [Hotwire Native](https://native.hotwired.dev/). With a hybrid approach you can combine the very same web app you have built with a wonderful native experience right where you want it. The productivity compared to a purely native approach is night and day.\n- Embrace and celebrate rendering things on the server. It has become cool again.\n- ERB templates and view helpers will take you as long as you need, and they are a fantastic common ground for designers to collaborate hands-on with the code.\n- [#nobuild](https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c) is the simplest way to go; don’t close this door with your choices. Instead of bundling Javascript, use [import maps](https://github.com/rails/importmap-rails). Don’t bundle CSS, just use modern standard CSS goodies and serve them all with [Propshaft](https://world.hey.com/dhh/introducing-propshaft-ee60f4f6). If you have 100 Javascript files and 100 stylesheets, serve 200 standalone requests multiplexed over HTTP2. You will be delighted.\n- Don’t add Redis to the mix. Use [solid\\_cache](https://github.com/rails/solid_cache) for caching, [solid\\_queue](https://github.com/rails/solid_queue) for jobs, and [solid\\_cable](https://github.com/rails/solid_cable) for Action Cable. They will all work on your beloved relational database and are battle-tested.\n- Test your apps with Minitest. Use fixtures and build a realistic set of those as you cook your app.\n- Make your app a [PWA](https://world.hey.com/dhh/native-mobile-apps-are-optional-for-b2b-startups-in-2024-4c870d3e), which is fully supported by Rails 8. This may be more than enough before caring about mobile apps at all.\n- Deploy your app with [Kamal](https://kamal-deploy.org/).\n\nIf you want heuristics, your `importmap.rb` should import Turbo, Stimulus, your app controllers, and little else. Your `Gemfile` should be almost identical to the one that Rails generates. I know it sounds radical, but going vanilla is a radical stance in this convoluted world of endless choices.\n\nThis is the Rails 8 stack we have chosen for our new apps at [37signals](https://37signals.com/). We are a tiny crew, so we care a lot about productivity. And we sell products, not stacks, so we care a lot about delighting our users. This is our [Omakase](https://rubyonrails.org/doctrine#omakase) stack because it offers the optimal balance for achieving both.\n\nVanilla means your app stays nimble. Fewer dependencies mean fewer future headaches. You get a tight integration out of the box, so you can focus on building things. It also maximizes the odds of having smoother future upgrades. Vanilla requires determination, though, because new dependencies always look shiny and shinier. It’s always clear what you get when you add them, but never what you lose in the long term.\n\nIt is certainly up to you. [Rails is a wonderful big tent](https://rubyonrails.org/doctrine#big-tent). These are our opinions.\n\nIf it resonates, choose vanilla!\n\n* * *\n\nGuess [what our advice is for architecting your app internals](https://dev.37signals.com/vanilla-rails-is-plenty/)?\n\nSign up to get posts via email,\\\n or [grab the RSS feed](https://dev.37signals.com/feed/posts.xml).\n", "authors": [ "Jorge Manrubia" ], "captured_at": "2026-09-19T21:30:23.395188495+00:00", "category": "programming", "content_html": "

Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps.

\n

If you have the luxury of starting a new Rails app today, here’s our recommendation: go vanilla.

\n\n

If you want heuristics, your importmap.rb should import Turbo, Stimulus, your app controllers, and little else. Your Gemfile should be almost identical to the one that Rails generates. I know it sounds radical, but going vanilla is a radical stance in this convoluted world of endless choices.

\n

This is the Rails 8 stack we have chosen for our new apps at 37signals. We are a tiny crew, so we care a lot about productivity. And we sell products, not stacks, so we care a lot about delighting our users. This is our Omakase stack because it offers the optimal balance for achieving both.

\n

Vanilla means your app stays nimble. Fewer dependencies mean fewer future headaches. You get a tight integration out of the box, so you can focus on building things. It also maximizes the odds of having smoother future upgrades. Vanilla requires determination, though, because new dependencies always look shiny and shinier. It’s always clear what you get when you add them, but never what you lose in the long term.

\n

It is certainly up to you. Rails is a wonderful big tent. These are our opinions.

\n

If it resonates, choose vanilla!

\n
\n

Guess what our advice is for architecting your app internals?

\n

Sign up to get posts via email,
\nor grab the RSS feed.

\n", "content_markdown": "Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps.\n\nIf you have the luxury of starting a new Rails app today, here’s our recommendation: go vanilla.\n\n- Fight hard before adding Ruby dependencies. Keep that Gemfile that Rails generates as close to the original one as possible.\n- Fight even harder before adding Javascript dependencies. You don’t need React or any other front-end frameworks, nor a JSON API to feed those.\n- [Hotwire](https://hotwired.dev/) is a fantastic, pragmatic, and ridiculously productive technology for the front end. Use it.\n- The same goes for mobile apps: use [Hotwire Native](https://native.hotwired.dev/). With a hybrid approach you can combine the very same web app you have built with a wonderful native experience right where you want it. The productivity compared to a purely native approach is night and day.\n- Embrace and celebrate rendering things on the server. It has become cool again.\n- ERB templates and view helpers will take you as long as you need, and they are a fantastic common ground for designers to collaborate hands-on with the code.\n- [#nobuild](https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c) is the simplest way to go; don’t close this door with your choices. Instead of bundling Javascript, use [import maps](https://github.com/rails/importmap-rails). Don’t bundle CSS, just use modern standard CSS goodies and serve them all with [Propshaft](https://world.hey.com/dhh/introducing-propshaft-ee60f4f6). If you have 100 Javascript files and 100 stylesheets, serve 200 standalone requests multiplexed over HTTP2. You will be delighted.\n- Don’t add Redis to the mix. Use [solid\\_cache](https://github.com/rails/solid_cache) for caching, [solid\\_queue](https://github.com/rails/solid_queue) for jobs, and [solid\\_cable](https://github.com/rails/solid_cable) for Action Cable. They will all work on your beloved relational database and are battle-tested.\n- Test your apps with Minitest. Use fixtures and build a realistic set of those as you cook your app.\n- Make your app a [PWA](https://world.hey.com/dhh/native-mobile-apps-are-optional-for-b2b-startups-in-2024-4c870d3e), which is fully supported by Rails 8. This may be more than enough before caring about mobile apps at all.\n- Deploy your app with [Kamal](https://kamal-deploy.org/).\n\nIf you want heuristics, your `importmap.rb` should import Turbo, Stimulus, your app controllers, and little else. Your `Gemfile` should be almost identical to the one that Rails generates. I know it sounds radical, but going vanilla is a radical stance in this convoluted world of endless choices.\n\nThis is the Rails 8 stack we have chosen for our new apps at [37signals](https://37signals.com/). We are a tiny crew, so we care a lot about productivity. And we sell products, not stacks, so we care a lot about delighting our users. This is our [Omakase](https://rubyonrails.org/doctrine#omakase) stack because it offers the optimal balance for achieving both.\n\nVanilla means your app stays nimble. Fewer dependencies mean fewer future headaches. You get a tight integration out of the box, so you can focus on building things. It also maximizes the odds of having smoother future upgrades. Vanilla requires determination, though, because new dependencies always look shiny and shinier. It’s always clear what you get when you add them, but never what you lose in the long term.\n\nIt is certainly up to you. [Rails is a wonderful big tent](https://rubyonrails.org/doctrine#big-tent). These are our opinions.\n\nIf it resonates, choose vanilla!\n\n* * *\n\nGuess [what our advice is for architecting your app internals](https://dev.37signals.com/vanilla-rails-is-plenty/)?\n\nSign up to get posts via email,\\\n or [grab the RSS feed](https://dev.37signals.com/feed/posts.xml).\n", "dateCreated": "2026-09-19T21:30:23.395188495+00:00", "date_created": "2024-12-12T18:00:00+00:00", "date_modified": "2024-12-12T18:00:00+00:00", "date_published": "2024-12-12T18:00:00+00:00", "description": "Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps.", "external_url": "https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/dev-37signals-com/2024/12/2024-12-12-a-vanilla-rails-stack-is-plenty.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/dev-37signals-com/2024/12/2024-12-12-a-vanilla-rails-stack-is-plenty.md" }, "id": "urn:aggr:item:daa3b6189cc84013e98a23a3caab077a784aa26f", "isBasedOn": { "@id": "https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/" }, "mainEntity": { "@id": "https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/dev-37signals-com/2024-12-12-a-vanilla-rails-stack-is-plenty/#webpage" }, "author": [ { "@type": "Person", "name": "Jorge Manrubia" } ], "dateModified": "2024-12-12T18:00:00+00:00", "datePublished": "2024-12-12T18:00:00+00:00", "headline": "A vanilla Rails stack is plenty", "timeRequired": "PT3M", "url": "https://dev.37signals.com/a-vanilla-rails-stack-is-plenty/", "wordCount": 529 }, "name": "Archived snapshot: A vanilla Rails stack is plenty", "preview": null, "reading_minutes": 3, "replicated_at": null, "source": "dev-37signals-com", "source_name": "37signals Dev", "summary": "Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps.", "tags": [], "temporalCoverage": "2026-09-19T21:30:23.395188495+00:00", "title": "A vanilla Rails stack is plenty", "url": "https://aggr.aymericbeaumet.com/items/dev-37signals-com/2024-12-12-a-vanilla-rails-stack-is-plenty/", "word_count": 529 }