Svelte

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.

The Svelte Language Server Protocol takes ~1 minute to initialize, causes IDE freezing, and runs out of RAM in some cases. Autocomplete is very slow or non-functional for both markup props and script tags. Affects VS Code, WebStorm, Neovim, and Zed.

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.

Official flavor variants like Pure JS and Svelte JS do not work without modifications despite being officially supported, forcing developers to debug and fix setup issues before starting development.

Some frameworks push proprietary patterns and abstract so much from developers that migrating to another framework or stack becomes prohibitively expensive. This creates vendor lock-in and limits architectural flexibility.

Svelte has significantly fewer libraries than React, forcing developers to build custom solutions or use workarounds for common needs like advanced form handling, markdown rendering, and LLM integration. Third-party packages sometimes break when used with Svelte.

Svelte's reactive blocks have a limitation where they only run once per tick. If a dependency changes after a block has already run in that tick, the block won't run again, which breaks expected behavior and creates unintuitive side effects for use cases like transitions.

v0 strictly outputs React components and Next.js-compatible code only, forcing developers using Angular, Vue, Svelte, or other frameworks to perform extensive code conversion. The tool also mandates Tailwind CSS and doesn't generate TypeScript by default.

Developers often fail to properly handle component lifecycle events in Svelte, particularly failing to unsubscribe from stores or clean up side effects in onDestroy, leading to memory leaks.

Svelte's runes-based reactivity system works well for basic use cases but becomes problematic in complex scenarios with multiple reactive dependencies. Developers need to use getters and setters to pass reactive variables into functions, creating unintuitive patterns when combining features like signals with effects and derived state.

Svelte requires developers to reassign arrays/objects rather than mutate them in-place to trigger reactivity. In-place mutations silently fail to update the UI, creating a non-obvious reactivity trap that violates typical JavaScript patterns.

Large monolithic codebases cannot migrate to Svelte 5 without freezing development. Only microfrontends (from monolith decomposition) have been able to adopt Svelte 5 without issues.

Svelte doesn't support publishing pre-compiled component libraries, forcing all components (e.g., 2,000 icons in a UI kit) to recompile every time a consuming app builds. Creates unnecessary overhead.

Svelte moves complexity from runtime to buildtime, requiring a heavy compiler toolchain. Unlike Vue which can be dropped into webpages directly, Svelte requires a build step heavier than React's JSX, and the browser-bundled compiler weighs 870k, making it unviable for normal application code.

Svelte lacks comprehensive debugging capabilities and IDE support comparable to React or Angular. While the Svelte compiler is fast, it doesn't offer the same level of debugging features, making it harder for developers to identify and fix issues in their code.

Svelte's file-based component model forces one component per file, leading to excessive file proliferation and fragmented state management. Developers must maintain separate files for components and their state logic, reducing colocation and code organization flexibility.

Components don't update as expected due to missed reactivity triggers. Managing shared state is harder than in other frameworks. Root causes of bugs are hidden in how Svelte's reactivity system interprets code, leading to increased development time and harder debugging.

Developers migrating from React struggle with Svelte's different mental model. Features like top-level awaits and reactive blocks ($: syntax) feel 'loose' compared to React's function-first approach, creating learning friction and potential debugging issues from nested reactive declarations.

The Svelte community is small and often unhelpful to beginners. Community members don't share code snippets, take time to help debug problems, provide proper guidance, and sometimes behave hostilely toward newcomers.

Svelte may never be able to implement an equivalent of React's concurrent mode, which could be a significant limitation. While Rich Harris intends to implement Suspense equivalents, there's no guarantee Svelte can achieve React's concurrent capabilities.

Tailwind's philosophy discourages reusable classes, leading to repetition of identical utility class combinations across similar elements (buttons, links, headings, inputs). Avoiding duplication requires using component frameworks like React, Svelte, or Astro—not practical for simple static HTML projects like landing pages.

Svelte's direct DOM manipulation doesn't enforce semantic HTML or accessibility best practices by default. Developers must manually audit with tools like axe-core and implement accessibility features like form enhancements.

Svelte's transition API makes animations easy but chaining multiple transitions causes performance jank. Developers must profile animations carefully to avoid reintroducing the performance problems that Svelte claims to solve.

Using client-only APIs (like browser globals) in SSR contexts causes runtime errors. Developers must manually guard code with environment checks like `browser` from `$app/environment`, adding boilerplate.

Official Svelte documentation is not tailored for beginners despite beginners being the primary target audience (senior developers already use React, Vue, Angular). Documentation should be reframed as 'JavaScript for beginners and dummies'.

Svelte 5's new prop syntax requires typing prop names multiple times (similar to TypeScript in React), breaking the elegance of Svelte 3 where prop names only had to be typed once. The syntax $props<boolean>(true) is verbose and feels unnecessarily complex.

Developers write more type assertions and struggle with IDE support for TypeScript in Svelte files. Less robust type checking for component props leads to potential runtime errors that could have been caught at compile-time.

Advanced development tools, debugging utilities, and testing frameworks are less mature for Svelte. Browser DevTools extensions are less feature-rich. Testing libraries lack maturity and thorough documentation compared to React Testing Library.

Svelte stores require a $ prefix to access reactive values; forgetting it reads a snapshot instead of live values, creating a subtle correctness bug that's easy to miss during development.

Each Svelte component generates its own runtime code. In applications with many small components, this results in larger bundle sizes compared to runtime-based frameworks. Reactivity system can cause unnecessary updates in complex scenarios.

Svelte is its own language and not plain HTML+CSS+JS, which increases the risks of adoption. Developers must learn Svelte-specific syntax rather than using standard web technologies.