JavaScript 江湖

JavaScript 江湖：这门语言不是设计出来的，是被时代硬推出来的

今天几乎所有前端都在写 JavaScript。

可很少有人会先问一句：

为什么一门据说只花了十天写出来的语言，最后会变成整个 Web 平台最难绕开的底座？

为什么它一开始像浏览器里的一点小把戏，后来却一路扩张到页面交互、异步通信、工程化、服务端、构建工具，最后连很多“现代前端体验”本身，都是围着它转出来的？

为什么这门语言一边总被人嫌语法别扭、历史包袱重、生态混乱，一边又总能在每一次“该不该换掉它”的讨论里活下来，而且活得更大？

这套 《JavaScript 江湖》，想讲的就是这些事。

它不是教程。

也不是“十分钟看完 JS 发展史”的压缩版百科。

它更像一部长剧。

而且是一种特别典型的 Web 长剧：

一开始像权宜之计，中间像兼容灾难，后来像平台引擎，最后又像一整套谁也很难替换掉的生态制度。

你可以把这套系列先记成六个镜头：

  1. 1995 年，Netscape 急着要一门脚本语言，时间紧到几乎不允许精雕细刻。
  2. 1996 年，微软推出 JScript，浏览器大战很快把“网页脚本”打成兼容性战场。
  3. 1997 年，ECMAScript 出现，它更像一份防止彻底分裂的停火协议。
  4. 2005 年前后，Ajax 让 JavaScript 从页面补丁变成 Web 应用的发动机。
  5. 2008 到 2009 年，V8 和 Node.js 让 JavaScript 不再只属于浏览器。
  6. 2015 年，ES6 终于让很多人第一次觉得：现代 JavaScript 真的成形了。

这六幕一连起来，你会发现这套系列真正想讲的，不是某些语法什么时候加进标准。

而是另一件更大的事：

JavaScript 的历史，不是一门语言如何稳步升级的历史，而是一门仓促诞生的脚本语言，如何在浏览器战争、标准补救、网页应用化和工具链救火中，被一路硬推成现代平台语言的历史。

这套系列讲什么

我想讲的，不只是“某个特性哪年发布”，而是更底下那几场反复重演的冲突：

  • 为什么 JavaScript 一开始更像市场时机的产物，而不像一门经过长期设计的语言
  • 浏览器大战为什么会把它从“网页增强脚本”打成一堆宿主差异和兼容烂账
  • ECMAScript 为什么看起来像标准，其实先是一种止血机制
  • Ajax、jQuery、浏览器引擎性能战，为什么会把 JavaScript 推到 Web 舞台中央
  • Node.js 为什么不是简单“让 JS 跑到服务端”，而是把它送进了新的权力中心
  • 为什么今天很多人所谓的“现代 JavaScript”，其实是 ES6 + Babel + bundler + npm + TypeScript 一起托起来的

换句话说，这是一套关于 JavaScript 标准史、浏览器权力史、前端平台化，以及现代工具链现实逻辑 的系列文章。

这套系列真正要追的，不是语法，是冲突

如果你退一步看，会发现 JavaScript 这些年的很多争论，表面上主角不同，底下却一直在重复几类老问题。

01｜仓促诞生，还是注定短命

JavaScript 最传奇的一层出身，就是它经常被概括成一句话：

十天写出来。

这句话当然容易制造戏剧感。

可真正值得追问的，不是“它写得快不快”，而是：

为什么这样一门明显带着时间压力和市场妥协痕迹的语言，没有很快被更正规、更整洁、更学院派的替代品淘汰？

这里面有市场窗口，有浏览器分发能力，也有 Web 平台最残酷的一条规律：

先上车的东西，往往比更完美的后来者更容易活成既成事实。

02｜一门语言，还是浏览器大战的附属品

很多人今天学 JavaScript，会天然把它看成一门语言。

可在很长一段时间里，开发者真正面对的并不只是“语言本体”。

他们面对的是一整个混在一起的东西：

  • JavaScript 语法
  • 浏览器对象模型
  • 事件差异
  • DOM 差异
  • 厂商私货

于是 JavaScript 的早期体验，常常不像“写一门统一语言”。

更像：

在不同浏览器的地盘上，分别和不同脾气的宿主环境谈条件。

所以这套系列里一个很重要的问题就是：

JavaScript 到底从什么时候开始，才逐渐不只是浏览器大战里的附属脚本，而是一门相对独立、可治理、可现代化的公共语言？

