Sneak Peek on Rails 8

2024-01-01

Planning for Rails 8 has started. I assume it will be released at Rails World Toronto on September 26 and 27, 2024 (as a certain bruised ego would probably not release at RailsConf). This is a quick summary of what we can expect:

Database-backed Jobs, Caching and Web Sockets

Rails 8 will feature new default adapters for Active Job, Caching and Action Job. They will all use the database as their backend. This is due to Basecamp’s conviction that SSDs are so fast these days that in-memory stores like Redis are not providing enough benefit over databases like MariaDB, PostgreSQL or SQLite. These are the new gems:

Discussions on GitHub point towards Mission Control (a web UI for Action Jobs) probably not being ready for the release of Rails 8.

Frontend

One goal of Rails 8 is to help people build progressive web apps, replacing the need for native wrappers for a lot of applications. Action Notifier will be a new part of Rails to send notifications to users. This will leverage the Push API (now supported in all major browsers) as well as alternative approaches. In addition, Rails will help with other aspects like the web manifest or service worker file.

Apart from that, we will see Turbo 8 with morph, view transitions, and local storage for offline mode. CableReady and StimulusReflex are soft-deprecated, and successors will be included in Hotwire.

Propshaft will become the default asset pipeline. You can use it both with the “no build” approach and with JavaScript and CSS bundlers.

In a sad turn of events, Rails will now add browser version blocking.

Language Server, Linting and Formatting

Aaron Patterson spoke about the advantages of offering a language server as part of Rails in multiple talks in 2023. This effort will probably be part of Rails 8. You can find his talk and the work on it for more details.

In addition, Rails 8 will include a Rubocop configuration in new applications for linting and code formatting. From the discussions, it will likely be a bike shed of creating a new configuration from scratch instead of using an existing one like standard.

Update: Apart from the changes above, a PR to include Brakeman by default on new applications has been merged. A PR with files for GitHub Actions running the tests, Brakeman and Rubocop as well as the configuration for Dependabot for automatic dependency updates has also been merged.

Smaller Changes

As with every major Rails version, the Ruby version requirement will be bumped. This time it will be Ruby 3.1. The Rack requirement is bumped to version 3.

In Rails 7.1, the core team added another building block for authentication. Chris Oliver created a great overview video to see how you can put it together. Rails 8 will feature a generator to add a basic authentication setup to applications. Most people will probably still make a better choice with devise.

It makes a lot of sense to log information in a way that can be consumed easily by tools like Logstash. My recommendation to do this has been Rails Semantic Logger for a while. This will no longer be necessary in Rails 8, as it will be built in.

Kamal will be added to the Gemfile of new applications by default (and can be skipped, of course).

There will also be a small Go-based proxy to support HTTP/2, public caching, and X-Sendfile designed to work with Puma. I’m not sure why this requires changes to Rails; let’s see.

Finally, Rails 8 will feature built-in rate limiting based on Redis via Kredis and a benchmarking tool.

Thanks

Thanks to nanoparsec for their feedback ❤️