Framework Merger Timeline: Shopify acquired Remix in 2022, attempted to compete with Vercel's ecosystem through 2023-2024, then merged Remix back into React Router as v7 in 2025.
The React Router v7 announcement turned into a branding nightmare. I had to explain to my team lead why the framework we'd been pushing for suddenly didn't exist as a brand anymore.
What happened: Shopify bought Remix, couldn't make it compete with Vercel's ecosystem, then rolled it back into React Router as v7. The GitHub discussion shows confused developers trying to figure out migration paths and whether they should rebrand their internal docs.
Technically, React Router v7 is just Remix with better React Router integration. But try explaining to procurement why your "stable framework choice" just went through an identity crisis. Our CTO asked me three times if we needed to rewrite everything.
Next.js 15.5: Turbopack Finally Works in Production
Build Performance Improvement: Our 800+ component codebase went from 8-12 minute Webpack builds to 3-4 minute Turbopack builds. Cold starts are ~19% faster according to independent benchmarks.
Next.js 15.5 made Turbopack available for production builds. Been waiting for this since they announced it. Our builds were taking 8-12 minutes with Webpack, now they're down to 3-4 minutes.
Does it actually work? On our 800+ component codebase, yes. Build times improved significantly. Smaller projects (under 100 components) won't see much difference - Webpack already handles those fine.
The bigger win is fewer random build failures. Webpack would occasionally throw Module build failed: ReferenceError: regeneratorRuntime is not defined with no clear fix. Turbopack fails more predictably - when something's broken, the error actually tells you what's broken.
SvelteKit Has Real Scaling Issues
The SvelteKit scaling discussion documents performance problems with large projects. Multiple developers report similar issues:
- Language server crashes requiring VS Code restarts
- Build times increase exponentially with project size
- Memory usage spikes during development
- Hot reload becomes unreliable
I hit performance degradation around 1,200-1,500 components on our dashboard rebuild. The TypeScript language server would crash with out-of-memory errors, and builds went from 30 seconds to 5+ minutes. Had to bump our CI runner memory limits twice.
The fundamental issue is SvelteKit's compilation model. It processes all components for type checking and optimization on every build. This works great for smaller apps but becomes a resource problem as component counts grow.
Teams handling this either architect around smaller component counts, use microfrontends to split the codebase, or allocate engineering time to developer tooling optimization.
API Routes: Where Frameworks Show Their True Colors
Real apps need to handle API calls, auth, webhooks, and WebSocket connections. This is where the performance differences actually matter for your bank account.
SvelteKit API routes need way too many servers to handle decent traffic. Teams end up abandoning SvelteKit's built-in API handling and just use Express because the overhead is ridiculous.
Next.js API routes work fine for moderate loads but struggle with high-frequency operations. You'll end up moving busy endpoints to dedicated services anyway.
Remix/React Router v7 handles server-side stuff better than the others, but good luck planning long-term when the framework just went through an identity crisis.
Enterprise Security: Where SvelteKit Becomes a Nightmare
Enterprise apps need SAML, security headers, audit logging, and all that compliance bullshit. This is where the framework ecosystems really differ:
Next.js has NextAuth.js that handles most auth patterns. Security middleware exists. Someone already solved your compliance problems.
SvelteKit means building everything yourself. Spent weeks writing custom Vite plugins for basic features that exist out-of-the-box in Next.js. The adapter system sucks for custom requirements.
Remix/React Router v7 has decent server-first architecture but the ecosystem reset means you're starting from scratch on integrations.
Pattern: Next.js has solutions that work today. SvelteKit requires building everything yourself. Remix has to rebuild its ecosystem.
The Hiring Reality Check
Framework Adoption Reality: Stack Overflow 2024 survey shows React used by 73% of developers vs Svelte's 14%. When hiring, you'll see 200+ React applications vs maybe 3 with professional Svelte experience.
Good luck hiring Svelte developers. When you post a frontend role you get 200 React applications and maybe 3 people who've used Svelte professionally. This isn't technical - it's business risk.
- React/Next.js: Most developers know this stuff
- Svelte/SvelteKit: Tiny adoption numbers means brutal hiring
- Remix: Nobody knows if they need React Router or Remix skills anymore
The Current Decision Framework
After running this stuff in production for a while:
Choose Next.js when: You need to ship apps, hire developers, and not worry about your framework disappearing. The Vercel lock-in concerns are overblown - Next.js works fine elsewhere.
Choose Remix/React Router v7 when: You control the full stack, understand server-first development, and can handle the uncertainty about what the framework is even called.
Choose SvelteKit when: You're keeping projects under a few thousand components, have dedicated tooling people, and performance matters more than ecosystem.
The reality: Most teams pick Next.js not because it's perfect, but because it's predictable. You know what breaks and how to fix it. That matters more than technical elegance when you're responsible for apps that actually make money.
