设计理念

组件设计

现状及趋势：Web 开发以组件为基础，JavaScript 社区主流是函数式编程。

组件设计应以实现目标用户需求为准。组件过于灵活以适应不同的运行环境，诱发开发者随意进行组装，导致最终组合的产品中包含大量冗余的 HTML、CSS 和 JavaScript，并无脑发送给用户。

抽取复杂组件时，注意是消除复杂性，而不是转移它。

基于特定框架、UI 库的组件，在框架、库版本重大更新，甚至更换时，自我更新成本过大。组件应独立框架，而不是适应框架。

CSS 使用 @container 容器查询，基于父级容器尺寸适配，消除 @media 媒体查询只能全局适配的局限性。

合理使用 @scope 作用域规则和 :scope 作用域选择器

框架

React.dev：直接使用框架，尽管项目可能在起步阶段不一定需要框架所提供的一切，但很可能会在未来的某个时候有所需求，那时即可轻松添加这些新功能。否则后续就得自行添加额外的库来解决各种功能需求，拉高各组件间匹配的难度。

框架依赖的配置和 Node 模块过多，已极大影响首次加载和运行性能，Node 模块安全性问题也越发突出。

ECMAScript 标准化趋势

TC39 Rob Palmer：“我们见证了工具（tools）、框架（frameworks）和模式（patterns）的迭代，随着时间推移，我们会在标准层面择取其中已趋同的点，并努力为降低应用程序技术栈的复杂度铺平道路。这样 Node 模块目录才能持续瘦身，越来越多的功能（functionality）由语言自身直接提供。”

TC39 Rob Palmer 和 Ecma Daniel Ehrenberg 均认为 ECMAScript 标准化需保守地（conservatively）进行，因为一旦发现设计有误且需要修正（比如 Web 组件），那从 Web 平台中移除错误的成本是非常高的。相比之下，Polyfill 和基于工具的功能实现（标准候选版）允许更快的反馈周期，保护了 Web 兼容性，无需让开发者等待正式流程走完所有阶段。

跨平台框架

打包

打包工具解决的问题：

rollup.js 特点：输出代码整洁，体积小，无 import 和 export 语句；摇树（tree-shaking），打包时自动删除没有用到的代码。

技术选型

多语言、多框架选择时，需考虑因素有：公司业务规划（契合度）、现有人力资源（成本）、团队技术提升（持久性）。

图形图像技术：使用第三方 UI 组件库、图表库，是否需二次开发，或者自主开发。

前端全职 VS 全栈

全职专注于：浏览器性能、跨平台、辅助功能、设计和测试部门间的桥梁、用户体验。

减少认知负担

深层模块（deep module） - 接口简单，功能复杂；浅层模块（shallow module） - 接口复杂，功能简单。浅层模块过多会使项目难以理解，不仅要记住每个模块的职责，还要记住它们之间的所有交互。深层模块把复杂性隐藏，更方便使用。

开发成本控制

尽可能让事情简单化；尽可能少造轮子；尽可能使用已验证的、可靠的技术。

减少类型检查依赖

类型系统在编译阶段就能发现错误，但其自身会引入不必要复杂性。通过松耦合的组件、简洁的接口、严格的调用顺序，也可以构建出可靠的大型系统。

更新于[2025-09-15]

文章参考