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.
