Hacker News 中文摘要

RSS订阅

你不需要React：用原生JavaScript创建最小化UI库 -- You don't need React: creating a minimal UI library in Vanilla JavaScript

原文链接 | HN讨论 | 2026-08-04 21:52:34

文章摘要

本文探讨了React的核心优势——即时模式UI编程、HTML与JS的结合以及响应式编程模型，并指出这些概念无需庞大库支持，仅用少量代码即可实现类似功能。作者尝试用最小化UI库复现React教程。

文章总结

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的代码示例和具体实现细节。

标题：你不需要 React：创建一个极简的 UI 库

核心观点：

React 是一个优秀的库，它普及了“即时模式”UI 编程的概念，即 UI 是状态的函数。这种方式让我们能用简单的编程结构（如 if 和循环）来构建 UI，而无需关心底层细节。即时模式的主要潜在问题是性能，因为每次状态变化都需要重新渲染整个 UI，但有许多技术可以优化这一点。

除了即时模式，React 的另外两个优点在于它将 HTML 与 JavaScript 紧密结合，以及其响应式编程模型。但作者认为，这三个核心概念并不一定需要一个庞大的库来实现，完全可以用少量代码实现类似功能。本文的目标就是通过创建一个极简的 UI 库，来重现 React 官方教程中的示例。

极简 UI 库的三大核心概念：

  1. 即时模式 UI：UI 是状态的函数。
  2. HTML 与 JS 的结合：不需要新的语法，直接使用常规的 JavaScript 即可完美实现。
  3. 简单的响应式编程模型：一个应用于变量的“发布-订阅”机制，类似于 Solid.js 中的信号（signals）或 RxJS 中的某些概念。

库的实现思路：

  • 创建 DOM 节点：通过一个简单的 DomBuilder 类，封装原生 DOM API，提供更可读的方式来构建复杂的 DOM 结构，例如通过链式调用 attr()、style()、append() 等方法。
  • 实现响应式状态：创建一个 useState 函数，它返回状态的获取器、设置器以及一个用于订阅状态变化的 onChange 方法。当状态更新时，会触发所有已注册的回调函数。
  • 实现即时模式：通过 JavaScript 函数自然地实现。创建一个返回 DomBuilder 对象的渲染函数，并在状态变化时重新调用该函数来更新 UI。

实践示例：

文章通过重现 React 教程中的几个示例来展示该库的用法，包括：

  • 嵌套组件：创建简单的按钮和 App 组件，演示组件组合。
  • 个人资料卡片：模拟从 API 异步获取数据，并在加载和展示状态之间切换。
  • 任务列表：实现一个包含添加、勾选完成状态的任务列表，展示了状态驱动的 UI 更新。
  • 井字棋游戏：实现了完整的游戏逻辑，包括判断胜负、显示状态和重置功能。
  • 带“时间旅行”功能的井字棋：在基础游戏上增加了历史记录，允许用户回溯到任意一步棋，展示了更复杂的状态管理。

结论：

这篇文章旨在证明，我们可以用极少的代码创建一个具备函数式组件、响应式状态和简易 DOM 创建能力的极简 UI 库。这个库本质上是一个类似于 React 的即时模式 UI 库，但代码量小得多。作者表示，虽然这个库在小型项目和个人网站中很有用，但不建议在大型复杂项目中使用。不过，拥有这样一个替代方案仍然是有意义的。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 支持“不需要React”的观点（部分评论认可度高）：

    • 评论8（netdur）：认为该项目具有教育意义，指出许多全栈开发者只会React却不理解其初衷。
    • 评论13（gulugawa）：赞赏该框架，认为React被过度使用，支持替代方案。
    • 评论28（assimpleaspossi）：基于多年经验，认为React过于庞大复杂，不如直接使用Web基础元素。

  2. 反对或质疑“不需要React”的观点（部分评论认可度高）：

    • 评论1（Flavius）：通过井字棋示例，100%确信需要React。
    • 评论3（mythz）：认为最小化UI库会导致应用代码最大化，React/Vue更优。
    • 评论4（hsn915）：批评替代方案缺乏实质性优势，仅因“不是React”而推荐，并指出Preact是更好的轻量选择。
    • 评论6（jakelazaroff）：指出简单替代方案存在缺陷（如输入框文本丢失），无法真正替代React等框架。

  3. 对“即时模式”概念的争议（部分评论认可度高）：

    • 评论2（Oras）：质疑文章将React描述为“即时模式”的准确性。
    • 评论5（wild_egg）：明确反驳，认为React和文中描述的库都属于“保留模式”。
    • 评论30（satnhak）：批评文章对“即时模式”的理解错误，认为React通过依赖数组控制重绘。

  4. 其他替代方案推荐（部分评论认可度高）：

    • 评论7（bryanhogan）：推荐Astro，认为其更适合简单网站。
    • 评论10（afavour）：认为Astro+Preact是完美平衡，复杂功能用Preact，内容型网站用Astro。
    • 评论18（killerstorm）：认为浏览器自带的HTML+CSS+JS已足够，无需额外库。
    • 评论24（css_apologist）：建议直接使用原生JS进行细粒度更新，而非模仿虚拟DOM。

  5. 对React生态的批评（部分评论认可度高）：

    • 评论23（fidotron）：认为React的价值在于限制错误影响范围，但问题在于人们默认使用Next.js等工具链。
    • 评论29（torginus）：批评SPA模式，认为HTML本身就能很好地表示大多数网站结构，React反而使HTML混乱。

平衡性总结： - 支持方强调React被过度使用、增加复杂性，推荐原生方案或轻量替代品。 - 反对方指出简单替代方案存在缺陷，React在大型项目中的价值（如状态管理、团队协作）。 - 争议焦点在于“即时模式”概念的理解，以及替代方案是否真正解决了React的问题。 - 多数评论认可React在某些场景下的必要性，但反对其被滥用。