01|很多人以为标准化是加冕,其实 JavaScript 更像先被送去急诊

如果你只从今天往回看,很容易把 ECMAScript 理解成一场顺理成章的加冕。

前面有语言诞生。

中间有浏览器大战。

再往后,标准组织出场,把局面收拾清楚。

听起来很像技术史教科书会喜欢的节奏:

  1. 先发明
  2. 再扩散
  3. 再标准化
  4. 然后进入成熟期

JavaScript 这条线不是这么长的。

它更像:

  1. 先仓促诞生
  2. 立刻被拖进浏览器大战
  3. 互操作问题马上爆出来
  4. 大家赶紧找地方止血

这就是第三篇最该记住的基本判断。

ECMAScript 最早出现时,最重要的作用不是“宣布 JavaScript 成熟了”。

而是:

别让这门语言在厂商竞争里先碎掉。

所以如果说第一篇讲的是仓促出生,第二篇讲的是迅速分裂,那第三篇真正要讲的,就是:

这门语言第一次试图建立公共秩序时,为什么更像一份停火协议,而不像一场正式登基。


02|Netscape 把 JavaScript 送去标准化,不是因为从容,而是因为已经不从容了

第二篇里已经看到,麻烦来得非常快。

JavaScript 才出生没多久,微软的 JScript 就跟上来了。

问题还不只是“名字不同”。

更麻烦的是:

  • 浏览器对象模型在分叉
  • 宿主环境在分叉
  • 作者写出来的网页脚本开始出现兼容问题

JavaScript: The First 20 Years 里有一句特别关键的话:

Within its first year Web developers were encountering interoperability issues between Netscape's JavaScript and Microsoft's reverse-engineered implementation.

这句话的杀伤力很大。

因为它说明一件事:

这门语言的标准化需求,几乎不是慢慢生长出来的,而是被现实立刻逼出来的。

这很不一样。

有些语言进入标准化,是因为生态变大了,大家想认真整理共识。

JavaScript 进入标准化,首先更像是因为:

再不赶紧找个公共牌桌,浏览器大战会把它打成长期方言。

所以 Netscape 把 JavaScript 往 Ecma 那边送,并不是一种悠闲的“我们来讨论一下语言哲学”。

它更像一项现实动作:

先把语言核心里最容易继续分叉的部分拉回共同边界。

你可以把它理解成:

  • 不是先设计未来
  • 而是先防止继续散架

这就决定了 ECMAScript 第一阶段的气质。

它天生不会太浪漫。

它更像应急秩序。


03|为什么是 Ecma,不是 W3C?因为大家当时急着标准化的是语言,不是整个浏览器世界

很多人今天一看到 Web 技术标准,第一反应都是 W3C

这很正常。

毕竟 HTMLCSSDOM 这些名字,长期都和 Web 标准组织绑在一起。

JavaScript 当年被送去的地方,不是 W3C,而是 Ecma

这里最值得看的一点,不是机构八卦。

而是它反映了一个很现实的判断:

大家当时先想收住的,是语言核心,不是整个浏览器宿主世界。

这点非常关键。

因为到了第二篇那个阶段,所有人都已经感觉到:

网页脚本世界太乱了。

但这份混乱并不是一团完全同质的东西。

里面至少混着两层账:

第一层是语言本体:

  • 语法
  • 类型
  • 对象模型
  • 运算规则

第二层是浏览器宿主环境:

  • window
  • document
  • 事件
  • 页面元素访问方式
  • 各家浏览器自己额外暴露的能力

如果一上来就想把这两层全拉进一个统一大工程,难度会非常大。

所以更现实的路线是:

先把语言核心单独拎出来。

这就是为什么 ECMA-262 第一版一上来就把自己定义成:

“ECMAScript: A general purpose, cross-platform programming language.”

这句话表面像常规标准摘要。

实际上非常有立场。

它等于在说:

我们先谈的是这门脚本语言本身。

它会运行在宿主环境里,但宿主环境不是这份标准打算一把兜完的全部世界。

这一步当然必要。

但它也埋下了后面的长期别扭:

JavaScript 的标准化,从第一天起就先把“语言”和“浏览器现实”切成了两张账。

而开发者实际面对的,偏偏永远是两张账叠在一起。


04|第一版规范最有味道的一句,不是技术条文,而是那段“Brief History”

如果你去看 ECMA-262 第一版开头那段 Brief History,会发现它写得其实非常坦白。

它直接说:

  • 这份标准基于几种来源技术
  • 其中最著名的是 Netscape 的 JavaScript
  • 和 Microsoft 的 JScript
  • 这项标准开发始于 1996-11

很多标准文档喜欢装作自己天生来自抽象理性。

ECMA-262 第一版没有完全这么装。

它一开场就把现实写出来了:

