相似点
这篇文章open in new window讲的很好
其主要说的是前端框架存在的意义就是解决UI 与状态同步的问题；使用原生JS操作存在以下缺点：
响应式系统保证了View与Modal的同步每一种框架的出现并且火热必然和当下的一些痛点息息相关，从一开始的Jquery的出现，就是为了方便的解决兼容性问题和操作DOM；但是随着浏览器和js的发展；兼容性已经越来越不需要在开发中考虑进去同时也出现了原生的方便操作DOM的方法；到现在的MVC/MVVM模式的出现，因为随着前端项目越来越复杂，前端如何解决UI与状态间的同步成为当代的痛点，而MVC/MVVM通过监听更改和虚拟DOM来帮助实现UI与数据的对应；下一代前端框架可能就是多端统一
模块化指在解决某一个复杂问题或者一系列的杂糅问题时，依照一种分类的思维把问题进行系统性的分解后处理，模块化是使复杂系统的代码结构更合理，可维护性更高的可管理的模块的方式，是为了解耦软件系统的复杂性；
直接定义依赖；缺点： 产生大量的全局变量，一不小心就会导致冲突命名空间模式；解决了遍地全局变量的问题；缺点：这种方式同样没有安全性，变量可以随意更改闭包(IIFE)模块化模式;缺点：没有解决如何管理模块的问题，或者在使用时无法清晰描述出模块的以来关系CommonJS是服务器端模块的规范，是同步方案(打包工具webpack等可以实现浏览器端的支持)AMD(requireJS)&CMD(SeaJs)是浏览器端的模块化，异步方案，按需加载；AMD&CMD区别Umd是AMD和CommonJS的集合(function (window, factory) {
if (typeof exports === 'object') {
module.exports = factory();
} else if (typeof define === 'function' && define.amd) {
define(factory);
} else {
window.eventUtil = factory();
}
})(this, function () {
//module ...
}
);
ES2015 Modules是现代的模块化方案；在编译时就能确定模块的依赖关系未来的模块化肯定是在原生支持模块化的同时，分别增加对css和html的模块化，需要browser端的支持，而不是webpack/rollup 等构建工具的支持
针对复杂且大型的web前端分解成一些更小、跟简单、松耦合的能够独立开发部署的小应用，最常见的解决方案就是在运行是集成（ iframe、JS、Web Components ）：
参考open in new window、框架:乾坤open in new window
| # | 压缩方式 | 动画 | 透明度 | 兼容性 | 适应场景 |
|---|---|---|---|---|---|
| JPEG/JPG | 有损 | 不支持 | 不支持 | 所有 | 呈现色彩丰富的图片 |
| PNG | 无损 | 不支持 | 支持 | 所有 | 呈现小的 Logo、颜色简单且对比强烈的图片或背景等 |
| GIF | 无损 | 支持 | 支持 | 所有 | 呈现动画 |
| SVG | 无损 | 支持 | 支持 | >IE8 | 图片由标准的几何图形组成，或需要使用程序动态控制其显示特效 |
| webP | 有损 | 支持 | 支持 | chrome、opera | 不考虑兼容 |
tree shakinghash替换为chunkhash实现缓存优化gzip雪碧图、base64、字体图标等方式加载301来做永久重定向CDN<link rel="dns-prefecth" href="https://www.**.com">进行DNS预解析域名拆分,主要是为了增加浏览器下载的并行度KeepAlive减少与服务器建立链接的次数或启用http2.0css放在head中js放在尾部defer、async）preload当前页资源预加载prefetch下页资源预加载srcset设置响应式的图片,实现加载更合适的图片content-visibility：auto优化长列表DocumentFragment对象，让变化先发生在内存中innerHTML到页面requestAnimationFrame此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。