🍻 跟着 Chrome 学技术

[原创] 最后编辑于：2020-11-17 22:50:20@code#整理 #思考 #功能

!本篇文章过于久远，其中观点和内容可能已经不准确，请见谅!~

想让读者了解的事情

在阅读这篇关于 Chrome 技术实现的文章前，希望你能理解：

标准化的力量 - 原生 Web 标准往往是最优的解决方案
组件化的本质 - Web Components 提供了真正的封装和复用能力
未来技术的前瞻性 - 理解新技术趋势对技术选型的重要性
工程化的平衡 - 性能、开发体验、可维护性之间的权衡
学习的方法论 - 从优秀项目中汲取经验，举一反三

PS: 在你的 Chrome 浏览器里面输入 chrome://welcome/，我们从这里开始

一、观其行

能看到：

用了 ES Module
用了 Web Component
用了暗黑的 CSS Query
用了 CSS 变量
css 居然放到了最后 👿👾💀

代码很简洁，主要是因为用了 Web Component；用了很多新的技术，因为跟浏览器绑定，倒是一点不用担心兼容问题 😂。

能看到：

是一个 SPA 应用，后续的功能都在这一个页面里
用了 Polymer.js 作为 Web Component 框架
在 cr_elements 里应该是组件库，Web Component 规范
自行实现了一个简单的路由行为
用了 JSDoc
定义了一套 Proxy 机制和原生的浏览器通信
没有使用预编译打包！

二、详其义

2.1 Web Component + ES Module

这个开发模式应该算是面向浏览器标准了，组件化开发盛行的现在，原生 ES 标准给出的答案好像是 WebComponent 的应用，之前尝试过，感觉还是不错的，不过需要有更友好的开发工具才能更舒服，而且兼容性的问题短时间内还无法完全让人放心，不过面向未来的方案还是很值得投入调研的。

2.2 技术选型的启示

Chrome 的技术实现给我们带来几个重要启示：

1. 标准优先

Chrome 团队选择了原生的 Web 标准，而不是依赖第三方框架。这样做的好处：

无额外依赖：减少包体积，提高加载速度
更好的兼容性：浏览器原生支持，不用担心版本问题
未来可维护性：标准是稳定的，不会频繁变化
性能优势：原生实现通常比框架更高效

2. 组件化思维

Web Components 提供了真正的封装能力：

// 自定义元素的实现示例
class WelcomeElement extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.render();
  }
  render() {
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
          padding: 20px;
        }
      </style>
      <slot></slot>
    `;
  }
}
customElements.define('welcome-element', WelcomeElement);

3. 开发体验的平衡

Chrome 源码中的一些设计考虑：

代码简洁：使用高级抽象，减少冗余
文档完整：JSDoc 提供了良好的代码文档
模块化：清晰的模块划分，职责明确
渐进增强：从基础功能开始，逐步添加高级特性

2.3 架构设计的思考

单页应用的设计

Chrome 欢迎页采用 SPA 模式，这背后有其深层原因：

一致性体验：所有功能在同一个上下文中，避免页面跳转的割裂感
性能优化：减少重复加载，提高响应速度
状态管理：全局状态更容易维护
代码组织：所有相关代码集中管理

但 SPA 也有其缺点：

SEO 困难：搜索引擎索引问题
首屏性能：需要加载所有代码
历史管理：需要额外实现路由机制

Chrome 团队选择了简单粗暴的方式：自己实现路由，而不依赖框架。

通信机制的设计

Chrome 源码中有一个 interesting 的设计：他们实现了一套 Proxy 机制与原生浏览器通信。这种设计有几个优势：

解耦：业务逻辑与浏览器功能分离
安全性：通过代理控制访问权限
可扩展性：可以轻松添加新的通信方式
性能：直接调用原生 API，减少中间层

2.4 性能优化的实践

1. CSS 放置策略

/* 常规做法 */
<head>
  <style>
    /* 样式放在头部，阻塞渲染 */
  </style>
</head>
/* Chrome 的做法 */
<body>
  <!-- 内容先渲染 -->
</body>
<style>
  /* 样式放在最后，不阻塞渲染 */
</style>

这种策略的原因：

减少阻塞：浏览器可以边解析边渲染
优化用户体验：用户能更快看到内容
并行处理：CSS 解析与 HTML 渲染可以并行

2. 按需加载

虽然是单页应用，但 Chrome 采用了组件化设计，实现了按需加载：

// 组件懒加载
const loadComponent = async (name) => {
  const module = await import(`./components/${name}.js`);
  return module.default;
};
// 动态创建组件
const element = document.createElement('welcome-element');
document.body.appendChild(element);

2.5 开发工具的选择

为什么不用构建工具？

Chrome 源码有几个明显特点：

无预编译：直接使用原生 JavaScript
模块化：使用 ES Module 标准化模块
文件组织：按照功能模块组织
类型检查：可能使用 JSDoc 或 TypeScript 类型

这种选择的原因：

开发效率：省去构建时间，快速迭代
调试友好：可以直接在浏览器中调试
生产优化：浏览器本身会进行优化
学习成本：降低框架依赖，更专注于业务

3. 暗黑模式的技术实现

Chrome 的暗黑模式实现很有特色：

/* 使用 CSS 变量和媒体查询 */
:root {
  --bg-color: #ffffff;
  --text-color: #000000;
}
@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: #1a1a1a;
    --text-color: #ffffff;
  }
}
/* 使用 CSS 查询选择器 */
.container {
  background-color: var(--bg-color);
  color: var(--text-color);
}

这种设计的好处：

系统级适配：跟随系统设置
性能友好：纯 CSS 实现，无 JavaScript 开销
易于维护：集中管理主题变量
可扩展性：可以轻松添加更多主题

2.6 对我们项目的启示

基于 Chrome 的实践，我们可以反思自己的项目：

1. 技术选型的原则

优先选择标准：原生标准通常是最优解
谨慎引入框架：框架是有成本的（学习成本、维护成本）
保持简单：简单的方案往往更可靠
关注性能：性能不是优化出来的，设计出来的

2. 架构设计的思考

// 一个简单但灵活的架构设计
interface AppArchitecture {
  // 核心功能
  core: {
    router: Router;
    state: StateManager;
    components: ComponentRegistry;
  };
  // 扩展功能
  plugins: Plugin[];
  // 工具链
  utils: {
    logger: Logger;
    storage: Storage;
    api: API;
  };
}

3. 开发流程的建议

渐进式开发：从简单开始，逐步完善
文档先行：好的文档比代码更重要
测试驱动：测试是质量的保障
持续集成：自动化保证代码质量

Chrome 的源码展示了一种不同的开发哲学：简单、直接、面向未来。他们没有使用最流行的框架，而是选择了最合适的标准。这提醒我们，技术选型不是追求潮流，而是选择最适合项目的方案。

2.7 未来技术的发展趋势

从 Chrome 的实践中，我们可以看到几个重要趋势：

1. Web Components 的普及

虽然目前 React、Vue 主流，但 Web Components 在特定场景下有独特优势：

真正的封装：样式和逻辑完全隔离
跨框架可用：不依赖于特定框架
浏览器原生支持：不需要额外引入

2. 模块化标准

ES Module 已经成为标准，未来：

不需要打包工具：浏览器直接支持模块
开发体验提升：无需配置复杂的构建流程
性能优化：浏览器可以优化模块加载

3. 渐进式 Web 应用

结合 Service Worker、WebAssembly 等技术，未来的 Web 应用将：

接近原生体验：离线、推送、安装
高性能：WebAssembly 提供高性能计算
平台无关：跨平台、跨设备