这份标准不是从真空里长出来的。它就是在几种已经跑起来、而且已经互相挤压的实现之间,试图建立共同底线。

这就解释了为什么我一直觉得 ECMAScript 最早更像停火协议。

因为真正的停火协议,往往都有几个特征:

  • 不是大家都满意
  • 不是一切问题都解决
  • 也不是未来蓝图已经画完

它更像:

先把已经开打的几方拉回一张桌子,至少先把共同底线写出来。

ECMA-262 第一版就是这种气质。

它不是在宣布“最理想的 JavaScript 长这样”。

它更像在宣布:

“无论你们前面怎么打,这门语言至少要有一个大家都能认出来的核心轮廓。”


05|这也是为什么我一直觉得,ECMAScript 这个名字本身就带着妥协味

如果说 JavaScript 这个名字里写着市场宣传,

ECMAScript 这个名字里写着的,就是标准妥协。

因为正常人都知道,标准名字最理想的情况当然是直接叫 JavaScript

那才是市场上所有人真的在说的名字。

可现实偏偏不允许它这么简单。

Brendan Eich 在 2008 年的访谈里讲得很直:

ECMAScript 之所以会变成标准名,是因为标准组织拿不到一个所有方都同意的 JavaScript 商标安排。

Sun 有商标。

Netscape 用这个名字。

微软拿不到许可,于是自己那边叫 JScript

结果标准组织最后只能发明一个新的中性名字。

这名字听着很别扭。

Eich 自己后来还吐槽过,说它听起来像种皮肤病。

这句大家爱引用,是因为它确实很形象。

但更重要的是,这件事本身透露出的结构:

标准连名字都没法直接沿用市场上的公共叫法,这说明它从一开始就不是在一个真正统一的世界里工作。

所以 ECMAScript 这个词最值得看的,不是它奇怪。

而是它为什么必须奇怪。

因为它本身就是一份历史痕迹:

  • JavaScript 是市场世界的名字
  • JScript 是厂商分叉世界的名字
  • ECMAScript 是标准组织不得不造出来的中性名字

三个名字并存,本身就说明:

这门语言最早不是长在单一秩序里,而是长在商标、厂商实现和标准化彼此拉扯的夹缝里。


06|可问题在于,标准能先收住语言,却收不住浏览器现实

到这里就会出现一个非常关键、也非常容易误解的地方。

很多人会自然觉得:

既然有了 ECMAScript,是不是局面就开始稳定了?

答案是:

稳定了一部分,但远远没有全稳定。

因为 ECMAScript 最早能做的,是给语言核心立底线。

它能处理的是:

  • 这门语言有哪些基本类型
  • 运算规则是什么
  • 对象和原型怎么理解
  • 语法层面怎么统一

可开发者真正写网页脚本时,遇到的又不只这些。

他们还要面对:

  • document 到底怎么取元素
  • 事件对象长什么样
  • 页面对象模型是否一致
  • 哪些宿主能力是共通的,哪些是浏览器私货

这些问题不是一份语言标准就能立刻抹平的。

于是就出现了 JavaScript 历史里一个特别关键、也特别别扭的长期结构:

语言标准先统一一部分,运行时现实继续分裂一大半。

这会带来一种非常古怪的开发体验:

纸面上,你终于有了共同语言核心。

现实里,你写网页还是要继续防浏览器差异。

所以 ECMAScript 最早的意义,更像是:

把火势从“整间屋子都在烧”压到“至少先把主梁保住”。

这已经很重要了。

但它离“天下太平”还非常远。


07|换句话说,TC39 最早干的事,不是设计乌托邦,而是给战争划边界

这也是为什么我觉得,理解早期 TC39 的关键,不是把它想象成一群纯粹语言设计师。

它当然有语言设计这一面。

但在那个时间点上,它更现实的任务,其实是:

给已经失控的分裂趋势划边界。

你可以把它想得更直白一点。

如果没有这条线,后面很可能发生的,不是什么“浏览器各自扩展一点点”。

而是:

  • Netscape 一路带着自己的 JavaScript 版本跑
  • 微软一路带着自己的 JScript 和宿主系统跑
  • 开发者被夹在中间长期写双份脚本
  • Web 脚本能力越来越像厂商锁定工具

这会非常危险。

因为 Web 之所以能扩张,一个很重要的前提就是:

底层公共能力不能完全变成私有阵营武器。

所以 TC39 最早干的事情,本质上不是“把一门已经稳定的语言继续雕花”。

它更像:

先把这门语言从浏览器大战里抢救成一个还能继续谈公共规则的对象。

这就是我说“停火协议”比“加冕礼”更贴切的原因。

加冕礼意味着胜利者、成熟、秩序既定。

停火协议意味着:

  • 大家刚打过
  • 问题还没全解决
  • 但至少先别再往更坏的方向裂

