From React to Hotwire - Part I - [EN]

Versão em Português do Brasil

Part II

In the latest edition of Tropical.rb, I announced that Linkana would be transitioning from React to Hotwire. This transition has already begun, and I want to share with you the challenges we are encountering. Before starting, I would like to look back on my experience with the frontend of my applications over the past few years.

Past - Server Side Rendering (SSR) - 2011/2017

At my first company, Eventick, we used only Rails views to create our frontend. The big challenge was creating layouts in a world where Flexbox or Grid did not exist. We relied on floats, absolute/relative positioning, and tables. JavaScript was limited to jQuery; trying to use pure JS was madness, as each browser behaved differently.

During this time, JavaScript began to be taken seriously. Internet Explorer was losing market share, and the first "modern" frameworks/libs began to emerge. I started using AngularJS 1.0, still integrated with Rails views. Angular's role was to create more interactive interfaces without needing to write many lines of JS or jQuery just to hide or show an element. The JavaScript ecosystem was gaining strength, while in Rails, it was very difficult to use NPM packages. The mindset was to use gems to add JS and CSS files, but the libs would get updates while their gems would not. This was when Rails fell behind in the frontend.

Shortly after, React appeared and started gaining attention, especially with the appeal of the Virtual DOM. It was a library that promised performance while being lightweight. At that time, Google decided to change the entire architecture of Angular with Angular V2, making V1 incompatible with the framework's future. Seeing Angular in crisis and React emerging, I started experimenting with React. Around this time, Eventick was sold to Sympla, and I knew my next project needed to be a SPA with React. It was inconceivable to start a startup in 2018 using the Rails approach.

Present - SPA - 2017/2024

At Linkana, we opted for GraphQL after reading an article from Airbnb mentioning that they were advancing 10 times faster with GraphQL and Apollo. But also due to my frustration with Redux, which always seemed like a complex and bureaucratic solution to me. Looking back, I believe it was the right decision. With Apollo and GraphQL, we could develop APIs in less time and avoid the complexity of managing state with Redux, Reflux, etc. However, the main drawback of GraphQL is that it makes the N+1 problem quite complex, something we still face today. Additionally, it complicates implementing cache in requests, though fortunately, this is not a problem we need to tackle at Linkana.

React also proved to be a good bet due to the large number of available libraries. On the other hand, being a library and not a framework, React code tends to become messy. It lacks the conventions of Rails. This is something we face at Linkana, but I don't consider it one of the most serious problems. We always try to organize our components using Atomic Design and a folder structure that we believe makes sense.

Another important bet at the beginning of Linkana was Grommet, a UI framework that offers React components for creating interfaces. Some may think it was a wrong bet since we eventually moved away from it and Grommet never took off, but that was not the case. At the time, we believed that "creating our own Design System" was a vanity common in many companies, large and small. This mentality, I believe, was a legacy of Twitter Bootstrap. Although Bootstrap was the first UI library to become popular, its strength was never customization. As a result, many sites ended up looking similar. Grommet, besides being a ready-to-use UI framework, was the only one available in 2017/2018 with a Figma file. More popular options like MUI and Ant Design did not offer this feature. Having the Figma file meant that design projects would be done within Grommet's sandbox, avoiding unnecessary customizations.

This architecture served Linkana well for a few years until we realized that Grommet, which initially made our work easier, was becoming an obstacle when we needed to make simple customizations. Additionally, it distanced us from CSS; we were learning Grommet, but not CSS. It was then that we set out to find Stack V2.

Stack V2 with Shadcn and Tailwind

Linkana's Stack V2 needed to maintain or increase our productivity while allowing us to make the minimal modifications we still desired.

The first bet I made was on Tailwind. Tailwind is known for "looks ugly and feels good." At first, many people may feel repulsed by looking at Tailwind classes in an HTML tag, but after a few hours of use, you realize how convenient it is not to worry about separate .css files anymore. Everything is available through classes. To understand this, I had to work on a side project.

Soon after, I discovered a new concept called "unstyled-ui," which are JS libraries that implement all the behavior of library components, leaving the CSS to be applied by you. Good examples are: Radix-ui, Headless-ui, and Tanstack.

The idea of having components without UI like Radix allows it to be added to any project. It is no longer necessary to "fight" to remove the component's style and make it fit your project. Or reinvent the wheel and build the component from scratch. When I saw this, the direction made a lot of sense to me.

But the real find was Shadcn. Shadcn is a library that brings together all these concepts. It uses Radix as a base, incorporates Tailwind to add style to Radix, and has a Figma file. Additionally, Shadcn innovated in one more aspect: instead of being an npm/lib package, it is just a set of reusable code that you can copy and paste into your project. As it says:

This is NOT a component library. It's a collection of reusable components that you can copy and paste into your apps.

Although this might seem strange, I have seen this model being increasingly applied in other projects, as it allows you to use components while giving you a customization possibility like never before. It combines the practicality of Bootstrap with the customization of a bespoke "Design System." Additionally, it includes an AI for generating graphical interfaces.

Bringing all this together, we have Linkana's React SPA frontend.

I will talk about Hotwire in part II of this article.