SvelteKit

The framework's dependency graph, build pipeline, and integration points are carrying more load than originally designed for. This root cause manifests as slow LSPs, long builds, dev-server lag, flaky SSR tests, and uneven runtime performance. Fundamental architectural issues rather than individual bugs.

Building for production takes ~10 minutes, and svelte-check adds another ~10 minutes, making it 20+ minutes total. esbuild, swc, and rspack lack good Svelte support, making workarounds difficult. Build times worsen as projects grow.

SvelteKit API endpoints are not performant enough for high-load scenarios (11k RPS required 200 pods just for proxying). Teams forced to write endpoints directly on Node.js server, bypassing SvelteKit entirely.

When generating PrismaClient to a custom location in SvelteKit projects, Prisma produces code with undefined __dirname references, causing build and runtime failures.

Since client-side load functions (`+page.js`) started serializing responses, they cannot be mocked effectively. SSR can cause flaky tests in Playwright when selectors click before hydration completes, causing event handlers to not attach.

SvelteKit feels behind competing frameworks when building real full-stack applications, separate from reactivity/runes concerns. Fundamental platform maturity gap exists.

Even in small SPA-mode projects, the nested folder structure with multiple `+page`, `+layout`, and server-side files creates navigation and discoverability nightmares. Routing files strewn across a million folders makes codebase navigation difficult.