ECMAScript 第一阶段,明显更像后者。


08|这也解释了为什么 JavaScript 世界后来一直有“两张账”

如果把这一步看懂,你就能明白今天很多前端世界的别扭感,其实很早就种下了。

为什么直到今天,大家还总会混着说:

  • JavaScript
  • ECMAScript
  • Web API
  • DOM
  • 浏览器支持

为什么很多人一谈“JS 新特性”,实际上说的是浏览器能力,不只是语言语法?

根就在这里。

因为历史上最早的标准化动作,本来就只先拎住了其中一层。

于是这门语言后来的现实,就长期分成了两张账:

第一张账是语言标准:

  • ECMA-262
  • 强调共同语言核心

第二张账是运行时现实:

  • 浏览器到底给了什么
  • 各家实现差异有多大
  • 页面脚本实际能碰到哪些对象和事件

开发者的日常经验,则永远是两张账合在一起。

这也是为什么很多看似只是“术语混乱”的问题,其实都有深历史背景。

不是大家故意分不清。

而是:

这门语言最早的秩序建立方式,本来就不是把整个世界一次性讲清,而是先把其中一部分单独稳定下来。

这当然比没有标准好得多。

但代价就是后面很长时间里,JavaScript 都会带着一种结构性的双轨感。


09|为什么 ECMAScript 一上来先要做的,不是统一天下,而是先止血

把前面这些线叠一起看,第三篇最重要的判断其实可以压成一句:

ECMAScript 最早是为了防止继续分裂,不是为了宣告已经统一。

它的出现,当然很重要。

没有它,JavaScript 这门语言后来很可能连共同核心都保不住。

可它在 1997 年那个时间点上的意义,更接近:

  • 给语言核心立底线
  • 给浏览器大战划边界
  • 给开发者至少保住一个“不会彻底散架”的希望

它不是某种“从此一切清楚”的起点。

它更像一场混乱局面中的第一次制度止血。

而且最要命的是,止血并不等于痊愈。

因为语言核心能先停火,不代表浏览器宿主世界也会立刻停火。

所以第三篇其实是在帮整套系列建立一个很重要的中间判断:

标准当然重要,但标准最早能做到的,往往只是先守住一部分现实。

这和很多人脑子里“标准一来,世界就整齐了”的想象,完全不是一回事。


10|ECMAScript 一开始更像止战文本,不像加冕文本

ECMAScript 第一次出现时,最值得记住的,并不是“JavaScript 终于有官方名字了”。

更值得记住的是:

这门语言在刚开始大规模扩张时,就已经乱到必须先找一份公共文本,来阻止它继续被浏览器大战打碎。

所以第三篇如果只记一句,就记这句:

ECMAScript 最早不是一场加冕礼,它是一份在 JavaScript 和 JScript 已经开始互相拉扯之后,勉强把语言核心重新拉回同一张桌子的停火协议。


编者注(事实核对):文中关于 ECMA-262 第一版的背景、命名、以及其与 JavaScript / JScript 的关系,主要依据 ECMA-262 第一版 开头 Brief History、Ecma 官方对 ECMA-262 二十周年的回顾,以及 Allen Wirfs-Brock / Brendan Eich 合写的 JavaScript: The First 20 Years。正文中“标准开发始于 1996-11”“第一版基于 Netscape 的 JavaScript 与微软的 JScript”“标准名 ECMAScript 与商标问题相关”等判断,均来自这些材料互证。关于 Brendan Eich 对 ECMAScript 名字的吐槽,见其 2008InfoWorld 访谈。


关键人物速览

  • Brendan Eich:JavaScript 的创造者。第三篇里他更重要的身份,是把 Netscape 那条语言线送进标准化流程的人之一。
  • Guy SteeleECMA-262 第一版编辑。第三篇里他代表的是“把混乱现实整理成共同文本”这层工作。
  • Waldemar Horwat:早期 TC39 关键人物之一。理解 JavaScript 早期标准化和后续规范讨论,很难绕开他这条线。

参考与延伸阅读

  1. ECMA-262 第一版(1997)
    https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf

  2. ECMA-262 标准档案页
    https://ecma-international.org/publications-and-standards/standards/ecma-262/

  3. Ecma:ECMA-262 二十周年回顾
    https://ecma-international.org/news/ecma-262-the-ecmascript-javascript-the-most-popular-web-scripting-standard-is-celebrating-its-20th-birthday/

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

  5. 作者修订版 PDF:JavaScript: The First 20 Years
    https://www.wirfs-brock.com/allen/jshopl.pdf

  6. JavaScript creator ponders past, future (InfoWorld, 2008)
    https://www.infoworld.com/article/2653798/javascript-creator-ponders-past-future.html


下篇预告:一门语言差点把自己重写过头,ES4 为什么最后夭折。