原则
Svelte 新近明确阐述的“原则”——强调“好氛围”、以 HTML 为中心的设计，以及“magical, not magic”的开发者体验——引发了关于前端框架应优化什么的强烈反应。支持者称赞 Svelte（以及通常还包括 SvelteKit）重新点燃了 Web 开发的乐趣、带来快速成果，并相较 React/Next 提供了更易于理解的心智模型；批评者则质疑目标过于模糊，不喜欢 Svelte 的 DSL 和响应式模型，并担心 Svelte 5 的语法变化。这场讨论进一步扩展为一场更广泛的辩论：HTML 是否适合作为基础 UI 语言、魔法与显式性之间的取舍，以及紧密集成的生态系统与可自由拼装的工具链各自的价值。
对这些原则的整体反应
- 许多人很喜欢看到这个框架的理念被写下来；这让他们更清楚自己为什么喜欢（或不喜欢）使用它。
- 有些人觉得这份文档过于含糊或像营销文案，即使他们认同其中许多底层选择，也没有提供实际洞见。
- 少数人把它理解为一种近乎承认：这个框架并不是在追求“客观更好”，而只是与它自身的审美取向一致。
“最佳氛围”和开发者体验
- 支持者将“最佳氛围”理解为：直观的默认值、极简 API、较少的手动优化，以及一个乐于助人、以示例为主的社区。
- 批评者则认为“好氛围”没有实质内容：它可以为任何取舍辩护，每个框架都会声称自己有良好的 DX，而且它有可能压制具体批评。
HTML、模板与 UI 理念
- 一派人把 HTML 视为描述 UI 的自然、浏览器原生方式；那些尽量贴近 HTML 的框架（模板、JSX、Svelte 语法）被认为更容易推理和调试。
- 另一派认为 HTML/DOM 是一个存在深层缺陷的 UI 基底，尤其不适合复杂、高交互的应用，并将其与桌面工具包、约束系统、canvas/WebGL 或命令式 UI 相比，认为后者更优。
- 争论也出现在“HTML 中放逻辑 vs JS 中放 HTML”、关注点分离，以及极简模板语言与完整编程语言之间的价值取舍。
魔法与显式性；响应式
- “magical, not magic” 这句话让那些希望一切既轻松又可理解的人很有共鸣。
- 也有人抱怨之前的 Svelte 响应式机制（例如
$:标签）已经显得过于“魔法化”且令人困惑。 - 还有人认为大多数 React 用户也并不理解其内部机制，所以对 Svelte“魔法”的抱怨前后不一。
Svelte 5 与 runes
- 新的 runes 系统和
$props语法引发分歧：- 支持者认为它减少了隐式行为，让响应式更贴近标准 JS 模式。
- 反对者不喜欢新的魔法标识符，觉得它偏离了“就是 JavaScript”的原则，增加了认知负担，并且会让 Svelte 更难教学；有些人表示他们可能不会采用 Svelte 5。
比较：React、Vue、Next.js 及其他
- 许多人表示，Svelte（以及经常包括 SvelteKit）感觉更轻、更高产，也更“有趣”，尤其是与 React/Next.js 被认为的复杂性和生态膨胀相比。
- 有些人更喜欢 Vue 那种更统一的生态和文档；另一些人则觉得 Svelte 优于 Vue。
- 对 Next.js 近期方向的批评很尖锐（App Router、RSC、缓存行为）。
- 还提到了 Astro+Svelte、HTMX 加服务器渲染 HTML，以及经典模板系统等替代方案，认为它们是令人愉快、复杂度更低的路径。
SvelteKit、工具链与实际问题
- 对 SvelteKit 的评价褒贬不一：有些人从专业角度喜欢它；另一些人不喜欢它的路由约定（
+page文件）、后端限制以及文件结构耦合。 - 也有人担心简单项目所需的样板代码，以及官方网站在较旧 Safari 版本上无法工作。
- Lighthouse 被讨论为一个有用但并不完美的指标：它可以被“刷分”，不应被视为性能或可访问性的决定性衡量标准。