最后更新于 2022-08-06 00:21:00
前端工程化是在做与业务开发完全不同的事情，旨在解决软件工程领域与开发者密切相关的问题，通常会将其与基建开发、DevOps 放在一起讨论。前端开发是复杂的，其结合了 HTML/CSS/JavaScript 3 种语言，甚至还有很多其超集，没有开箱即用的工具链，不像 Java Web 开发、Android 开发等等有官方或者商业领域非常成熟的工具可以利用，一切都源于开源社区的从 0 开始构建。正因如此，前端工程化领域百花齐放，开放与创新展现的淋漓尽致，这也是前端开发者了解学习软件工程的机会。
最后更新于 2022-06-12 22:22:00
对于 Web 的图表组件库来说，一些功能比较强大的开源库，渲染层可以支持 DOM、SVG、Canvas、WebGL 等多个平台的环境，而图表库的很多功能的实现都和渲染层紧密相关。
最近，在参考学习一些开源的图表组件库时，发现在跨平台设计中，事件机制的实现很有意思，所以在这里以最简化的代码来解释和记录一下这个方案。如果要用经典的软件设计模式来解释，大概就是桥接模式了。
桥接模式（Bridge Pattern） 将一个功能的实现拆分为抽象（Abstraction）和实现（Implementor），让其相互独立的扩展和定义，借助该模式可以设计一种平台无关的软件架构。
最后更新于 2022-05-03 16:43:00
一直以来，开源精神被开发者所推崇，开源项目为开发者提供了不用付出除时间以外任何成本就可以学习前沿技术的最佳途径，另一方面，我们应该思考开源为何会成功，在全球开发者参与协作的情况下代码仓库为何能保持整洁、不出现大规模冲突而奔溃，上下游依赖如何管理，这背后有既定的规范进行强约束，也有一系 列社区工具来完成复杂而有价值的工作。所以，从参与或者维护开源项目的角度来看，这些社区公认的最佳实践值得我们了解，学习这些东西也能在一定程度上提高我们管理项目的能力。
最后更新于 2022-01-09 17:36:00
TypeScript 作为 JavaScript 的超集，为 Web 开发带来了强类型语言和类似代码智能提示这种良好的开发体验，而代码提示依赖于类型定义文件。类型定义文件的发展也经历了一个逐步演变的过程，从最初基于 JavaScript 编写的 npm 包，通过社区方案来引入类型定义包，再到目前多数模块基于 TypeScript 编写并在发布时带上类型定义文件这种最佳方案，开发者体验得到进一步的提升。
不过，在使用类型定义文件的过程中我们通常需要和类型定义进行交互，大多数场景可以通过泛型来解决；而有一个典型场景就是需要我们扩展第三方库的类型定义，避免在多个文件中编码时都要引入类型定义的麻烦。可能不是很好理解，在这里通过一个实际的例子就可以解释清楚。
最后更新于 2021-12-08 21:12:00
Web 网页为了保证在多个平台和低中高端设备上的体验稳定性和一致性，通常会做 Polyfill 以保证兼容性。
然而，兼容性问题本身是个难题，Polyfill 也并非很好处理，所以在技术演变的过程中，社区达成了一致，有一个主流的方案，大家共同来使用和维护。当下社区的主流方案则是基于 core-js，另一方面， 利用 ESLint 插件则可以做到自动检测代码中需要添加 Polyfill 的 API。
core-js 只是解决了 JavaScript 的兼容性问题，Web 网页还有 CSS / HTML / Web API 的兼容性问题，处理这些问题的过程中，必然会存在大量相似的逻辑，比如目标设备的检测、目标设备的 API 支持情况统计。当然，社区也给出了非 常好的方案，下面就来了解一下。
最后更新于 2021-12-05 16:47:00
对于经常看纯技术书籍的人来说，难免会感觉到烦闷，阅读 纯技术书籍的过程通常是非常消耗人的，不像看小说，是一个享受和放松的过程。所以，借此机会，找到一本与技术相关但并非纯粹的技术教程类书，讲解了 UNIX 诞生的历史和之后发展壮大的过程，虽然相比于小说还是略有枯燥，但其中也不乏精彩之处，对于一个技术研发成果，从多个角度阐述和讨论，也会让作为从事技术开发工作的人来说有一定的启发。
最后更新于 2022-05-07 21:57:00
Web 前端项目出于加载性能优化和安全考虑，在生产环境部署的代码是经过混淆和压缩的，对于利用生产环境收集到的错误堆栈信息要进行调试是非常具有挑战性的。理想情况下，应该在生产环境收集错误堆栈信息，然后映射到源码进行调试。恰好，SourceMap 文件提供了这个机制，可以将编译（压缩）后的代码映射到源代码中。
最后更新于 2021-11-18 00:14:00
基于 React.js 的 Web 应用如何完成状态管理？社区主流方案是 react-redux，其本质上基于 React 的 Context 特性实现，如果应用足够简单，实际上用 Context 手写一个简单的状态管理工具倒也并不难。不过，考虑到工具的完善性、项目的健壮性，通常采用较好的、成熟的社区方案。在移动端场景下，react-redux 略显臃肿，轻量级状态管理工具 zustand 倒是一个不错的替代方案。
最后更新于 2022-03-10 00:28:00
利用 JS 开发的原生应用与依赖于 React.js/Vue 开发的框架/库应用，性能孰高孰低？这两者最显著的区别在于原生应用需要手动操作 DOM 完成业务，而框架/库应用 是基于数据变化响应式的应用，后者只需要关注数据如何变化，至于体现在 DOM 上的变化皆由框架/库内部自动完成。所以，要搞清楚两者的性能优劣，可能批量的 DOM 操作是一个不可忽略的核心因素。从代码执行的角度分析，框架/库也是基于原生 API 进行的封装抽象，因此代码执行时的路径更长、堆栈更深，由此可见原生 API 的操作性能应该是最高的。但是，现实情况是业务通常来说是复杂的，代码实现中 DOM 操作的逻辑分散在各处，那么多个 DOM 操作之间是否会产生影响从而不利于性能？这个时候就要关注宿主浏览器的渲染机制是如何理解批量的 DOM 操作的，这里引入的概念就是关键渲染路径（Critical rendering path）。
https://developer.mozilla.org/en-US/docs/Web/Performance/Critical_rendering_path > https://developers.google.com/web/fundamentals/performance/rendering
最后更新于 2022-03-06 23:28:00
能在真实业务场景中落地 Web 性能优化方案的机会鲜有，大多数时候业务是较为简单而且要求不高的，前段时间恰好有一个比较核心的业务，对稳定性和性能有一定的要求，在这个过程中也算是做了很多尝试和实践，在此作为案例记录一下分析的过程和最终解决的方案。