01｜这场事故最可怕的地方，不是提案太大，而是整门语言差点在现代化时把自己谈崩
前面第三篇讲到 ECMAScript 更像停火协议。
它先把语言核心拉回一张桌子，至少让 JavaScript 不至于继续被浏览器大战打成碎片。
可停火之后，新的问题立刻就来了。
而且是一个任何活下来的语言迟早都得面对的问题：
你接下来怎么变。
到这一步，JavaScript 已经不是刚出生时那个仓促脚本了。
它已经活下来了。
也已经有了一批真正依赖它的人。
那下一步自然会有人问：
- 这门语言能不能更现代一点
- 能不能把早年那些别扭之处系统性补掉
- 能不能支持更大规模、更复杂、更像“真正程序”的开发方式
这些问题本身一点都不奇怪。
奇怪的是，JavaScript 第一次认真回答这些问题时，差点把自己整个标准过程谈崩。
这就是第四篇真正要讲的东西。
不是“ES4 加过哪些特性”。
而是：
一门语言第一次试图大规模重写自己时，为什么最后没有迎来新生，反而先迎来了一场治理事故。
02｜ES4 最初打动人的地方，恰恰在于它不是小修小补，而是想一次把很多旧账重做
今天很多人一听 ES4，第一反应是：
“哦，那个失败的大版本。”
这当然没错。
可如果只记住“失败”，你就会低估它当年为什么那么有吸引力。
因为 ES4 最迷人的地方，恰恰在于它不像一轮小修小补。
它更像一次正式宣言：
JavaScript 不想再只当一门凑合能用的网页脚本了。
这一阶段里，委员会里相当多人真心觉得，这门语言已经到了必须大改的时候。
理由也不难理解。
因为当时的 Web 已经在变：
- 脚本越来越重
- 应用越来越复杂
- 作者对工程组织能力的期待越来越高
- Flash / ActionScript 那边也在给压力
也就是说，JavaScript 面对的已经不是早年那种“给表单加点逻辑就够”的世界。
它开始被拿去做：
- 更复杂的客户端程序
- 更大的代码组织
- 更长期的维护
这时候再回头看老 JavaScript，很多人当然会不满足。
于是 ES4 想做的事，就不只是“再补几个 API”。
它想碰的是更深的层：
- 类
- 模块
- 包
- 命名空间
- 更强的类型表达
- 更大规模程序的组织方式
这是一种非常典型的冲动：
既然这门语言已经活下来了，那就别再只补缝了，干脆趁这个机会把它认真做成现代语言。
从愿望上说，这完全说得通。
甚至很容易让人热血。
问题只是：
愿望很大，不等于平台接得住。
03｜所以 ES4 真正危险的地方，不是野心大，而是它想一次跨过太多现实约束
很多失败方案，死因不是“完全没价值”。
反而常常是：
价值很大，但一步跨得太远。
ES4 就很像这种。
它当年最强烈的吸引力，是它真的试图回答“JavaScript 如何长大”。
可它最危险的地方也在这儿。
因为它不是沿着旧世界慢慢挪。
它更像想把这门语言往另一种气质上拉：
- 更正式
- 更系统
- 更适合大型工程
- 更接近那些大家心中“成熟语言”的样子
这就会立刻撞上一个特别敏感的问题：
JavaScript 到底该不该为了长大，把自己改得不那么像原来的 JavaScript？
这个问题一旦出现，委员会里就很难只剩技术讨论。
因为两边害怕的东西完全不一样。
支持激进升级的人会觉得：
- 不改，语言会越来越跟不上现实需求
- 不补上这些能力，开发者只会继续在语言外层搭更多土办法
- 不趁现在动手，以后历史包袱只会更重
而反对者看到的则是另一套风险：
- 一次改太大，兼容和实现都可能失控
- 语言复杂度会暴涨
- 浏览器和现有网页世界未必接得住
- 你以为是在现代化，最后可能是在制造新分裂
于是从这里开始，JavaScript 现代化第一次真正暴露出一个很硬的问题：
这门语言到底该走“激进重构”，还是“渐进演化”？
第四篇其实整篇都在围着这句转。
04｜委员会后来之所以会撕裂，不是因为大家都不讲理，而是因为双方想救的根本不是同一个东西
这也是 ES4 最值得写、也最容易被写浅的地方。
很多人讲这段历史，喜欢把它写成阵营互撕。
当然，最后确实撕了。
可如果只写成“谁脾气更大”，就没意思了。
因为这场冲突底下真正碰撞的，不只是方案表。
而是两种完全不同的救火逻辑。
一边，主要以 Mozilla / Adobe 这一侧为代表的人，更担心：
JavaScript 如果继续停在旧底盘上，会不会永远长不出支撑复杂应用的骨架。
另一边，以 Microsoft / Yahoo 等更谨慎的力量为代表的人，更担心：
JavaScript 如果一次跨太大，会不会把 Web 最依赖的连续性和实现共识直接掀翻。
你会发现，这两边都不是在单纯搞破坏。
他们都在“救”这门语言。
只是救法完全不同。
一边想的是：
趁现在还来得及，狠狠干一次大的。
另一边想的是：
先别把旧世界炸了，活着最重要。
这就是为什么我一直觉得，ES4 的冲突特别像一场语言版的路线之争。
它表面在吵提案，底下其实在吵：
JavaScript 到底是该像一次改革，还是像一场革命。
05｜最糟糕的不是意见不合，而是委员会真的分成了两条线
语言标准过程最怕的，通常不是争论。
争论很正常。
最怕的是：
争到最后，已经不像在同一个项目里工作了。
这正是当时最危险的地方。
围绕 ES4 的路线冲突后来逐渐升级成一种公开的分裂状态。
Brendan Eich 在 2008 年宣布 Harmony 时自己都承认：
It’s no secret that the JavaScript standards body ... has been split for over a year.
这句话特别重。
因为它说明问题已经不是“会里有争议”。
而是：
委员会真的裂开了。
一边还在推进以 ES4 为核心的大改路线。
另一边则在推进更小、更保守、基于 ES3 的 ES3.1 路线。
这意味着什么？
意味着 JavaScript 不只是“内部讨论紧张”。
它已经走到一个很危险的边缘：
继续这样下去，标准本身可能会先分叉。
你想想这有多吓人。
第三篇才刚讲完 ECMAScript 为什么更像停火协议。
结果没过多久，这门语言自己在现代化过程中，又差点把停火协议撕开。
所以 ES4 这段历史最狠的地方，不是某个提案最后没过。
而是它一度把整个标准过程都逼到了“继续合作还有没有意义”的边上。
06｜这也是为什么很多人后来回头看，会觉得 ES4 像一场“太想一步到位”的事故
从后见之明看，ES4 特别像一种工程世界里非常熟悉的失败模式：
旧系统问题很多，于是大家忍不住想趁一次大版本把所有账一起清。
这种想法为什么总那么诱人？
因为它有一种逻辑上的痛快。
旧账太多。
历史包袱太重。
外部需求已经变了。
那不如趁这次：
- 重新整理语言结构
- 重新定义大型程序能力
- 把之前没补上的全补上
这听起来像终于要干正事。
问题在于，Web 平台和很多封闭系统不一样。
它最不擅长承受的，就是“一次性重写秩序”。
因为它背后永远站着：
- 旧网页
- 旧引擎
- 多浏览器实现
- 迁移成本
- 市场上并不统一的推进节奏
也就是说，ES4 最后之所以看起来像事故，并不是因为它的愿望低级。
恰恰相反。
它的问题在于：
它太像一门正常语言会梦想的升级方式，却不够像 Web 这种平台真正能承受的升级方式。
这就很悲剧。
因为很多最动人的改革方案，最后往往就死在“它对，但它太不适合现实节奏”。
07｜2008 年那次 Harmony，其实不是胜利宣言，而是一次公开止损
到了 2008 年的 Oslo 会议，局面终于不能再拖了。
Brendan Eich 后来公开发出的那封 Harmony 说明，语气已经很说明问题。
它不是那种“我们伟大地达成了更宏大的下一阶段蓝图”的兴奋口气。
更像：
委员会终于决定别再这么裂下去了。
那份说明里最值得记住的，不是哪条具体技术路线。
而是它透露出来的整体姿态：
- 先集中做
ES3.1 - 下一步继续推进，但要更克制、更务实
- 有些
ES4里的东西被认定为对 Web 不够稳妥，直接出局
这里最有味道的一句，可能反而是这句：
A split committee is good for no one and nothing.
这句话听起来像常识。
可它出现在那个时间点上，几乎像事故现场广播。
因为它等于公开承认：
再不止损，JavaScript 标准化自己就先要失去共同前提了。
所以我一直觉得，Harmony 这个名字虽然听起来温和、好听、甚至有点理想主义，
但它在当时真正干的事，其实非常现实：
不是宣布全面胜利，而是先把一场差点把委员会撕裂的路线战争压回可合作状态。
这就是为什么第四篇不能把 Harmony 写成励志结尾。
它首先是止损。
然后才是重启。
08｜最残酷的一点是：Edition 4 这个编号居然真的存在过，但正式标准却根本不存在
如果你想找一个最能代表 ES4 历史命运的细节，我会选这个：
ECMA-262 Edition 4 这个编号被留了下来，但官方出版物根本不存在。
Ecma 官方今天还把这件事写得很明白：
“ECMA-262 Edition 4” was reserved but not used ... does not exist.
这句话特别冷。
也特别狠。
因为它等于把整段历史压成了一个非常少见的制度伤疤：
这不是“有个版本后来不流行”。
也不是“有个提案输了”。
而是：
连标准编号都给你留好了，结果整份正式版本根本没有出生。
这在语言史里是很罕见的画面。
它说明 ES4 的失败不是边角料级别的失败。
它是那种会直接留在标准档案页上的失败。
所以第四篇如果要有一个特别强的视觉锚点，我觉得就是这个：
编号存在，版本不存在。
这比单纯说“夭折”更有重量。
因为它说明整个委员会当年真的走到过“差一点就要往那边定稿”的位置。
只是最后，现实把方向硬掰回去了。
09｜ES4 留下来的最大遗产，不是某个没进标准的特性，而是整个社区从此不敢再那么赌
很多人一提 ES4，会先想：
- 它失败了
- 它没成标准
- 后来很多东西分散跑进了
ES5/ES6
这些都对。
但如果只看到“特性去哪了”，还是不够。
ES4 最重要的遗产，根本不是某几个具体语法点。
而是：
它把整个 JavaScript 标准社区都教育了一次。
教育内容大概就是这句：
别再拿整门语言的未来去赌一次‘大一统重写’。
你今天回头看后来的 TC39 风格，会发现它越来越强调：
- 渐进推进
- 可实现
- 可验证
- 尽量别一次压太大包袱
这种气质并不是天生就有。
很大一部分，正是 ES4 这场事故留下来的组织记忆。
也就是说，ES4 虽然没正式活成标准，
但它反而深刻塑造了：
后面 JavaScript 要怎样才敢继续进化。
这一点特别讽刺。
有时候历史上最重要的版本，不是成功发布的那个。
而是那个失败得太痛，痛到把后面所有人做事方式都改了的那个。
ES4 就很像这种版本。
10｜为什么 JavaScript 那次最像重生的尝试，最后反而差点把自己谈崩
把前面这些线叠一起看，第四篇最重要的判断其实可以压成一句：
JavaScript 不是没想过激进重生，只是那次几乎把自己谈崩了。
ES4 不该被写成一个简单笑话。
它不是“想太多所以活该失败”的低级案例。
它更像这门语言第一次真正面对成年危机：
- 旧自己已经不够用了
- 新需求在往上顶
- 大家都知道不能永远不变
- 可一旦真的想大变，又会立刻撞上 Web 平台最硬的现实边界
所以第四篇最值得留下的，不是幸灾乐祸。
而是一种更沉的判断：
JavaScript 现代化最危险的一次，不是它没变化，而是它曾经太想一次变完。
后来这门语言之所以会变成我们今天熟悉的样子，
很大程度上恰恰不是因为它完成了 ES4。
而是因为它在 ES4 这场失败之后，终于学会了另一种活法：
别再试图一口气重写自己，先学会在不炸掉旧世界的前提下慢慢长。
这也就是下一篇要接的方向。
因为从这里往后，真正改变 Web 现实的，不再只是委员会内部路线战。
而是 Web 本身正在变成应用平台。
11｜ES4 留下的，不是遗憾功能表，而是一次平台承受力测试
ES4 最值得记住的，不是“某些功能后来没上”。
更值得记住的是：
JavaScript 曾经认真尝试过一次大规模重写自己，结果那次尝试暴露出来的，不只是技术分歧，而是整个 Web 平台根本承受不起这样一场过于激进的现代化豪赌。
所以第四篇如果只记一句，就记这句：
ES4 不是简单失败，它更像一次把整门语言的治理方式都吓醒了的夭折。
编者注（事实核对）：文中关于 ES4 的激进路线、委员会分裂、Harmony 转向，以及 Edition 4 官方不存在的叙述，主要依据 Allen Wirfs-Brock / Brendan Eich 合写的 JavaScript: The First 20 Years、Brendan Eich 在 2008 年发布的 ECMAScript Harmony 公告、以及 Ecma 官方 ECMA-262 档案说明。正文中“委员会已分裂超过一年”“先集中做 ES3.1”“部分 ES4 提案被认定为对 Web 不够稳妥”“ECMA-262 Edition 4 编号保留但从未正式出版”等判断，均来自这些材料互证。文中将 ES4 概括为“差点把语言谈崩”的治理事故，属于基于史料的写作性总结。
关键人物速览
- Brendan Eich：JavaScript 的创造者，也是
Harmony公告的发出者。第四篇里他代表的是激进现代化路线与后来的止损转向。 - Douglas Crockford：Yahoo 一侧的重要声音之一。理解为什么委员会里会出现强烈的保守、渐进路线，绕不开他。
- Pratap Lakshman：Microsoft 一侧的关键人物。第四篇里他代表的是
ES3.1这条更小、更稳的演进路线。 - Lars Hansen：Adobe 一侧的重要代表。理解
ES4为什么不仅是 Mozilla 理想，也和更大规模应用语言诉求有关，他很关键。
参考与延伸阅读
JavaScript: The First 20 Years
https://dl.acm.org/doi/10.1145/3386327作者修订版 PDF：JavaScript: The First 20 Years
https://www.wirfs-brock.com/allen/jshopl.pdfECMAScript Harmony（Brendan Eich, 2008）
https://esdiscuss.org/topic/ecmascript-harmonyECMA-262 标准档案页（Edition 4 does not exist）
https://ecma-international.org/publications-and-standards/standards/ecma-262/John Resig: ECMAScript Harmony
https://johnresig.com/blog/ecmascript-harmony/Brendan Eich: ES4 News and Opinion
https://brendaneich.com/2007/11/es4-news-and-opinion/
下篇预告：Ajax 之后，JavaScript 从页面补丁变成了应用引擎。