Every so often, a tech stack decision that once felt right starts to show its limitsâlike realizing just how inefficient a screwdriver is after using a power drill. Thatâs been the case with HackerNoonâs use of Styled Components. For years, it served us wellâoffering scoped styles, dynamic theming, and full control within our React components. But as our codebase evolved and tools like Tailwind CSS matured, it became clear that a change was overdue.
This post is a breakdown of our shift from Styled Components to Tailwind CSS, why we made the move, how I approached the transition, and what the process has looked like so far. If you're working with legacy styles or considering Tailwind for your own projects, hopefully this gives you something useful (or at least relatable) to walk away with.
Why HackerNoon Originally Used Styled Components
I wasnât part of the team when Styled Components was first chosen to handle our CSS, but at the time, Tailwind CSS hadnât even been released, and Styled Components made a lot of sense for HackerNoonâs front-end architecture.
It allowed developers to write CSS directly within JavaScript, making components fully self-contained. This approach felt very âReact-nativeâ in natureâencapsulated, reusable, and, at the time, thought to be easier to maintain across a growing codebase and team. The dynamic styling capabilities, built-in theming support, and ability to pass props directly into styles worked especially well for the wide variety of pages and layouts we were building. For a long time, Styled Components served HackerNoon well.
What Made Us Consider Switching to Tailwind?
Over time, our codebase grewâand so did the complexity of managing styles.
Styled Components gave us flexibility, but that came at a cost: larger bundle sizes, runtime performance hits, and a cluttered component structure filled with increasingly long styled blocks. It was getting harder to trace styles or reuse them effectively without duplicating code.
We also noticed many of our styles were repeating across components. Thatâs when Tailwind CSS started to make a lot of sense. The utility-first approach felt like a way to streamline everythingâfrom layout to responsiveness and even theming.
But letâs be real: for a small dev team like HackerNoonâs, the idea of refactoring a massive codebase line by line felt like a huge undertaking. Still, we couldnât ignore how widely Tailwind was being adopted in the dev community. We wanted in.
How I Made the Switch
The hardest part of this switch? Setup.
Installing Tailwind was straightforward, but once it was active, Tailwindâs global stylesâthanks to Preflightâstarted clashing with our existing components. Styles were broken left and right.
A lifesaver here was setting preflight: false in the tailwind.config.js file. That move disabled most of Tailwindâs base resets, which brought back some order. Sure, there were still minor styling issues to fix, but things looked less like a war zone.
From there, I had to establish new conventionsâhow weâd handle global styles, reuse classes, and build theme-aware components with Tailwind. Once that foundation was laid, I was ready to build.
And here's the part Iâm still amazed by: AI made this process actually enjoyable.
Refactoring thousands of lines of code solo wouldâve been madness. But I used ChatGPT to convert our styled components into Tailwind one at a time. For simple componentsâlayouts, spacing, structureâit was a breeze. Just paste, tweak, and go.
Now, let me be honest: AI didnât get everything right. More complex, themed components still required manual coding and plenty of hours. But having a solid base to start from made things so much easier. Tailwindâs documentation also helped fill the gaps, and once I fully embraced the utility class mindset, things started to click.
What the Migration Looks Like So Far
Iâm happy to say Tailwind is now live on HackerNoon! đ
As of now, the HackerNoon Homepage is fully converted to Tailwind CSS, with Styled Components completely removed. Most of the other pages still rely on Styled Components, and theyâll be converted graduallyâone component, one page at a time.
This slower approach has actually been a blessing. Refactoring each component gave me the opportunity to revisit and improve the design and structure of our pages. Alongside the Tailwind conversion, we introduced a more modern UI, better layout usage, new components, and even a custom-built theme picker that puts our old theming system to shame.
After working at HackerNoon for over 4 years, I feel reignited diving into our codebase again. Tailwind has made building fun again. Itâs clean, consistent, and powerfulâand Iâm excited to keep pushing the conversion forward. Who knows? Maybe soon, weâll be deleting styled-components from our package.json for good. đ
Final Tailwinding Thoughts
The move to Tailwind CSS wasnât just about swapping out a styling libraryâit was about modernizing our frontend workflow, embracing consistency, and simplifying development. While Styled Components helped shape HackerNoonâs interface during a critical growth phase, Tailwind is giving us the flexibility, speed, and maintainability we need as we continue to scale.
Itâs still a work in progressâour app still has plenty of Styled Componentsâbut seeing Tailwind live on our homepage and in newly refactored components has been incredibly rewarding. The fact that I can pair AI with my own expertise to refactor faster has made this transition feel not only doable but exciting.
HackerNoon is evolving, and our styles are evolving with it. One component at a time.