Svelte’s characteristics that likely contribute most to improved performance

Original Article ↗ Hacker News Discussion ↗

Benchmark recency and methodology

  • Thread notes the article is based on a 2022 paper using React 17, Svelte 3, Angular 11, and old Vue/Blazor versions, making its conclusions dated.
  • People point to newer JS framework benchmarks showing different leaders and improvements (e.g., Angular with zoneless and signals, Vue 3.4, Svelte 5).
  • Missing frameworks (Solid, newer WASM frameworks) and calling Blazor a “JS framework” are criticized as conceptual errors.
  • Some conclude there’s little to learn from the study given version drift.

How meaningful are performance benchmarks?

  • Many are tired of microbenchmarks (e.g., rendering 25k rows) that don’t resemble real apps where you’d virtualize lists.
  • Argument: all major frameworks are “fast enough” for almost all use cases; bigger UX problems are latency, loading states, flicker, scroll loss.
  • Others defend benchmarks as still useful for understanding tradeoffs, even if nobody would migrate frameworks just for speed.
  • Examples cited of frameworks tackling UX-level issues: React’s async APIs (startTransition, suspense), Vue transitions, Phoenix LiveView, sync-engine-based architectures.

Churn vs stability in the JS ecosystem

  • Strong frustration with constant rewrites: Silverlight→AngularJS→Vue, legacy PHP frameworks, shifting .NET UI stacks, old projects breaking on new runtimes.
  • Some argue React’s core has been relatively stable for years; Vue is praised for low churn and a cohesive ecosystem.
  • Others counter that build tools, meta-frameworks (Next, SvelteKit), and dependency breakage still create high operational churn.

Svelte’s design, runes, and SvelteKit

  • Clarification: the article describes Svelte 3’s compile-time reactivity; Svelte 5 now uses signals/runes (runtime-based with some compile-time sugar).
  • Supporters say runes solve real complexity problems and remain ergonomic; detractors feel they destroy Svelte’s “vanilla HTML/JS” feel and make it more React-like, prompting some to switch away.
  • SvelteKit draws mixed reactions: some love Svelte overall; others find Kit overengineered, with confusing “magic” file/folder-based routing.

Adoption, ecosystem, and enterprise use

  • Consensus: Svelte is established but far behind React/Vue/Angular in jobs and ecosystem breadth.
  • One enterprise developer claims Svelte encourages unreadable “wild west” code and is unsuitable for serious products; others with large-app experience strongly disagree.
  • Several comments stress that in big organizations, coordination, stability, and shared tooling often matter more than shaving milliseconds off rendering.

Reactivity models and why Svelte can be fast

  • Svelte’s advantage is seen as compiling declarative templates into targeted imperative DOM updates, while React does more work at runtime via vDOM and many allocations.
  • Newer frameworks (Svelte 5, Solid, modern Vue) converge on signal-based reactivity with fine-grained updates; React is adding a compiler and signals-like concepts but remains architecturally different.

Alternatives and broader reflections

  • Some prefer vanilla JS + web components/htmx/alpine, arguing that frameworks and their churn cause more rewrites than they save. Others counter that large apps inevitably grow internal frameworks anyway.
  • WASM frameworks (e.g., Rust-based) are cited as capable of near-vanilla performance; Blazor’s slowness is seen as implementation-specific, not inherent to WASM.
  • Several long-timers describe frontend as decades of rearranging abstractions over an inherently complex, distributed, backward-compatible platform, with no consensus “final form” yet.