原生JavaScript能替代React吗？什么场景不必用React？

图 0：原生 JavaScript 与 React 框架的技术选型天平

一、技术可行性与心智模型差异

讨论“原生 JavaScript 能否替代 React”时，首先需要厘清一个底层事实：浏览器原生环境只认识 HTML、CSS 和 JavaScript，并不存在名为 React 的原生虚拟机。React 的所有 JSX 语法、虚拟 DOM（Virtual DOM）比对以及 Fiber 架构调度，最终都会被转译为标准的原生 DOM API（如 document.createElement、addEventListener、replaceChild 等）执行。因此，从功能实现极限来看，不存在任何 React 能实现而原生 JavaScript 做不到的界面功能。

然而，二者在开发心智模型上存在本质区别：

• 原生 JavaScript 采用“命令式”模型：开发者需要逐步指示浏览器“怎么做”。例如：监听到点击事件后，先通过选择器查找到具体的 DOM 节点，再手动修改该节点的文本、样式类或属性。当页面逻辑简单时，这种直连路径性能最高、开销最小；但当多个按钮或组件共用同一批数据时，手动同步所有 DOM 节点极易出现遗漏或状态不一致。
• React 采用“声明式”模型：开发者只需要描述“界面应该长成什么样”（即 UI = f(state)）。当数据状态发生变更时，React 负责在内存中比对新旧虚拟 DOM 树，自动找出需要修改的最小 DOM 集合并批量更新。这极大地减轻了人工维护 DOM 同步的负担。

图 1：原生命令式更新与 React 声明式更新机制对比

从图 1 可以看出，React 的声明式优势是以引入一层额外的运行时计算（VDOM Diff）以及约 40KB~50KB（gzip 后）的核心库体积为代价换来的。如果一个业务页面的状态交互非常直接，这个抽象层不仅无法带来开发效率的提升，反而增加了加载延迟。

二、原生 JavaScript 构建交互组件的规范步骤

许多开发者之所以觉得原生 JavaScript 难以维护，是因为常常把“数据状态”与“DOM 节点”混为一谈，习惯将临时变量直接挂在 DOM 的 dataset 或文本内容中，导致代码迅速演变为相互耦合的“面条代码”。只要遵循以下四个标准步骤，原生 JavaScript 同样可以写出结构清晰、职责分离的轻量组件。

图 2：原生 JavaScript 构建轻量状态组件的四步操作流程

完整代码示例：原生待办计数器组件

以下示例展示如何在不引入任何构建工具的情况下，在单个 HTML 文件内按照上述四步实现一个高内聚的交互卡片：

<!-- HTML 挂载容器 -->
<div id="counter-app"></div>

<script>
(function () {
  // 步骤 1：状态集中化定义
  const state = {
    count: 0,
    items: ['阅读技术规范', '整理组件逻辑']
  };

  const container = document.getElementById('counter-app');

  // 步骤 2：纯函数式模板渲染
  function renderTemplate(s) {
    return `
      <div style="border: 1px solid #D9D9D6; padding: 16px; border-radius: 8px; background: #FFF;">
        <h4 style="margin: 0 0 10px 0; color: #2C3E50;">原生任务看板</h4>
        <p>当前任务总数：<strong data-role="count">${s.items.length}</strong></p>
        <ul style="margin: 10px 0 16px 20px;">
          ${s.items.map((item, idx) => `
            <li>
              ${item} 
              <button data-action="delete" data-index="${idx}" style="margin-left: 8px;">删除</button>
            </li>
          `).join('')}
        </ul>
        <input type="text" data-role="input" placeholder="输入新任务内容" />
        <button data-action="add">添加任务</button>
      </div>
    `;
  }

  // 渲染并挂载初始界面
  function render() {
    container.innerHTML = renderTemplate(state);
  }

  // 步骤 3：容器层统一事件委托
  container.addEventListener('click', (e) => {
    const target = e.target;
    const action = target.getAttribute('data-action');
    if (!action) return;

    if (action === 'add') {
      const input = container.querySelector('[data-role="input"]');
      const val = input.value.trim();
      if (val) {
        state.items.push(val);
        input.value = '';
        scheduleUpdate(); // 触发更新
      }
    } else if (action === 'delete') {
      const index = parseInt(target.getAttribute('data-index'), 10);
      state.items.splice(index, 1);
      scheduleUpdate(); // 触发更新
    }
  });

  // 步骤 4：基于微任务的批量更新机制
  let updatePending = false;
  function scheduleUpdate() {
    if (updatePending) return;
    updatePending = true;
    queueMicrotask(() => {
      render();
      updatePending = false;
    });
  }

  // 初始化执行
  render();
})();
</script>

