To Framework or Not to Framework, that is the question

Last year, I was in an in-person technical interview at a local startup (one of those that would later ghost me, but that’s a story for another day).

Somewhere in the middle of it, the interviewer asked me, non-verbatim:

“If you were a team lead assigned to a new frontend project, how would you determine whether to use React or Next.js, and why?”

Safe to say, I fumbled it. Not catastrophically (I think), but enough to know for certain that I blew up the hiring chances for good.

Obviously, I didn’t get the job (womp, womp). But fast forward to now where I’m preparing for another interview, I kept coming back to that same question that I butchered.

The thing is, it’s not a trick question. It’s not even a particularly hard one, but it requires a framework for thinking about frameworks (sorry) that I didn’t have one at the time.

So I figured, why not do a write up for the answer I wish I’d given.

TL;DR

What you’re actually choosing between

First off, people often lump libraries, frameworks, and metaframeworks together — even though they’re not the same thing.

Vanilla Vue or React is a UI library. It handles components, reactivity, and the view layer. Everything else — routing, data fetching, rendering strategy, server logic — you wire up yourself or pull in separately.

You get control. You also get every architectural decision landing on you.

Nuxt or NextJS meanwhile is an opinionated metaframework built on top of that library. File-based routing, SSR/SSG/ISR out of the box, server API routes, middleware, image optimisation. You trade flexibility for convention and built-in capability.

The decision isn’t which is better. It’s: does your project actually need what the metaframework provides? If it doesn’t, you’re paying the complexity cost without collecting any of the benefits.

The questions that actually matter

1. Does this need to be indexed?

This is the first filter, and often the only one you need.

If the app lives entirely behind authentication e.g. a dashboard, admin panel, internal tool, SaaS product, then SEO is irrelevant. No crawler needs to read it. SSR buys you nothing.

Plain Vue with client-side rendering is not just acceptable, it’s the right call. Simpler to deploy, cheaper to run, no server to maintain.

If any part of the application is public-facing and needs to appear in search results, you will need SSR or SSG. That means a metaframework, because building your own SSR pipeline is a significant undertaking and you’d essentially be rebuilding what Nuxt already gives you.

2. Do you need different rendering strategies on different routes?

In reality, more often than not an application has mixed requirements: a public landing page that should be SSG, product pages that need ISR because inventory changes, a blog that can be fully static, and a user dashboard that should be CSR.

In plain Vue, handling this requires custom infrastructure. In Nuxt, it’s a few lines of config:

routeRules: {
  '/': { prerender: true },
  '/blog/**': { ssg: true },
  '/products/**': { isr: 60 },
  '/dashboard/**': { ssr: false },
}

If your project has this kind of mixed requirements, the metaframework is the way to go.

3. Do you need server-side capabilities without a separate backend?

Nuxt’s server routes let you write backend logic in the same project i.e. proxying third-party APIs, protecting secret keys that can’t live in the client and handling webhooks.

export default defineEventHandler(async (event) => {
  const user = await fetchFromDatabase(event.context.user.id)
  return user
})

If your team already has a dedicated backend, this is less relevant. Your server logic belongs there and the frontend should just be purely UI. A library/framework here would make more sense.

4. What’s the team’s experience level?

Metaframeworks add concepts and abstractions. Nuxt specifically introduces file-based routing conventions, auto-imports, the Nitro server engine, composable patterns, and hybrid rendering configuration.

A junior-heavy team building an internal tool might not adapt so easily to that overhead. Plain Vue with a deliberate folder structure is easier to reason about, easier to debug, and easier to onboard into. The metaframework’s conventions only help when everyone understands what they’re conventions of.

5. How long will this live and how might it grow?

Future-proofing one’s work is a thought that always lives rent-free inside an engineer’s head. An internal dashboard that might become public-facing in 18 months is a meaningful consideration.

Migrating from CSR to SSR after the fact is especially painful as it surfaces hydration mismatches, requires rethinking data fetching patterns, and often means restructuring the project. Starting with Nuxt in CSR mode costs almost nothing upfront and keeps the door open.

Conversely, if the scope is genuinely fixed and will never need SEO, carrying the metaframework indefinitely for a future that won’t arrive is unnecessary weight.

When a library is the right call

• The app lives entirely behind auth
• SEO is irrelevant
• The team wants explicit control over routing and data fetching
• You’re building something highly interactive where the complexity is in the client-side logic, not in rendering strategy
• The scope is well-defined and you want to move fast without learning framework conventions

When a metaframework is the right call

• Any part of the app is public-facing and needs to be indexed
• You need different rendering strategies per route
• You need lightweight server capabilities without a separate backend
• First paint performance matters — SSR delivers complete HTML immediately, which directly improves LCP and TTFB
• The project is content-heavy and SSG through Nuxt Content simplifies the content pipeline
• You want consistent structure across a larger team where opinionated conventions reduce decision fatigue

Reflection

Fear of missing out (FOMO) in the tech scene is real. Add impostor syndrome to the mix, and voilà; you’ve got the two deadly sins of software engineering. It nudges people toward metaframeworks because they feel more serious, more complete, more “production-ready”.

But complexity isn’t free. It shows up in onboarding time, a larger debugging surface area, heavier deployment infrastructure, and a mental model every developer has to carry.

A metaframework only makes sense when you’re getting real value from it. Otherwise, it’s just unnecessary weight.

In a world obsessed with premature optimization where everyone is racing toward the biggest and the best, it’s worth remembering that tools aren’t the goal. They’re a means to an end.

And more often than not, the simplest tool that gets the job done is the right one.