03｜页面补丁，还是平台核心

JavaScript 最早并不是以“Web 应用主引擎”的身份出现的。

它起初更像一门小脚本语言：

  • 做点表单校验
  • 回应一下用户操作
  • 给静态页面加几分活气

可后来 Web 自己变了。

网页越来越不像文档。

而越来越像：

  • 应用界面
  • 状态容器
  • 在线服务前台
  • 商业系统入口

一旦 Web 开始往应用平台方向长，JavaScript 的位置就不再只是“可有可无的点缀层”。

它会被推到一个更危险也更重要的位置：

用户交互要靠它，异步通信要靠它，复杂状态要靠它，页面体验升级也要靠它。

也就是说，这套系列还会反复追问：

不是 JavaScript 自己有多大野心，而是 Web 平台后来还有谁能接这份活。

04｜标准在设计未来，还是在给现实止血

很多技术标准的理想状态是：

先设计一个更好的未来，再慢慢推动大家跟上。

可 JavaScript 的标准化，很多时候并没有这么从容。

ECMAScript 最早出现时，一个非常现实的任务就是：

别让浏览器厂商把这门语言彻底打成几套互不相认的方言。

后来的 ES4 风波，更把这条线暴露得特别明显。

它让社区不得不重新回答一个非常关键的问题：

JavaScript 的现代化，到底应该靠一次激进重写，还是靠一套不把旧世界炸掉的渐进演化？

05｜语言本体，还是生态外骨骼

今天很多开发者口中的“JavaScript”，其实已经不是单指语言本身。

它往往还包括：

  • npm
  • Node.js
  • Babel
  • bundler
  • TypeScript
  • lint / test / build 整套工具链

这会带来一个特别现代、也特别别扭的问题：

你今天在用的，到底是 JavaScript 这门语言，还是一整个围着它长出来的外骨骼系统？

很多现代 JavaScript 的能力感，并不是只靠标准正文给你的。

它更像语言、运行时、包管理器、转译器、工程化实践一起托出来的结果。

所以到后面你会越来越明显地看到：

JavaScript 的历史，不只是语言史。

它也是一部生态基础设施如何反过来塑造语言现实的历史。

为什么今天的开发者还得关心这些旧账

因为你今天面对的，其实不只是几条语法规则。

你面对的是一整套由 JavaScript 历史塑造出来的开发现实。

比如：

  • 为什么前端圈总会对“兼容性”和“迁移成本”特别敏感
  • 为什么很多语言能力要靠工具链提前普及，而不是等浏览器一步到位
  • 为什么“官方标准”和“社区实际工作流”之间经常会有时间差
  • 为什么 JavaScript 能一边被嫌弃，一边又总是更难被替代
  • 为什么现代前端复杂度看起来像突然爆炸，其实很多根都埋在十几二十年前

如果不看这些过程，你就很容易把今天的 JavaScript 误会成一套天然如此、理所当然会长成现在这样的东西。

它不是。

它更像一座先搭起来、再不停加层、边住边修、还不能停业的大楼：

  • 有的楼层，最初只是临时加建，后来却成了承重结构
  • 有的管线，明知道别扭，却因为整栋楼都绕着它走，谁也不敢硬拆
  • 有的扩建，本来只是应急方案，最后反而定义了新的日常

看懂这些，你回头再看 JavaScript，就会更明白：

它很多让人皱眉的地方，不只是“设计不够好”，而是“历史已经把它推到了一个不能轻易重来的位置”。

推荐阅读顺序

01｜JavaScript 江湖（一）：十天写出来的语言，为什么最后活成了整个 Web 的底座

从 1995 年那场仓促诞生讲起。看懂这篇，你会知道：JavaScript 最初的成功，并不是因为它足够完美，而是因为它刚好踩中了 Web 爆炸前夜的入口位置。

02｜JavaScript 江湖（二）：标准还没定，浏览器大战已经把它打成两门话

Netscape 和微软怎么把“网页脚本”迅速打成兼容性灾区，这里会把很多人对早年 JS 的痛苦记忆串起来。

03｜JavaScript 江湖（三）：ECMAScript 不是加冕礼，更像浏览器大战中的停火协议

这篇会回答一个很容易被忽略的问题：为什么 JavaScript 要先靠一份标准止血，才能谈得上后来的现代化。

04｜JavaScript 江湖（四）：一门语言差点把自己重写过头，ES4 为什么最后夭折

