A Front-end Journey
back to Rails

For the longest time, ever since I started using Ruby on Rails just after the launch of version 3.0, front-end had always felt somewhat of an second-class citizen within the framework. You could get your basic CRUD UI, sprinkle a little bit of interactivity at the critical points, but as soon as your interface required a higher level of fidelity, you would have to reach for the Javascript framework du jour.

Grieving through growth

The development process of many applications I’ve worked on went something like this:

• (Day 0) This time, we’re going to stick to framework defaults!
• (Day 21) Well, we may need an island of React for this specific control.
• (Day 57) Well, actually we’re gonna need to whole page to be in React.
• (Day 94) Well, now we have 3 fully interactive pages, we could use client-side routing.
• (Day 112) We’re developing UI components, we’d like to use them everywhere, let’s do the entire front-end in React.
• (Day 238) REST is becoming cumbersome, let’s communicate with the front-end using GraphQL.
• (Day 300) At this point, our front-end is a completely separate process developed by a discrete team of React engineers.

This process feels like the stages of progressively grieving the fact that vanilla Rails didn’t quite support our high front-end expectations. While the support for front-end tooling got increasingly better over time, the core issue remained: your Rails app would likely increasingly split into two distinct entities written in two different languages, developed by distinct people.

Split entities

While this solution remained in my opinion the most efficient way to reach the goal of a high quality application, it came at a tremendous cost. To be considered autonomous, developers would need to be at least somewhat proficient at both sides of the divide. Ideally, they’d be very good at one and serviceable at the other. Others would firmly camp on one side, becoming narrow experts, at the cost of versatility. The split would even echo as far back as the organisational level, where one cohesive team of web engineers would become two distinct squads, backend and frontend.

This level of complexity really bothered me. In part because it felt like betraying the promise of Rails on some level, but mainly because this strain had a tangible negative effect on all metrics that matter to me, most of which enjoyment.

After 11 years, I didn’t quite enjoy programming anymore.

Fixing a relationship, the unlikely way

We’re now at the beginning of 2023, and the issue is clear to me: I can’t have a product be two completely different stacks hiding in a trench coat. I’m gonna have to pick one and stick to it.

During the past few years, I had been using Next.js as my front-end framework of choice, and it was clearly now aiming at being a full-stack framework. The choice was going to be between Rails and Next.js, so I started by picking the unlikely candidate: I started developing a side-project with the constraint of using Next.js only, no Rails backend API server (or anything else).

It was a first to me, and it was very uncomfortable in many ways. However, that challenge was exciting for a while, I’ll admit it reignited something in me. It forced me to think in different ways, it forced me to let go of many things, made things that were previously hard easier, but conversely made previously trivial things really complicated.

After a few months, I threw in the towel. This wasn’t gonna be it.

It wasn’t the limitations of Next.js — which, to its credit and the team at Vercel and all contributors, is an amazing powerhouse of functionality for how young it is in comparison — or the fact that it’s written in Javascript, it’s that I found myself missing Rails like crazy about once or twice a day. I kept repeating at various points “I’m gonna need a Rails process at some point”. This was the same grieving process, in reverse.

You know what they say: you don’t realize how much you love something until it’s gone. And I say that despite the fact that I was still using Rails every day in my main job.

Coming home…

Late September 2023. I was now pretty discouraged about my side project, and found myself asking the opposite question: “what if I could use only Rails?”.

To my surprise, delight, and kid-on-Christmas-Day level of excitement, while I was neck-deep focused on the React ecosystem, the Rails front-end ecosystem had dramatically changed. The once-dreaded Turbolinks was now Turbo, and reportedly didn’t suck anymore. Hotwire standardized broadcasting atomic template changes over WebSockets, and Stimulus gave small but sensible guidelines for the surprisingly tiny amount of Javascript that you’d still need around.

At first glance, it seemed like at least 90% of my high-fidelity front-end needs could, for the first time ever, be entirely met by core Rails framework features. And it looked like there were more on the way!

Much more importantly, it finally felt like the core promise of Rails: “The 15-minute blog”, “The one developer framework” was fulfilled without compromise.

… but not empty-handed

After binging hours of tutorials and videos, I got to work porting my side project back to Rails. I immediately recovered all the comfort I’d missed. I regained access to a decade’s worth of mechanical memory, design patterns and learned-by-heart framework APIs.

Things were going really well, and I was feeling all the joy and excitement that I’d lost. This was it. However, because fate loves irony, I was now missing design patterns and paradigms from the other side of the fence!

Core React features like Hooks, Suspense and Error Boundaries, flagship Next.js features like Route Interception and dynamic OpenGraph images, quality-of-life libraries like tailwind-variants, were gone.

My new challenge became, and remains this: can I have my cake and eat it too? Can I integrate the highlights of 5-7 odd years of thinking in React and bring them back home with me?

So far, the answer has been a resounding yes. For (almost, for now) all the above features and more, I have found or created an equivalent that allows me to preserve the lessons learned and keep the UX bar as high as I’ve always wanted it.

Looking forward

This was a side project. Knowing what I know now, would I choose the modern Rails/Hotwire stack for a professional project? The cautious, slightly jaded part of me says that it’s still a bit early to tell, but the newly excited, re-energized part says “we are so back” and I’m gonna let it have that one. The upside is too good to pass on.

In a future instalment, I’ll go over each of the aforementioned features and provide before/after React -> Rails code samples. Hope to see you there.

Thanks for reading!