Spoiler alert: I still prefer Vue/Nuxt.js, but I'm definitely not opposed to React/Next.
I'll start by saying that this wasn't a complex project. It fetches some data from an API and displays it in a clean UI. No advanced logic. No complicated business rules. Just a simple front-end interface for browsing countries.
But simple can be good.
In fact, it made for the perfect experiment: build the same thing in two frameworks and focus entirely on what I was actually there to explore—the developer experience.
I already had this project built in Nuxt as part of a Frontend Mentor challenge. It used the REST Countries API to display a list of countries with features like search, filter, theme switching, and detail pages. A solid little interface. I figured: why not rebuild the whole thing in Next.js and see how the experience compares?
It's worth mentioning: I've been using Nuxt (and Vue) for over five years. My experience with Next (and React) is closer to a year. So this wasn't about crowning a winner. It was about shifting perspective—using a known project to get out of my Nuxt-shaped comfort zone and spend some focused time in Next-land.
The Setup
Here are both versions if you'd like to click around:
The core features were the same: API fetch, responsive layout, theme toggling, search and filter inputs, and basic routing. Not a complex app—but a good representation of the kinds of workflows I deal with all the time in production apps.
What I Noticed While Building
Since I already knew Nuxt, I started there. It took very little effort to scaffold things out and get a working version together. The separation of concerns in Nuxt still makes me happy: template for markup, script for logic, and style for styling. Each part of the file feels like what it's supposed to be. Familiar. Comfortable.
One thing I continue to love about Nuxt is how much it does for you. I don't have to manually import every component. Server-side API calls with Nuxt Nitro felt natural. I could filter and clean the data before it ever hit the browser, and the result was snappy and clean. It feels like a framework built with productivity and clarity in mind—especially for people who appreciate a structured mental model.
But there are tradeoffs. Vue directives like v-if, v-model, and v-for can feel like magic, and that magic doesn't translate easily to other environments. I've spent enough time in other stacks to know that when things aren't written in plain JavaScript, it can sometimes slow you down when context-switching or collaborating across teams.
Switching over to the Next version was… different.
Next.js feels much closer to raw JavaScript. There are fewer abstractions, and it felt more like I was building with a language I already knew, rather than learning a DSL specific to the framework. That made it easier to follow the flow and stay mentally connected to the underlying logic. But it also meant wiring up more pieces myself, which led to a few moments of friction. I missed some of Nuxt's conveniences—but I understood the trade.
Where Next really shines is the documentation. It's not even close. The clarity, the examples, the tone, the supporting tutorials—everything about Next's learning resources made me want to keep building. It's the kind of documentation that meets you at your level, no matter where you are.
And then there's JSX. I know, I know. People love it. But as someone who spent years writing vanilla HTML in a *.html file, and inside template tags, writing markup inside JavaScript still feels a little... wrong. I kept wanting to reach for a closing </template> tag that wasn't there. It's probably just personal taste—and some old-school muscle memory—but it slowed me down in ways I didn't expect.
A Few Shared Patterns
Both frameworks have a version of reusable logic: hooks in React, composables in Vue. They're not identical, but the mental shift between them wasn't that dramatic. The same can be said for their routers. Not having to maintain a routes file is kind of nice. Honestly, I could go either way there. Once you get used to the syntax, both patterns help keep logic clean and portable.
So, What's the Verdict?
In case you missed the spoiler above, I still prefer Nuxt.
But if I'm honest, that preference is mostly about familiarity. It's hard to beat five years of muscle memory and framework habits. I know where everything lives. I know what to reach for. It's home.
That said, I could absolutely see myself working long-term in a Next.js/React codebase again. The fundamentals make sense. The developer experience is good. And the way the ecosystem supports learning—through docs, examples, and training apps—is genuinely impressive.
Why Not Svelte? Or Angular? Or Qwik?
Fair question. There are a lot of shiny frameworks out there. And truthfully, I’d love to tinker with more of them. I’ve kicked the tires on Svelte a few times. Angular still has a presence in enterprise. Qwik and others are doing some seriously interesting things around performance and hydration.
But I picked React for a reason: market reach.
As much as I enjoy learning for learning’s sake, I also want to sharpen skills that are relevant in the job market. React has a massive footprint across industries and team sizes. If I’m going to invest my free time, I want to make sure I’m learning something that’s both satisfying and useful in the real world.
And—believe it or not—there’s more to life than coding websites. So for now, I’m spending that limited "learning time" where it makes the most impact. That might change down the line, but I’ve found that focus beats FOMO more often than not.
Why This Was Worth It
This little experiment reminded me how valuable it is to build the same thing in more than one way. It highlights things you don't always notice when you're heads-down on a production feature. Things like how the framework makes you feel. Where you pause. What feels intuitive, and what doesn't.
The differences weren't just about syntax. They were about friction, pacing, affordances, and decision fatigue. They were about developer experience, not just developer output. And that's exactly why I built it twice. I'll surely do something like this again in the future.