Published on
← Blog

Here's what's coming in Rails 8

Authors

Work on Rails 8 is starting, so I dug through the official GitHub milestone to break down all the upcoming goodies for you, right here in this article. There's plenty coming, including Solid Queue, Solid Cache and Kamal becoming defaults, better support for PWAs, an official LSP, an authentication generator and (much) more!

Table of Contents

It's a new year, and the official Rails 8 GitHub milestone is live! This milestone gives us a great idea of the new stuff coming in Rails 8; I've done some digging and summarized all the exciting new goodies in this article.

With Rails 8 slated for release sometime in 2024*, I think this article is a good way to get ahead (and excited!) about all the new stuff coming our way.

The broad brushstrokes of Rails 8 center around simplifying the stack, leaning into PWA's, adding simple first-party solutions to things like authentication, and improving developer experience — a lot of these additions seem driven by the ONCE products, so the focus on simplification makes sense.

Let's dive in!

*Update: In a recent blog post, DHH confirmed that Rails 8 will be released "...by the time Rails World 2024 rolls around". Rails World 2024 is scheduled for September 26 & 27, 2024.

So, if you're wondering about the Rails 8 release date, I'm thinking Rails 8 will be released on (or before) September 26, 2024.

Solid Queue and Solid Cache as defaults (plus a DB-backed ActionCable adapter)

Solid Queue and Solid Cache were released with great fanfare towards the end of 2023, and they're slated to become the default queue and cache implementations for Rails 8.

This is a pretty big shift! Until now, job queues and caching in Rails both relied on in-memory stores (think Redis or Memcached). These two new adapters (alongside the new and currently unreleased DB-backed ActionCable adapter — Solid Cable, anyone?) will let a Rails 8 app completely drop Redis/Memcached!

Of course, you'll still be able to use Redis if you wish, and in a lot of situations you'll probably want to. But, these DB-based adapters will let Rails 8 apps run without an in-memory store, simplifying the stack, cutting down the number of services a production Rails 8 app needs, and saving some $$$ on cloud hosting costs.

Related GitHub issues:

Note: There's a chance that Mission Control (video), the teased UI management panel for Solid Queue, could be included as part of Rails 8, but it's not guaranteed (GitHub discussion).

Progressive Web Apps (PWAs) are getting first-class support

... I have PWA tech as my #1 objective for Rails 8.

— DHH on Twitter

Progressive Web Apps (PWAs) are getting much better support in Rails 8, with the inclusion of Action Notifier, a new push notification framework, plus required PWA files being generated by default.

Action Notifier is the more exciting of the two, serving as an entirely new framework within Rails for managing push notifications (including managing badge counters, those little icons indicating your hundreds of unread emails). Action Notifier will be analogous to Action Mailer, but strictly for push notifications.

This push (hah!) for better PWA support in Rails 8 seems strongly in line with DHH's pro-PWA stance, driven in no small part, I imagine, by the app store shennanigans he's faced building HEY.

Related GitHub issues:

Basic Authentication Generator (finally!)

It's been a long time coming, but Rails 8 looks set to finally include an authentication generator!

From the GitHub issue —

We can teach Rails developers how to use the basic blocks [of authentication] by adding a basic authentication generator that essentially works as a scaffold, but for authentication.

— DHH

With Rails 7.1 including some big improvements to home-rolled authentication, and rate-limiting recently getting merged into Action Controller, Rails now contains all the pieces needed for a simple authentication solution.

The authentication coming in Rails 8 sounds like it will be relatively simple, far simpler than a heavyweight solution like Devise. It sounds like passkeys won't be initially supported (but that might come later), and will generate code directly rather than acting as a mountable engine.

In many cases, a solution like Devise may still be preferable, and we're still waiting for a pull request to materialize, but I'm excited! It's about time, and in the spirit of Rails 8, a simple native solution will simplify a large chunk of Ruby on Rails apps (particularly those running at smaller scales).

Related GitHub issues:

Improved linting and editor experience (including a default Rubocop!)

We've already covered a ton of great stuff coming in Rails 8, but the slated improvements to developer experience are some of my personal favorites.

Rails 8 has two major upcoming features here — a default Rubocop setup, and a default LSP.

As you'd expect, the Rubocop discussion thread was a bit contentious! Despite heavy support for Standard, Rails 8 looks set to ship with an Omakase Rubocop configuration instead. The intention here seems twofold — It's to serve as a basic, pared-back linter for Rails 8+ apps, and also a starting point for an in-house style guide (for individual projects or companies).

The default LSP excites me a lot — I hope it leads to a vastly improved editor/IDE experience for Ruby on Rails, ideally including things like autocompletion, hinting, jump-to-definitions and more. As DHH mentioned in the issue comment, Shopify is slowly building out the ruby-lsp-rails gem, alongside ruby-lsp — it's unclear whether ruby-lsp-rails will become the Rails default, or whether the Rails default will be derived from it, but I'm excited!

Between both of these improvements, I'm hoping Rails 8 will deliver a big bump to developer experience & happiness, à la the Rails doctrine.

Related GitHub issues:

Streamlined deployment with Kamal and GitHub CI Actions

With Rails 8 including Brakeman by default alongside Rubocop lint rules, a default GitHub CI action was the next logical step, and it's coming in Rails 8.

This new GitHub CI action will cover linting, running tests, scanning for vulnerabilities, and a Dependabot config for keeping dependencies up to date. Here's the merged PR if you're interested, with the intention being to double down on setting good habits for new apps.

Kamal is also going mainstream and will be included in all new Rails 8 apps as the default deployment solution, in line with DHH's trend towards platform agnosticism, and away from large cloud providers and vendor lock-in. Of course, you'll be able to use other deployment methods (like Dokku), and the Kamal installation is itself very lightweight (a single deploy.yml file, and a line in your Gemfile).

I'm hoping that Kamal's inclusion in Rails 8 will force it to mature a bit (the official docs seem a bit sparse), but I'm excited to watch the tool develop. The inclusion of a default GitHub CI action is also handy and will dovetail nicely into most people's workflows.

Related GitHub issues:

Other goodies (Propshaft, structured logging, benchmarking, HTTP/2 and more!)

Finally, here's a dump of the leftover goodies I couldn't fit above —

Related GitHub issues:

Conclusion

Thanks for reading! I hope you're as excited as I am for Rails 8.0 to be released! Don't forget to check out the official GitHub milstone for more info, and if you've got time, have a read through some of the issues there. I found the reasoning behind some of the decisions interesting, as well as reading through the discussions.

Even though these milestones are a solid indicator of what's coming in Rails 8.0, there's a chance things could still change, so don't take this article as gospel. If you notice anything I've missed or need to update, please let me know via email, or by commenting on this article.

Join 1050+ Ruby on Rails lovers

Join 1050+ Ruby on Rails lovers and get our weekly newsletter, no spam. Just interesting Rails articles, from here and around the web.

learn more / read previous issues