这是整套系列里最像路线斗争片的一篇。它讲的是：JavaScript 后来为什么宁可慢，也不愿再赌一次“重写式现代化”。

05｜JavaScript 江湖（五）：Ajax 之后，JavaScript 从页面补丁变成了应用引擎

从这里开始，JavaScript 的身份就不再只是网页配角，而是 Web 应用化真正的发动机。

06｜JavaScript 江湖（六）：V8、JIT 和 Chrome，为什么让 JavaScript 从能用变成必须认真对待

这篇讲的是性能战争。没有这轮引擎竞赛，后面的 Node、工程化和“JS 万能感”都很难长成今天这样。

07｜JavaScript 江湖（七）：Node.js 不是换个运行时，它把 JavaScript 送进了新的权力中心

从浏览器脚本走到服务端、CLI、构建链，JavaScript 真正开始接管基础设施，是从这里起势的。

08｜JavaScript 江湖（八）：JavaScript 真正长成现代模样，不是在 1995，而是在 ES6

收束篇。最后会回到一个更现实的判断上：现代 JavaScript 不是靠推翻旧世界获得的，而是靠标准、实现和工具链一起把旧世界慢慢拧成新日常。

如果你只想先读三篇

可以先看这三篇：

  1. 第一篇：看 JavaScript 为什么能在一开始活下来
  2. 第四篇：看 ES4 为什么把整个社区吓出治理阴影
  3. 第七篇：看 Node.js 为什么把这门语言从浏览器送进基础设施

这三篇能最快把这套系列的味道读出来。

为什么想写这套

因为今天很多开发者对 JavaScript 的印象，其实也大多只是结果，不是过程。

大家知道：

  • JavaScript 到处都是
  • npm 很大
  • 工具链很重
  • ES6 之后现代语法顺手很多
  • TypeScript 已经几乎成了默认配置

可并不知道这些东西背后：

  • 为什么一门脚本语言会变成平台中枢
  • 为什么标准化过程会和浏览器战争绑得这么紧
  • 为什么现代 JS 的现实，很多时候是工具链先于标准普及
  • 为什么前端工程化最后会重到像另一层运行时

而我一直觉得，如果不看这些过程，你就很容易把今天的 JavaScript 误会成“它本来就这么大、这么乱、也这么强”。

它不是。

它更像 Web 世界里最典型的一种既成事实：

  • 先因为现实需要被快速做出来
  • 再因为市场扩张被硬性普及
  • 后来靠标准补救和生态外设，一点点长成今天这个样子

看懂它，某种程度上也就是在看懂：

现代前端为什么会越来越不像单纯写页面，而越来越像在经营一整套不断膨胀的平台秩序。

先记住：JavaScript 的很多怪，都是替整个 Web 扛下来的旧账

如果你平时把 JavaScript 当工具，这套系列也许能让你第一次把它当成一段活历史来看。

如果你平时嫌 JavaScript 太怪、太旧、太杂，这套系列也许会让你稍微理解它一点。

因为你会发现：

JavaScript 最让人抓狂的地方，很多不是因为它单纯设计得差，而是因为它活得太久、接得太多，最后不得不替整个 Web 扛下太多历史。

关键人物速览

  • Brendan Eich：JavaScript 的直接创造者。理解这门语言为何带着明显的时间压力和设计混血痕迹，绕不开他。
  • Marc Andreessen：Netscape 的关键人物之一。JavaScript 最初为何以那种速度和姿态进入浏览器，和他的市场判断高度相关。
  • Douglas Crockford：早期 JavaScript 传播与规范讨论中的重要声音。很多关于“语言该怎么自我解释”的舆论线索，都能从他身上接出来。
  • Allen Wirfs-Brock：ECMAScript 标准化过程中的关键人物之一。理解 ES4 到 Harmony 再到现代 TC39 的治理转向时，他很重要。
  • Ryan Dahl：Node.js 的发起者。JavaScript 逃出浏览器、进入基础设施地带，这条线离不开他。

参考与延伸阅读

  1. JavaScript: The First 20 Years
    https://dl.acm.org/doi/10.1145/3386327

  2. ECMAScript Language Specification
    https://tc39.es/ecma262/

  3. A Brief History of JavaScript
    https://brendaneich.com/2008/04/popularity/

  4. Node.js: The Documentary - Rise of JavaScript
    https://www.youtube.com/watch?v=LB8KwiiUGy0

  5. V8 Blog
    https://v8.dev/blog