Doing Rails Wrong

No, just no. Or maybe it depends. But if you want to provide a lovely, modern, interactive frontend, you can't just blindly ignore what evolved on the frontend ecosystem for the sake of your purity. It's arrogant and dismisses all the people who love to craft enjoyable frontends.

Following some thoughts about how to merge Rails and modern frontend approaches and how Inertia finally solved that question for me.

--

I consider myself more frontend focused but I have a deep love for Rails and some advanced experience, for sure less than in frontend though.

I tried hard following the route of hotwire, stimulus and friends knowing that DHH and the rest of the community loves those JS patterns.

Creating reusable stuff, cresting just a little bit more complex components, sharing those components through the UI.. it's just horrible cumbersome, repetitive and far, far away from all those best practices and patterns we've developed in the frontend.

I tried creating a diff viewer with comment functionality with stimulus. It worked, I was kind of proud but it was cumbersome the define components and share functionality. Maintainable? No way.

Then I wanted to create a double list where you can drag items from left to right. It was the hell to include css, js, manage the hierarchy and then I just gave up. I was demotivated by the constant nagging of my brain how much more simple this would have been with a single, simple react/vue component.

Then I went the wrong route: Rails API plus React. That's just giving up on most of what Rails gives you and I wasted ton of my time creating an additional auth layer on top of the session that Rails would give me. And then the horrible duplication of your state. One in Rails and then the same stuff in React. The same nagging in my brain now told me: That's wrong.

And then I found the holy grail of modern Rails development: Inertia.js. I heard about it very often but never at the right time. So I forced myself to try it out.

And here I am: I use Rails with Inertia Rails. I have the full pleasure of Rails but I can create React components that represent any page I like to write in React. Inertia will serialize and pass in the data from my controller. So no state. Just pure UI building.

If you love Rails and the frontend: Try out Inertia. It feels like I'm using the best of both worlds. The layer inertia creates is very shallow and optional. So the risk is low.

You could do the exact same breakdown describing the pieces of rails you need to learn to accomplish the same things, just because they are more separated libs in the front-end doesn't mean the problem is simpler if you solve it with rails' chosen tools vs the popular npm solutions.

That said you can avoid it. I wrote a website using Fresh (https://fresh.deno.dev/) and that was the only thing I needed. Incredibly simple compared to the usual Node/Webpack mess. Plus you're writing in Typescript, and can use TSX.

I probably would set up ESLint if multiple people were working on the project. But you can definitely start without anything else.

Sure it does. If you're not using Vite, how are you bundling? Oh, you're not bundling? I guess that means you're not using TypeScript? Interesting, how do you catch errors? Oh you just let things crash in production? How do other engineers understand the intent behind your code? Oh they don't I see. If you're not using React, what are you using? Vanilla JS? Have you considered that it's a statistical fact that every single person who has said "I don't need React, it's just a big complex mess, I'll just invent it myself" ends up creating an informally-specified, bug-ridden, slow implementation of half of React? Oh you don't use Prettier? OK, how are you formatting your code? Oh you're not, it's just a giant mess? Oh you're not using ESLint, interesting, how do you keep code consistent across your team? Oh that's not a concern? Hm.

Almost every technology in the article exists for good reason, and solves a real issue[1]. Maybe not an issue the author has encountered, but the author shows no understanding of the issues they are solving, and the final "punchline" implies that anyone could just toss all this tech out and improve their developer experience. "Learn the rules before you break them" applies here.

This is an uncurious article which mocks at abstractions rather than taking the effort to understand why they exist.

[1]: OK, I do think some abstractions are more trouble than their worth. But why did the author choose all the reasonable ones, like React? Why not dunk on Angular, I mean come on!