Back

选择原生 JavaScript 而非框架的理由

OpenReplay Team OpenReplay Team

Mar 12, 2026 · 2 min read

选择原生 JavaScript 而非框架的理由

大多数前端项目并不需要 React。它们不需要 Vue、Angular 或任何其他框架。它们需要的只是几百行 JavaScript 代码,以及一个在过去十年间已经悄然变得更加强大的浏览器。

这不是一个怀旧论调。这是在提醒我们,许多项目的默认起点仍然可以是平台本身。

核心要点

  • 2026 年的原生 JavaScript 意味着 ES 模块、async/await、Web Components 和一个稳定的 Web 平台——而不是 IE 时代浏览器不一致的环境。
  • 许多常见的前端任务现在可以通过内置的浏览器 API 来处理,而无需框架抽象。
  • 无框架开发非常适合营销网站、服务端渲染应用、嵌入式组件、内部工具以及对包体积敏感的项目。
  • 框架仍然为复杂应用和受益于共享架构的大型团队提供真正的优势。
  • 从平台本身开始,只有当问题的复杂性证明有必要时才引入抽象。

2026 年”原生 JavaScript”的真正含义

今天的原生 JavaScript 与 2010 年代初期的含义大不相同。现代 JavaScript 包括用于组织代码的 ES modules、用于管理异步逻辑的 async/await,以及曾经需要多层工具和库才能实现的原生浏览器特性。

当开发者谈论”使用原生方案”时,他们并不是建议放弃结构化或现代实践。他们的意思是直接使用浏览器能力,而不是将每个交互都通过框架运行时来路由。

在许多情况下,这种方法会产生更简单的架构、更少的依赖,以及多年后仍然易于理解的代码。

Web 平台的能力超出了许多项目的需求

框架之所以占据主导地位,部分原因是浏览器平台曾经缺乏解决常见前端问题的方案。路由、组件封装、DOM 观察和动画通常需要库或自定义抽象。

如今,浏览器提供了更多开箱即用的功能。

开发者可以使用 ES modules 和 import maps 来组织代码,无需打包工具。Web Components 允许创建可重用、封装的元素,可在各种环境中使用。像 Intersection Observer 这样的 API 简化了懒加载和基于滚动行为等任务。

其他更新的能力——如现代导航原语和内置视图过渡——继续减少构建交互界面所需的基础设施量。

换句话说,许多曾经证明需要大型框架的问题,现在都有了平台级的解决方案。

无框架开发最适合的场景

无框架前端开发在界面相对简单且应用逻辑易于理解的项目中特别有效。

常见示例包括:

  • 营销和文档网站 — 主要是静态内容,带有少量交互元素

  • 服务端渲染应用 — 后端框架已经生成了大部分 HTML

  • 嵌入式组件 — 最小化包体积和外部依赖很重要的场景

  • 内部仪表板和工具 — 简单性和可维护性通常比架构复杂性更重要

  • 性能敏感型项目 — 每一千字节的 JavaScript 都会影响加载时间和用户体验

在许多情况下,维护也更简单。浏览器 API 往往能保持多年稳定,而框架生态系统发展迅速,有时在版本之间需要大量的迁移工作。

像 querySelector 这样的方法很少会出问题。相比之下,框架 API 偶尔会出现破坏性变更。

JavaScript 框架仍然有意义的场景

这并不意味着框架已经过时。它们解决了真实的问题。

高度交互的应用——协作编辑器、复杂的数据仪表板,或具有复杂状态流的大型单页应用——通常会受益于框架提供的架构模式。

框架还帮助大型团队保持一致性。当许多开发者为同一代码库做贡献时,用于状态管理、组件结构和路由的共享约定可以显著减少摩擦。

在这些环境中,抽象层不仅有帮助——它可能是必不可少的。

关键问题不是框架是好是坏。而是抽象是否有意义地简化了你试图解决的问题。

实用的决策启发式方法

在添加框架依赖之前,考虑应用状态的复杂性。

如果界面可以用少量响应用户操作而变化的变量来描述,那么纯 JavaScript 和 DOM 更新通常就足够了。

当状态变得深度关联时——多个 UI 区域对相同数据做出反应、组件之间的复杂同步,或界面上的实时更新——框架的抽象开始显现价值。

从平台开始可以让你保持选择的开放性。如果应用的复杂性增长,你随时可以引入框架。

结论

现代 Web 平台功能强大、稳定,并通过 MDN 等资源提供了良好的文档。对于许多项目来说,浏览器已经提供了构建可靠界面所需的原语。

框架仍然是有价值的工具,但它们不再是每个前端项目的自动起点。

在令人惊讶的许多情况下,少量结构良好的 JavaScript——以及浏览器中已经内置的能力——可以带你走得比预期更远。

常见问题

是的。没有框架运行时需要解析和执行,原生 JavaScript 通常比基于框架的等效方案加载和运行得更快。浏览器直接执行你的代码,这通常会为许多类型的应用带来更快的启动时间和更小的包体积。

对于许多项目,状态可以通过纯变量、小型模块、自定义事件或 Proxy 对象来管理。将状态集中在一个简单的模块中,并在值变化时通知组件,对于中小型应用来说通常就足够了。

可以。Web Components 在设计上是框架无关的。用原生 JavaScript 编写的组件可以在 React、Vue、Angular 或其他框架中使用,如果项目后来在复杂性上有所增长的话。

测试和工具的工作方式与基于框架的项目相同。像 Vitest、Playwright 和 Web Test Runner 这样的工具支持原生 JavaScript,而 ESLint 和 Prettier 提供代码检查和格式化。浏览器开发者工具也可以直接使用,无需框架特定的层。

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.

OpenReplay

More articles from OpenReplay Blog