Rails 8, unreleased features

Rails 8 : More confidence in existing tools

Rails tend to anticipate the trends - which means how neat are the maintainers. ActionText is one example. Before Trix, let’s face it, giving any non-techie user the ability to write content was quite costly - or painful. Nowadays however, there are better tools than Trix. Simple features like “please create a <p></p> paragraph for every new paragraph” are still not released after years of PRs and requests from the community. I know, Open Source is given for free, and we should acclaim maintainer first instead of complaining. So first, a big thank you to all maintainers. Now for the Rails team, we would see two viable options :

• Make Trix stay on top of competition. Notably for SEO features and HTML compliance - <p></p> was just one example. But that would require tons of energy on only one tiny part of the Rails stack.
• Abandon Trix, and rely on the work of others.

We could be wrong of course, but at one point, we think that the second option seems more reasonable.

Trix was beating every other tool when it was released, but after a few years, maybe it’s time to reconsider and finally use something widely adopted by the community.

Rails 8 : Active Authentication

Maybe it should be the first paragraph, because it’s probably one of most missing features amongst Rails devs. That’s also true for our product (see the page why it’s time for better defaults, first bullet point). We can notice that most Rails projects use Devise, but this gem requires heavy hacks for corner cases. Which creates frustration. Moreover, authentication is always here, in any Rails app - I’ve never met any Rails app without it, so far. So making authentication here by default makes a lot of sense.

Hint : Here at BootrAils we use what we consider the closest “default gem” for authentication : Rodauth. Here is a tutorial about how to authenticate with Rodauth from scratch.

Rails 8 : another front-end manager ?

We are a little bit joking here, since front-end management has moved a lot in the past years, after a decade of decent stability.

They somehow tried to circumvent this problem by adding an extra layer on top of a choosable bundling tool.

The problem is, it is still two different tools for CSS and JS, and these two cohabit with the old - but mature - Sprockets pipeline.

As we said earlier, maybe it’s time to rely on existing tools. Finally Sprockets wasn’t widely used, and Webpack(er) was somehow complicated. However, the need for bundling is so high in the industry that probably a better standard should exist somewhere.

At bootrAils we found that ViteJS was this tool (we wrote an entire article about ViteJS and Rails), but it could be even better if there were a way to ask the community what do they prefer.

Change scaffolding, and align with Hotwire

Scaffolding is the ability for a Ruby-on-Rails app to generate Models, Views and Controller automagically. The user enters only the type of each field of a model, then migration file, models, controllers, views, unit tests are generated.

Since Hotwire is now in the place by default, these generators should be more aware of how Hotwire works. There is an attempt to glue Hotwire and scaffolding, in this Github repository named hot glue, but this is not part of the official Rails project, as far as we know.

Better production defaults

For every new Rails app, we have to tweak the production.rb defaults. Maybe it’s a good thing after all, so that each developer is aware of which config will apply on its own application. In our humble opinion, such things as force_ssl = true (and a few others) should be a default.

From Rails 7 to Rails 8 : A clearer Roadmap ?

What will be released in the next version of Rails is a mystery.

From what we understand, Ruby-on-Rails roadmap is basically Basecamp roadmap. The good news is, they do neat, brilliant work, and they release some new products, making Rails shine a little bit more on every new version. Probably the “Hey” product allowed Hotwire to gain new adopters, and allowed Ruby-on-Rails to be the new trendy toy - once again.

However it would be nice if the community was more involved in the Roadmap.

Rails 8 embeds some defaults

It cost nothing to delete (deprecated) code - just press “del”, but it cost a lot to write robust, tested code.

As far as I can remember, in Rails 3, the landing page was already included in the project. All you had to do is to remove the landing page and build your own.

It would be nice to have at least one controller, one view, one model, one migration, and a command to delete everything if this is not needed.

But from our experience, each time you have to test or isolate a new concept, you have to create a new Rails app, with at least a controller and a home page.

Rails 8, Rails X : we need some hot-reloading that works out-of-the-box

No matter which version of Rails we use, we always need hot-reloading to work. The problem is, it has never been a default feature of Rails, and surprisingly, it’s not so often claimed by the community as a de-facto feature.

If you code with NextJS or EmberJS (or any JS framework actually), you never hit the F5 key to reload the browser every time you modify a (front-end related) file. It seems quite obvious nowadays, and making it work with esbuild or guard is still very tricky.

Side note : This is something that works really well, if you use ViteJS with Rails.

Conclusion

Ruby-on-Rails 8 is far from being released, and we are neither committers, nor part of the Rails team. But it’s always good to take a step back, breathe, and think about what could be improved in the future.