Tenets

Original Article ↗ Hacker News Discussion ↗

Svelte’s newly articulated “tenets” — prioritising “good vibes,” HTML-centric design, and “magical, not magic” developer experience — prompt strong reactions about what a frontend framework should optimize for. Supporters praise Svelte (and often SvelteKit) for rekindling joy in web development, fast results, and an approachable mental model compared with React/Next, while critics question vague goals, dislike Svelte’s DSL and reactivity model, and worry about shifting syntax in Svelte 5. The exchange widens into a broader debate over HTML’s suitability as the foundational UI language, the tradeoffs between magic and explicitness, and the value of tightly integrated ecosystems versus pick‑and‑mix toolchains.

Overall Reaction to the Tenets

  • Many appreciate seeing the framework’s philosophy written down; it clarifies why they enjoy (or dislike) using it.
  • Some feel the document is too vague or marketing-like and doesn’t add practical insight, even if they agree with many underlying choices.
  • A few read it as almost an admission that the framework isn’t trying to be “objectively better,” just aligned with its own taste.

“Best Vibes” and Developer Experience

  • Supporters interpret “best vibes” as: intuitive defaults, minimal APIs, few manual optimizations, and a helpful, example-driven community.
  • Critics call “good vibes” content-free: it could justify any tradeoff, every framework claims good DX, and it risks shutting down concrete criticism.

HTML, Templates, and UI Philosophy

  • One camp views HTML as the natural, browser-native way to describe UI; frameworks that stay close to HTML (templates, JSX, Svelte syntax) are seen as easier to reason about and debug.
  • Another camp thinks HTML/DOM is a deeply flawed UI substrate, especially for complex, highly interactive apps, and compares it unfavorably to desktop toolkits, constraint systems, canvas/WebGL, or imperative UIs.
  • Disagreement also appears around “logic in HTML vs HTML in JS,” separation of concerns, and the value of minimal template languages vs full programming languages.

Magic vs Explicitness; Reactivity

  • The “magical, not magic” line resonates with people who want things to feel easy but still understandable.
  • Others complain that previous Svelte reactivity (e.g., $: labels) already felt too magical and confusing.
  • Some argue most React users also don’t understand its internals, so complaints about Svelte “magic” are inconsistent.

Svelte 5 and Runes

  • The new runes system and $props syntax are polarizing:
    • Fans see it as reducing implicit behavior, aligning reactivity more closely with standard JS patterns.
    • Detractors dislike new magic identifiers, feel it diverges from “just JavaScript,” increases cognitive load, and will make Svelte harder to teach; some say they may not adopt Svelte 5.

Comparisons: React, Vue, Next.js, Others

  • Many report Svelte (and often SvelteKit) feels lighter, more productive, and “fun,” especially compared to React/Next.js’s perceived complexity and ecosystem sprawl.
  • Some prefer Vue’s more unified ecosystem and documentation; others find Svelte superior to Vue.
  • There is harsh criticism of recent Next.js directions (App Router, RSC, caching behavior).
  • Alternatives like Astro+Svelte, HTMX plus server-rendered HTML, and classic template systems are mentioned as pleasant, lower-complexity paths.

SvelteKit, Tooling, and Practicalities

  • SvelteKit gets mixed reviews: some like it professionally; others dislike its routing conventions (+page files), backend limitations, and file-structure coupling.
  • Concerns appear about boilerplate for simple projects and about the official site not working on older Safari versions.
  • Lighthouse is discussed as a useful but imperfect metric that can be gamed and shouldn’t be treated as a definitive measure of performance or accessibility.