浏览器博弈论

在浏览器大战g [Borland 2003] 期间，Netscape 和微软都尝试在引入新网站能力上实现超越式的创新。他们都试图说服开发者使用其独有的特性，并开展了「在『XXX』上效果最佳」的营销活动。但如果网站无法在用户首选的浏览器下正常工作，浏览器用户会很不高兴。而且 Web 开发者也不喜欢为不同浏览器维护网站的多个版本。

即使微软为了赢得 Netscape 的市场份额，在技术和非技术方面都进行了大量投资，人们仍然意识到 JavaScript 的发展除了竞争外还需要合作。1997 年 7 月，在第一版 ECMA-262 的工作即将完成前的 TC39 会议上，微软的 Scott Wiltamuth 提出了关于未来 ECMAScript 开发的合作承诺（图 23）。

  1. 一种不同的工作方式
  2. 微软在 ECMAScript 标准上的承诺
  4. * 我们将把影响 ECMAScript 的新想法拿上组织的台面，而非保持机密。
  5. * 我们将实现组织内达成一致意见后的想法。
  6. * 我们将遵守组织内的架构原则，而非发布无视原则或与其矛盾的替代品。
  7. * 我们将不会在首先提交到 ECMA 前，发布 ECMAScript 的扩展。
  8. * 我们将实现所有 ECMA 批准的 ECMAScript 标准。
  9. * 我们将明确标识出所有我们目前支持但尚未批准的 ECMAScript 特性。

图 23. 微软在 1997 年 7 月 TC39 会议上的承诺 [TC39 1997g]。

Brendan Eich 回忆说在某个时候，他意识到市场的务实性严重限制了浏览器实现者能用来改善其产品的举措。例如：

  • 破坏性变更（甚至 bug 修复）可能赶走用户。
  • 新浏览器必须遵从于现有的浏览器。
  • 如果仅在一个浏览器中进行创新，那将是浪费。
  • 第一个吃螃蟹的浏览器，可能反而会丢失市场份额。

Eich 意识到这种情况很可能属于纳什均衡 [Nash 1950]，因此创造了「浏览器博弈论」一词，用以描述浏览器实现者所受到的约束。

第一个约束有时会用「不要破坏 Web！」的口号来表述。网页通常以 HTML 和 JavaScript 源码的形式存储在服务器上。每次用户访问页面时，浏览器都会对其进行重新解释。这些页面中有很多并非由其原始创建者维护，但仍在活跃使用中，其中还包括一些具有持续效用或历史重要性的文档。一旦浏览器解释源代码的方式发生破坏性变更g，就可能导致某个页面变得难以辨认或无法正常工作。如果变化仅在单个浏览器上发生，那么用户可以切换到使用其他浏览器。如果这种变化在浏览器中普遍存在，那么这部分失去维护的 Web 就会永久损坏。这个事实也限制了 Web 标准的开发。一旦浏览器实现者认为某个标准所引入的特性（或授权做出的改动）会使得现存的大量 Web 内容失效，那么这个标准就将被忽略。

如今，浏览器开发者普遍认识到作为 Web 及其开放标准基础的兼容要求，限制了他们通过单方面平台创新进行竞争的能力。浏览器「可以并且确实」会在实现的质量（如性能、安全性、可靠性和可用性）上进行竞争。但要想提高浏览器作为应用平台的基本技术能力，通常需要所有主流浏览器之间的合作。

浏览器博弈论是 JavaScript 演化的重要因素。它还可以提供一个理解 JavaScript 为何成功的视角，并解释 JavaScript 历史上许多创新的成败缘由。