为什么选择 Vanilla JavaScript

【HN用户评论摘要】 还有更多问题得到解决……这些问题并未“解决”。作者有一个解决方案的实现。他们认为这是好的，这是王牌，我为他感到高兴，但如果他向他的项目引入第二个开发人员，那么这些“已解决”的问题将成为摩擦点。他们将从“已解决”变为“已解决，但方式错误”或“已解决，但不适用于这种边缘情况”，或“已解决，但为什么代码如此冗长？”框架的巨大优势在于， 在用 vanilla JS 完成我的第一个 SPA 后，我使用 Svelte 5（不带 SvelteKit）作为我的 SPA。然后我发现了 Svelte。 Svelte 非常接近该平台，并且仍然解决了很多问题：反应性、模块化和 CSS 级联（在版本 5 中它并不太“神奇”）。本文中的许多对框架的批评并不适用于 Svelte。 将 UI 框架标记为人为复杂性只是缺乏经验的表现，表现为 NIH 综合症。普通方法对于个人或玩具项目来说很好，但对于具有中等复杂 UI 的项目来说却是一场彻底的灾难。最终，普通项目成为自己的定制 UI 框架，带有一堆糟糕的设计选择，因为所有被视为“人为”的复杂性最终都通过使用 rube-goldberg-machine 架构方法来修补。 > 反应性的想法来自 Angular.js 或由 Angular.js 普及。不，电子表格普及了反应性。而且总体观点非常薄弱。不使用框架并制作自己的框架吗？当然，祝你玩得开心。但是，尝试向拥有 1000 人的公司传授你的框架，看看你有多快意识到你对“问题”的看法只是其中的一小部分。 我很欣赏这种情绪，但不能完全同意。在 AngularJS 出现之前，我已经使用了 vanilla JS 多年（当 AngulasJS 还是个新事物时，我也尝试过它）。对于大型、复杂的视图，Vue 比原始 JavaScript 带来了巨大的便利。当然，我无法直接进行 DOM 操作，但是当我编写 C 代码时，我也无法选择哪个变量进入哪个 CPU 寄存器。我接受放弃 ASM 给予我的控制权，尽管 C 在此基础上带来了所有改进，即使 C 原始链接：https://guusen.com/html/posts/why-vanilla-js.html