三、复杂度分水岭：原生 JS 的适用边界

原生 JavaScript 的优势在于“启动成本为零，链路极短”，但随着项目规模的扩大，它的维护成本会呈非线性加速上升。

当遇到以下情况时，原生代码的复杂度会迎来急剧扩大的拐点：

1. 状态跨层级共享：A 组件的状态变化需要通知同级的 B、C 组件，以及深层嵌套的 D 组件。原生方式通常需要手动派发自定义事件（CustomEvent）或维护全局总线，调试时很难追踪到底是谁修改了数据。
2. 高频局部局部 DOM 细粒度修补：当列表达到成千上万行时，使用 innerHTML 全量重建会导致正在聚焦的输入框失焦、滚动条位置跳动以及动画中断；而若为每个字段手动编写细粒度的修改指令，代码量将呈几何级暴增。
3. 多人团队协作契约：原生 JavaScript 缺乏统一的组件封装规范，团队成员容易各按各的方式组织代码，缺乏统一的生命周期与响应式约束。

图 3：应用复杂度与维护成本演进曲线

如图 3 所示，在横轴左侧的低复杂度区间，原生 JavaScript 的成本线明显低于 React（无需安装庞大的 npm 依赖，无需配置 Webpack/Vite，无需处理 JSX 编译）；两条曲线相交的临界点之后，React 的标准化组件模型才显现出更持久的边际收益。

四、什么场景明确不必用 React？

在实际项目评估中，如果符合以下五类场景，完全无需引入 React，采用原生 JavaScript 不仅开发更加顺畅，运行效果也更佳。

五、选型决策指南与判断清单

在面临框架技术选型时，可以通过以下四个具体问题快速得出判定结果：

图 4：前端技术选型决策树与场景总结矩阵

• 问题 1：页面上是否存在频繁联动的“跨组件状态”？
  如果一个输入框的内容需要即时影响侧边栏、顶部导航、底栏状态等多个分离节点，优先考虑 React；如果仅仅是当前区块内部自闭环操作，原生 JavaScript 更加干净直接。
• 问题 2：首屏性能与网络体积预算是否卡得很紧？
  在弱网环境、移动端 H5 投放页面中，数百 KB 的 JavaScript 往往意味着可观的用户流失率。在此类严苛预算下，原生是最佳选择。
• 问题 3：项目是否需要大量现成复杂的 UI 组件？
  如果业务需要成熟的树形选择器（TreeSelect）、虚拟滚动长列表、可拖拽复杂表格等，React 拥有庞大成熟的生态圈（如 Ant Design、MUI），自研成本极高；若只是一般按钮、弹窗和列表，原生即可快速完成。
• 问题 4：团队人员流动性与维护周期如何？
  如果团队规模较大且长期维护大型核心产品，React 提供的组件规范能有效降低交接认知负担；但对于单人负责或小团队的轻量页面，原生反而避免了框架版本升级带来的维护折腾。

六、实践中的两个典型认知误区

在权衡原生与 React 时，开发者容易走向两个极端误区：

总结而言，原生 JavaScript 完全具备替代 React 的技术实力，但框架的价值在于降低大规模协同下的状态维护复杂度。当你的业务场景不承受这种复杂度时，果断卸下框架的重担，拥抱轻快、纯粹的原生能力，往往是更明智、更高效的工程选择。