01｜这场仗表面在比快，底下其实在争：浏览器到底要不要认真把 JavaScript 当核心资产
第五篇讲到 Ajax 之后，Web 开始想更像应用。
页面不再只是跳转和重载。
它开始想：
- 持续响应
- 局部更新
- 保持状态
- 承担越来越复杂的客户端逻辑
一旦走到这一步，问题就会立刻变得很现实：
那 JavaScript 跑得够不够快？
这是第六篇真正的起点。
因为从这里开始，JavaScript 的历史又往前拧了一下。
它不再只是“有没有这门语言”的问题。
也不再只是“标准怎么定”的问题。
它突然变成了：
浏览器厂商愿不愿意把足够多的工程资源，砸进这门语言的执行性能里。
这听上去像个纯技术问题。
其实一点都不纯。
因为一门语言如果只是配角，大家通常不会这么认真替它提速。
只有当平台已经默认：
“这东西接下来会承受越来越多关键工作。”
性能才会从“优化项”变成“战略项”。
所以第六篇最该记住的，不是某个引擎名字。
而是：
浏览器厂商第一次集体用行动承认：JavaScript 不再只是网页里的小脚本，它已经值得当成平台中心战场来打。
02｜为什么偏偏是这个时间点开始卷性能？因为 Web 已经先把野心抬上去了
如果你只看 V8、TraceMonkey 这些名字，很容易误会成：
好像浏览器厂商忽然心血来潮，决定来一场虚拟机技术竞赛。
可真正的顺序刚好反过来。
不是引擎先想变快，然后 Web 才变成应用。
而是：
Web 已经开始像应用，引擎才被逼着必须变快。
这点特别重要。
因为 Ajax 时代已经把一件事做成共识了：
用户会越来越习惯下面这种体验：
- 页面别老整页刷新
- 交互最好更连续
- 响应最好更即时
- 浏览器里的界面最好越来越像真正的软件
可一旦你真把这种期待抬起来，JavaScript 的短板也会立刻被放大。
以前它只是做点小校验，慢一点还能忍。
现在它开始承担：
- 更密集的事件响应
- 更频繁的 DOM 操作
- 更复杂的界面逻辑
- 更持续的状态调度
这时候只要引擎稍微迟一点，用户就能明显感到：
- 卡
- 钝
- 拖
- 不像应用
所以性能战争之所以会爆出来，不是偶然。
它是 Ajax 时代把 JavaScript 推上应用引擎位置之后，几乎必然会来的下一场大戏。
03｜Google 真正改写游戏的地方，不只是做了 Chrome，而是公开把“快的 JavaScript”写成产品哲学
到这里，2008 年的 Chrome 和 V8 才真正该出场。
很多人后来一回忆这段历史，第一反应都是：
Chrome 很快。
这当然没错。
但如果只停在“快”，还是不够。
因为 Google 当时最关键的一步，不只是把一个更快的引擎塞进浏览器。
而是它非常明确地对外宣布：
JavaScript 性能，就是这代浏览器最核心的问题之一。
Chromium 那篇著名的 Google Chrome's Need for Speed，标题本身就已经把姿态摆得很明白了。
不是“我们也顺手优化了一下脚本执行”。
而是：
Need for Speed。
这四个词背后其实有非常重的判断。
它等于在说：
Web 接下来要不要继续往前走，浏览器能不能撑住更复杂的应用体验，JavaScript 跑得快不快，已经不是边缘指标。
它会直接影响平台未来。
所以 V8 的重要性，从来不只是“某个引擎技术上很强”。
它更重要的地方在于：
Google 把“让 JavaScript 真正快起来”这件事，第一次做成了公开的浏览器战略宣言。
这会逼着别人全部跟上。
04｜V8 真正吓到同行的，不只是新引擎，而是它把“JS 可以快得离谱”这件事突然变得像现实
很多技术路线真正可怕的地方，不是它理论更先进。
而是它突然把原本大家觉得“差不多就这样了”的天花板，整个抬高了。
V8 在 2008 年的作用就很像这个。
Google 后来回顾 V8 十年历史时提到，项目在 2006 就开始筹备，Lars Bak 被招去做这件事，目标非常直接：
给 Chrome 造一台真正够快的 JavaScript 引擎。
而且不是小打小闹的加速。
是那种会让浏览器对 JavaScript 的态度整个改掉的加速。
所以 V8 出来以后带来的最强冲击，未必是某个实现细节。
而是心理层面的那一下：
原来 JavaScript 不是只能凑合跑。
原来它真的可以被当成需要认真编译、认真优化、认真对待的执行对象。
这件事一旦成立，后果会非常大。
因为它会立刻改写大家对平台边界的判断：
- 以前觉得太慢、太不现实的东西，开始看起来像可以做
- 以前只敢交给插件或桌面程序的体验，开始有人想往浏览器里搬
- 以前“脚本语言就那样”的轻视，会慢慢失效
从这个角度看，V8 不是只做了加速。
它更像是：
把 JavaScript 的社会预期一把抬高了。
05｜而 Mozilla 很快用 TraceMonkey 回了这一枪，这说明事情已经不是单点创新，而是全面开战
如果只有 Google 一家在喊“JavaScript 要快”，那这件事还可能只是某家公司的产品押注。
真正说明局面变了的，是 Mozilla 这边也马上把战线拉了起来。
Brendan Eich 在 2008-08 发 TraceMonkey: JavaScript Lightspeed 那篇文章时，语气其实非常有时代感。
里面最值得记住的，不只是技术细节。
而是几种态度同时露出来了：
JIT不再只是学术或虚拟机圈的小众词汇- JavaScript 提速被直接说成能带来
order of magnitude的变化 - Mozilla 明确意识到，这不是可有可无的优化
- 大家都已经知道：谁先把 JavaScript 跑快，谁就会重新定义 Web 的上限
Eich 在文里甚至写得很直：
we are moving the goal posts and changing the game
这句话非常关键。
因为它说明连当事人自己都知道，这已经不是普通的版本更新。
这是一场改比赛规则的战斗。
而一旦 Google、Mozilla 都用这种语气来讲 JavaScript 性能，事情的性质就彻底变了。
它不再只是“哪个浏览器更顺手”。
它变成：
谁能让 Web 平台继续往应用方向长下去。
06｜这时候 benchmark 为什么会突然变得这么重要？因为大家需要一块人人看得懂的战场
语言性能这种东西，本来很难讲清。
你说快一点、慢一点，普通人没概念。
工程师自己也很容易各说各话。
所以这时候 SunSpider、后来的 Kraken、Octane 这些 benchmark 之所以突然变得这么有存在感，并不是偶然。
它们的作用，很像前面 CSS 里 Acid2 那种公开考试：
给所有人一块人人看得懂、至少看得出胜负走势的战场。
一旦有了跑分，性能战争就会变得非常可传播。
媒体可以写。
开发者会盯。
厂商会宣传。
团队内部也更容易争资源。
这当然会带来副作用。
因为 benchmark 很容易把大家引到“为了分数而优化”的路上。
可在那个阶段，它的历史作用依然很大：
它把 JavaScript 性能从引擎内部问题，变成了整个 Web 行业都能围观、比较、施压的话题。
而一旦这件事公开化，所有主流浏览器厂商就更不可能装作无所谓。
07｜这轮性能战争真正改写的，不只是运行速度，而是语言地位
这点特别重要。
因为很多人后来回忆那段时间，会习惯性地说：
“哦，就是 JavaScript 引擎后来变快了。”
这话从结果上没错。
但它还是太轻。
更准确的说法是：
引擎变快，最后改写的是 JavaScript 在整个平台里的地位。
为什么？
因为一门语言如果慢得明显，它能承担的责任就有限。
你可以让它做胶水。
可以让它做边角。
可以让它做一点点用户交互。
可一旦你想让它承担：
- 更大规模的 UI 更新
- 更复杂的应用逻辑
- 更频繁的即时反馈
- 更重的客户端任务
性能就会决定这条路到底走不走得通。
也就是说，性能战争的真正意义不是“体验更丝滑”这么简单。
它更深的意义在于：
它让 JavaScript 从‘勉强能担事’变成了‘值得继续往上押注’。
这会影响一整串后续历史：
- 框架更敢变重
- 浏览器厂商更敢把更多能力往客户端放
- 开发者更敢把更复杂的逻辑写进浏览器
换句话说，V8、TraceMonkey 这些名字的历史意义，不只是它们把引擎做快了。
而是它们让“JavaScript 可以承担更多平台野心”这件事突然看起来像真的。
08｜为什么性能战一开打，JavaScript 的身份就不一样了
把前面这些线叠一起看，第六篇最重要的判断其实可以压成一句：
JavaScript 不是自然变重要的，它是被性能战争正式扶正的。
第五篇里它已经因为 Ajax 和 Web 应用化，被推到了更关键的位置。
可那时它还只是“责任变重了”。
第六篇要讲的，是另一层：
浏览器厂商终于愿意按平台中枢的标准，给它配真正重量级的工程投入。
这很关键。
因为很多技术哪怕需求很强，如果没有厂商在底层执行层面真砸资源，最后也走不远。
JavaScript 之所以后来越长越大，一个非常硬的前提就是：
浏览器厂商不再把它当玩票脚本。
他们开始把它当作：
- 虚拟机优化对象
- 产品差异化核心
- 平台未来押注点
一旦这件事成立，JavaScript 的命就完全不一样了。
从这里开始，你已经很难再说：
它不过就是网页里那门脚本。
因为平台已经先不这么看它了。
09｜这也就是为什么下一篇必须谈 Node.js：当 JavaScript 既足够重要，又足够快，它就不再只属于浏览器了
如果第六篇只停在“浏览器里性能变好了”，那还是不够。
因为这轮提速真正带来的下一步后果其实更大：
JavaScript 开始不再只属于浏览器。
这是很自然的逻辑。
当一门语言同时满足两件事：
- 它已经有巨大开发者基础
- 它现在又有了越来越能打的执行性能
那总会有人问：
为什么非得把它锁死在浏览器里？
这时候，后面的路几乎就已经铺好了。
你会开始看到：
- 它不只适合写页面逻辑
- 它也可能适合写服务器程序
- 它也可能适合做命令行工具
- 它也可能适合变成更大一整套生态的底层语言
所以第六篇和第七篇之间，其实是非常紧的因果关系。
第六篇讲的是：
浏览器厂商把 JavaScript 的执行层打磨到足够值得认真看待。
第七篇要讲的则是：
既然已经足够值得认真看待，它为什么还要继续待在浏览器里。
这也就是 Node.js 出场的历史时机。
10｜性能战争之后，JavaScript 才真正像平台资产
V8、JIT、Chrome 和整轮性能战争，最值得记住的，不只是它们让跑分更漂亮。
更值得记住的是：
它们第一次让整个行业相信，JavaScript 的未来不该只由“语法够不够顺手”决定，还要由“这门语言到底能不能承受平台级负载”来决定。
而一旦浏览器厂商集体回答“能，而且我们愿意继续砸资源让它更能”，JavaScript 的命运就再一次被改写了。
所以第六篇如果只记一句，就记这句：
性能战争真正做的，不是把 JavaScript 从慢变快，而是把它从“能用的网页脚本”正式扶正成“必须认真经营的平台核心”。
编者注（事实核对）：文中关于 Chrome / V8 把 JavaScript 性能推上战略位置的叙述，主要依据 Chromium 官方 Google Chrome's Need for Speed、Google 发布 Chrome / Chromium / V8 的官方博文，以及 V8 官方十周年回顾。关于 Mozilla / TraceMonkey 的性能叙事，主要依据 Brendan Eich 的 TraceMonkey: JavaScript Lightspeed 与后续更新。正文将 SunSpider、Kraken、Octane 概括为“公开战场”，属于对当时 benchmark 文化历史作用的写作性总结。文中把这轮竞赛概括为“把 JavaScript 正式扶正”，是基于平台投入、公开叙事与后续影响做出的历史判断。
关键人物速览
- Lars Bak：
V8的核心人物。第六篇里他代表的是把 JavaScript 引擎真正按高性能运行时来打造的那条路线。 - Brendan Eich：JavaScript 的创造者，也是 Mozilla 性能战叙事中的关键声音。第六篇里他代表的是 Mozilla 这边对
TraceMonkey和 JIT 竞赛的推进。 - Andreas Gal：
TraceMonkey的关键人物之一。理解 Mozilla 为什么能在性能战争里快速打出回应，绕不开他。
参考与延伸阅读
Chromium Blog: Google Chrome's Need for Speed
https://blog.chromium.org/2008/09/google-chromes-need-for-speed_02.htmlGoogle Chrome, Chromium, and V8 launch today
https://developers.googleblog.com/en/google-chrome-chromium-and-v8-launch-today/Celebrating 10 years of V8
https://v8.dev/blog/10-yearsTraceMonkey: JavaScript Lightspeed
https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/TraceMonkey Update
https://brendaneich.com/2008/09/tracemonkey-update/Tracing the Web (Andreas Gal)
http://andreasgal.com/2008/08/22/tracing-the-web/
下篇预告：Node.js 不是换个运行时，它把 JavaScript 送进了新的权力中心。