Interviews are the worst time to discover your "default stack" isn’t safe.
My task was simple: build a little app — a map with places and a sidebar list. I could pick any stack I wanted.
Naturally, I went with my bread and butter: React. Add Leaflet (used it before in Vue and it was fine), and since the “default recommended React starter” these days is Next.js, I grabbed that, why not.
Yes, I know that a Vite starter exists, but unfortunately I didn't evaluate it beforehand:
Does it come with TypeScript?
Who maintains it?
I needed something reliable - every second counts during an interview.
So I picked Next. Boy, that was the wrong decision.
First of all, I knew beforehand that a map won't work in SSR and it doesn't need to.
I knew it would be a client component, I'd just slap "use client" and be done.
That didn't work somehow. There were so many hiccups.
Confusing SSR / client issues, cryptic errors.
My map wouldn’t render cleanly. Precious minutes wasted.
By the way, a fresh NextJS starter takes 10 seconds to run... Why?
I mean, it's nothing, but I just wonder what numbers look like in real projects?
So I ditch it, spun up raw Vue and bam - I'm done in minutes.
That moment made me realize that I didn’t have a safe default choice anymore.
And it pushed me down the rabbit hole of reevaluating today’s frontend frameworks.
Here’s what I learned:
React & Ecosystem
Pros:
+ Simple JSX syntax + raw JS inside markup
+ Options for SSR beyond Next.js (e.g. TanStack Start)
Cons:
- useEffect - still a hot mess, we all know it, you just might not want to admit it; (See Cloudflare outage.)
- VDOM, every other framework ditched it in 2025 or didn't have it to start with
- React Compiler, Promise vs Reality: you still juggle memo, useMemo, and useCallback.
- React Router's Identity Crisis: can't decide if it is a framework or a router or a framework again (or was it Remix? will be again?), I'd just pick another router over it, and another framework (but curious for the Remix v3)
Too many band-aids, not enough stability.
NextJS:
- Slow app start, even for fresh projects
- Vague error messages, missing descriptions, errors about "window" but the app still works? Trust me bros it works! Just don't look at the red exclamation mark here! Confidence killer.
- App Router vs Pages Router: both exist, both half-overlap, and you’re left to choose. Make a decision and own it. It's confusing.
Angular:
+ Incremental DOM
+ Clear roadmap
+ Adoption of signals
+- On one hand, a bit behind other frameworks, on the other innovates and plans for the future
+- Docs suggest Express for SSR, but you can swap in something else. Flexible, but not confident.
- Cumbersome for small tasks
- RxJS vs Signals: powerful, but introduces decision fatigue.
* Eyeing Nitro (just as CLI or as a basis for server in SSR? Not clear yet)
Angular feels serious and forward-looing, but a bit behind others & too heavy if the task is supposed to be "easy."
All other frameworks use Nitro for the backend, and that's probably a good sign.
Solid / SolidStart
+ Signals-first: eliminates the useEffect headaches.
- Low adoption, slow iteration
- SSR still feels immature or an afterthought
Clean ideas, but experimental. Not for production-critical projects yet.
Svelte / SvelteKit
- Leaflet didn’t work out of the box
- Stores vs runes, v4 vs v5 — too much churn, not enough stability
- Unclear separation between Svelte and SvelteKit
- Syntax Sugar overload (which is good and useful, but a lot to learn)
- Boilerplates is either a complete demo or too bare bones
- And the magic (+ files, $ syntax, magic types) feels clever until it trips you up. Still immature, but promising.
- Not very clear how to disable SSR on some pages/components
The line itself is clear "export let ssr = false"; but where to put it - isn't:
SvelteKit's documentation specifies that this line should be placed in +layout(.server).js/ts or +page(.server).js/ts files.
But! Attempting to place it directly in a +page.svelte file will result in a warning and the setting will be ignored.
It's too complicated... I don't need a warning, I need a working solution.
I don't want to grep files in my head and decide.
A complete beginner might even interpret this straight and create a "+page(.server).js" file...
Ability to place it in layouts or pages is cool and gives you flexibility, but why can't I place it "directly in +page.svelte?"
I don't really like magic. The + signs in filenames, $ signs, tons of syntax sugar...
Exciting but immature. Makes you fight the framework at the worst times.
Vue/Nuxt:
+ Nuxt/Vue - both offer good boilerplate to start right away
+ Nuxt: Easy CSR opt-out that works: wrap w/ ...
+ Flexible SSR/CSR without the headaches;
+ Bonus: the Leaflet map worked out of the box even with SSR!
+ Nitro / H3 extensibility
+ Vapor Mode = No VDOM, gradual adoption, in Nuxt only for CSR only for now, but it already works!
+ Vue-Router is clear and stable
+ Pinia: cleanest state management I’ve used
+ Template syntax is lean and elegant, but you can drop into JSX if needed.
+ Clear and simple reactivity system that works even with raw vanilla JavaScript
+ Clean looking hooks, no "useEffect" craziness
- Potential loss of reactivity that's hard to debug
- And .value access feels noisy and potential for errors
But compared to the others, these are minor speed bumps.
The most balanced and reliable stack right now. Solid docs, smooth DX, and fast to production.
My Verdict
So, taking on a role of a judge, I pick Vue with or without Nuxt.
React is out JUST on the basis of the lack of VDOM, and it's not its only issue.
It may not matter to you and your project right now.
But what if it grows? The promise of React compiler failed too.
Nuxt's experience and the docs were worse before, but now it improved a lot.
Solid and Svelte are promising but not ready yet. Angular is serious, but too heavy for quick tasks and still plays catch-up.
I’ll reevaluate in 2026 — if they actually mature into something worth trusting and offer value.
And of course, keep an eye open for new frameworks.