组内做的一个分享，把文字稿搬过来存一下。

同为程序员，在细分工种下，前端和其他方向的一个最大的区别就是除了写代码之外，还要和视觉层面上的图形打交道，对我来说这也是前端最大的魅力，因为我深知图形之美以及其奥妙之处。不过并不是所有前端都会深入图形领域，但对于所有前端来说有一门图形相关的入门课倒是必修的，那就是图标管理了。

目前最主流的前端方案都是以组件为基本单位构建一个单页应用程序，通过REST API和后端交互，最终将所有前端代码打包为静态资源部署，如果有SEO需求，会采用服务端渲染方案，前后端分别打包再做同构。这套方案确实能应付绝大多数中小型应用场景，但量变会产生质变，随着业务发展，前端会越来越臃肿，可能组件=>应用的结构会慢慢演变成组件=>服务=>应用，不同的服务由不同的项目组负责开发，甚至会有接入完全不同技术栈的服务的需求，作为这个大型单页应用的一部分，至此不同服务之间就会有不小的沟通成本，代码编译打包性能，开发体验也会迅速下降，急需一种更有层次的解耦方案。受到后端微服务的启发，前端微服务架构也就应运而生。

相比于Vue的高度封装和自动化，React给予了开发者更高的自由度，但相对的，就要更注重性能优化相关的问题，这里就以React为入口总结一下前端应用开发中需要注意的一些常规性能优化点。

我们知道常规单页应用最终都会被webpack打包为若干js，css，入口html和各种静态资源，从http请求到入口html资源到整个应用准备完成经历了不少阶段，这篇文章就按照时间顺序分别介绍其中可优化的点。

目前浏览器已经提供了不少存储相关的API，比如localStorage,application cache等，以及各种缓存相关的策略，memory cache, disk cache等。这些方案各有优缺点，但无论哪种方案要实现精确的强缓存都存在难度，不可避免的耦合缓存检测相关的代码到主代码中。而基于Service Worker的缓存解决方案可以将检测与缓存逻辑和主代码完全解耦，并利用浏览器本身的特性平滑的控制缓存文件。

这篇文章用来梳理Webpack使用各个流程中常用的一些插件并长期更新，以便以后使用的时候能够快速索引。

loader和plugin可以说是Webpack的两大支柱功能了。相较于loader专注于模块类型的转化，plugin提供了更为广阔的功能，原因就在于其能直接通过编译生命周期钩子影响webpack编译流程，实现强大的自定义功能拓展。这篇文章就来分析下plugin的运作原理。

现在的Web页面越来越复杂并向着web app的方向演化，这意味着前端将会有着大量的代码。而一个复杂又庞大的代码库必然需要模块系统来分治，既然有了模块系统就少不了模块依赖的管理与打包，这就是Webpack的主要职责了。当然关于模块化的演进有许多东西可以讨论，今天主要还是从目前最流行的Webpack开始学习。