Svelte 5 is not JavaScript

Original Article ↗ Hacker News Discussion ↗

Reactions to Svelte 5 and Runes

  • Many early Svelte users feel Svelte 5 lost its “just HTML/JS” simplicity; runes, proxies, and getter-based props make it feel “not JavaScript” and closer to React/Solid.
  • Others, especially those on large Svelte apps, report big improvements: fewer accidental reactivity traps, clearer data flow, and better multi-file/TS ergonomics.
  • Some see Svelte 5 converging toward Vue 3’s Composition API and signals rather than React, and are happy to pay a bit more boilerplate for clarity.

Simplicity vs Complexity & Project Scale

  • One camp laments the loss of a mainstream “simple SPA framework” for small/medium apps; they feel React/Vue/Svelte all now target complex apps.
  • Another camp argues the added complexity is necessary for scaling large codebases, testability, and fine-grained reactivity.

Ecosystem Churn and Upgrades

  • Several comments broaden the complaint to the JS ecosystem: frequent breaking changes, short support windows, and “fashion-driven” rewrites.
  • Others push back: major-version churn exists in all ecosystems; Svelte 4 remains usable; React’s core API has been relatively stable; semantic versioning inflates major numbers without implying rewrites.
  • Security/support lifetimes vs. “just don’t upgrade” is debated; some propose forking old versions when only dependency patches are needed.

State Management and Reactivity Models

  • Opinions diverge on observables/signals/deep reactivity:
    • Critics say proxy-based deep reactivity is leaky, surprising (e.g., IndexedDB serialization issues), and harder to reason about than explicit stores.
    • Fans like that runes/composables move logic out of components, make unit-testing of reactive logic easier, and enable framework-independent reuse.
  • Some insist state management is “trivial” and frameworks overcomplicate it; others counter that real-world SPAs make it one of the hardest front-end concerns.

Alternatives and Architectural Preferences

  • Alternatives championed: SolidJS (seen as “what Svelte 5 should have been”), Vue 3, Mithril, Ember (praised for long-term API stability), Knockout-era stacks, Lit, web components, HTMX + Alpine, and server-driven/SSR–RPC frameworks (Next, SolidStart, SvelteKit, etc.).
  • A recurring theme: pick tools that match app complexity—HTMX/MPA for CRUD and forms; SPA frameworks when rich client-side state is essential.

Testing, Tooling, and Lock‑in

  • Some praise Svelte 5’s ability to encapsulate reactivity in plain TS/JS modules and test them directly.
  • Others worry that runes “infect” all code, deepen lock-in, and require strong editor tooling (largely VS Code–centric) to stay manageable.