diff --git "a/128.\347\262\276\350\257\273\343\200\212Hooks \345\217\226\346\225\260 - swr \346\272\220\347\240\201\343\200\213.md" "b/128.\347\262\276\350\257\273\343\200\212Hooks \345\217\226\346\225\260 - swr \346\272\220\347\240\201\343\200\213.md"
index 43084450..7e608e03 100644
--- "a/128.\347\262\276\350\257\273\343\200\212Hooks \345\217\226\346\225\260 - swr \346\272\220\347\240\201\343\200\213.md"	
+++ "b/128.\347\262\276\350\257\273\343\200\212Hooks \345\217\226\346\225\260 - swr \346\272\220\347\240\201\343\200\213.md"	
@@ -408,7 +408,7 @@ return {
 
 ### 3.5 依赖的请求
 
-翻了一下代码，没有找到对循环依赖特别处理的逻辑，**后来看了官方文档才恍然大悟，原来是通过 `try/catch` 并巧妙结合React的UI=f(data) 机制实现依赖取数的。**
+翻了一下代码，没有找到对循环依赖特别处理的逻辑，**后来看了官方文档才恍然大悟，原来是通过 `try/catch` 并巧妙结合 React 的 UI=f(data) 机制实现依赖取数的。**
 
 看下面这段代码：
 
@@ -445,10 +445,9 @@ useIsomorphicLayoutEffect(
 
 ```
 
-每次渲染的时候，SWR会试着执行`key`函数（例如 () => "/api/projects?uid=" + user.id)，如果这个函数抛出异常，那么就意味着它的依赖还没有就绪（user === undefined），SWR将暂停这个数据的请求。在任一数据完成加载时，由于`setState`触发重渲染，上述Hooks会被重选执行一遍（再次检查数据依赖是否就绪）然后对就绪的数据发起新的一轮请求。
+每次渲染的时候，SWR 会试着执行 `key` 函数（例如 () => "/api/projects?uid=" + user.id)，如果这个函数抛出异常，那么就意味着它的依赖还没有就绪（user === undefined），SWR 将暂停这个数据的请求。在任一数据完成加载时，由于 `setState` 触发重渲染，上述 Hooks 会被重选执行一遍（再次检查数据依赖是否就绪）然后对就绪的数据发起新的一轮请求。
 
-
-另外对于一些正常请求碰到error（shouldRetryOnError默认为true）的情况下，下次取数的时机是：
+另外对于一些正常请求碰到 error（shouldRetryOnError 默认为 true）的情况下，下次取数的时机是：
 
 ```tsx
 const count = Math.min(opts.retryCount || 0, 8);
diff --git "a/133.\347\262\276\350\257\273\343\200\212\345\257\273\346\211\276\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\345\271\263\350\241\241\347\202\271\343\200\213.md" "b/133.\347\262\276\350\257\273\343\200\212\345\257\273\346\211\276\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\345\271\263\350\241\241\347\202\271\343\200\213.md"
new file mode 100644
index 00000000..09c23b0d
--- /dev/null
+++ "b/133.\347\262\276\350\257\273\343\200\212\345\257\273\346\211\276\346\241\206\346\236\266\350\256\276\350\256\241\347\232\204\345\271\263\350\241\241\347\202\271\343\200\213.md"
@@ -0,0 +1,207 @@
+## 1 引言
+
+[尤雨溪](https://github.com/yyx990803) 在 2019 JSConf 的分享 [Seeking the Balance in Framework Design](https://www.youtube.com/watch?v=ANtSWq-zI0s) 十分精彩，道出了如何进行合理的前端框架设计与框架选型。
+
+正如所说，框架对比不能只停留在 Star 数量、Npm 下载量、Stackoverflow 问题量这些简单的数据对比，而要深入到技术细节进行比较。比较框架有多种不同维度，这次分享就从服务范围、渲染机制、状态机制这三个维度进行对比。
+
+## 2 概述
+
+这次分享的精彩之处在于不偏不倚的站在客观立场分析了框架各维度好的一面与坏的一面，从中我们不仅能学习到一些框架知识，还能培养思辨能力。
+
+### 服务范围
+
+服务范围是个比较难翻译的单词，在原 PPT 中用了 “Scope” 这个单词表示，可以理解为 “作用域、框架的承诺功能范围、服务配套齐全程度”。比如提供的是一个工具库还是整体框架，插件管理是集中式还是依赖生态。
+
+React 是典型的小服务范围框架，核心包只实现了基本功能，而其他生态基本靠社区拓展；Angular 是典型大服务范围框架，官方对所有业务场景都做了最佳实践能力覆盖；Vue 处在中间区域，通过功能分层，既拥有小服务范围的能力，又可以搭配官方插件实现更多场景化能力。
+
+#### 小服务范围优势
+
+**概念少，易上手**
+
+小的服务范围代表了小的学习成本，因为暴露的基本能力较少，概念也会比较少，对新人上手比较友好。
+
+**生态繁荣，百花齐放**
+
+由于很多功能没有被官方实现，社区就有机会填补这些空白，因此会冒出许多第三方库，而且一旦做得好，就有机会成为 “事实标准”，因此开发者会更加积极参与到社区开发，自己做的框架 “上升空间” 也非常大。
+
+同时，社区的力量会导致多元化，因此整体生态完整度与创新性都会非常亮眼，而且具有持续迭代的能力。
+
+**核心维护成本低**
+
+官方维护的核心代码较少，因此维护成本大大降低，而且官方可以将精力放在更多核心能力增强上，比如 Suspense 等，而不是将精力消耗在生态插件上。
+
+#### 小服务范围的劣势
+
+**复杂场景要引入新概念**
+
+复杂场景无法支持时，就要引入新的概念解决，这导致后续技术选型可能产生分歧，并带来持续的新概念理解成本。
+
+**非官方的开发模式逐渐产生**
+
+随着时间的流逝，会逐渐涌出一些新的设计模式，成为当下几乎是必不可少的方案，但却不会出现在官方文档中，造成选型时的疑惑。Redux 就是一个例子。
+
+**生态变化快，碎片化且持续流失**
+
+非官方的生态也意味着不稳定，而且缺乏统一的管理，碎片化的模块之间可能经常出现不兼容的问题。
+
+而且任何模块都可能被时代无情的淘汰，就像 Flux 到 Redux 再到 Hooks，带来额外的迁移成本和认知成本。谁也不希望自己的项目架构 “变得过时”，或者随时面临被新架构取代的风险，但第三方社区几乎一定代表未来会出现一种模式取代现有模式，只是时间早晚而已。
+
+#### 大服务范围的优势
+
+**大部分业务场景都被内置解决**
+
+减少不必要的技术方案调研与纷争，大服务范围的框架内置的方案就能解决几乎 100% 业务问题，团队再也不会为通用架构问题烦恼了。
+
+**生态稳定、连贯**
+
+稳定是指，官方维护作为背书，几乎不会存在一些生态包突然不维护、与已有版本不兼容、被植入恶意程序等等意外情况。
+
+连贯是指，官方会统一考虑一个改动在所有生态插件造成的影响，并以一个最合理的思路做整体改造，生态包无论是接口还是兼容性都不需要担心，设计思路也会一脉相承。
+
+#### 大服务范围的劣势
+
+**前期上手成本高**
+
+全家桶的概念导致上手难度偏高，因为必须理解所有内置概念后才能开始项目。
+
+**如果内置模块无法满足业务，会觉得有些死板**
+
+一旦发生内置功能无法满足业务的场景，就很难拓展了，因为 all in one 的思路本质上就是排斥自定义拓展的，这点从 [angular-cli](https://github.com/angular/angular-cli) 就能看出来。
+
+之所以觉得死板，是因为这种情况没办法用优雅的方式解决，只能在现有约束的框架内通过某些 “Hack” 方式解决，自然会有种死板的感觉。
+
+#### 中等服务范围的优势
+
+**分层设计，允许新特性渐进加入**
+
+Vue 通过分层设计做到了折中，即官方还是会维护生态，只不过生态不是必须的，可以按需使用。这样做的好处是兼顾了一些优势。
+
+**低学习门槛**
+
+与小服务范围框架一样，对于核心包来说学习成本都比较低。
+
+**依然有最佳实践解决所有业务问题**
+
+和大服务范围框架一样，拥有全套官方最佳实践，但不内置，不强求一定要使用，因此你可以按需使用。
+
+#### 中等服务范围的劣势
+
+**维护成本高**
+
+和大服务范围框架一样，虽然生态不强求，但毕竟官方还是要持续维护的，因此维护成本高的问题依然存在。
+
+**生态多样性不高**
+
+虽然生态是按需的，但毕竟中等服务范围的框架官方会实现一套标准生态插件，这会极大影响社区生态的发展空间，导致 “非官方插件没人愿意做”，因此生态多样性会差一些。
+
+### 渲染机制
+
+渲染机制区别主要在 JSX vs Template 之间，不同的表达方式之间还是存在一些很本质的区别，然而正如一开始所说，无法一言蔽之，必须从多个角度拆解的看。
+
+#### JSX 的优势
+
+**纯 JS 表达 UI**
+
+单这一点就非常重要了，满足了 All In Js 的幻想。毕竟 Html、Css 相比 Js 来说，模块化能力和灵活性都很弱，将其都收敛到 Js 不仅表达方式更统一，更重要的是都获得了与 Js 一样的模块化、灵活性、Typescript 支持等能力。
+
+**视图即数据**
+
+将视图看作一种数据，让针对视图的逻辑测试成为可能。
+
+同时也将视图概念泛化了，因为数据是平台无关的，一份描述视图的 DSL 可以运行在任何平台。
+
+#### JSX 的劣势
+
+**开销大**
+
+页面节点越多，Diff 开销就越大。
+
+**动态渲染很难性能优化**
+
+由于所有 DOM 节点都是动态生成，因此无法根据初始状态结构进行安全的优化。相比之下，Template 模式可以确定哪部分属于变量，哪部分是固定的，对固定部分的 Diff 检测都可以跳过。
+
+**动态调度虽然改善了性能，但依赖更重的运行时**
+
+React ConcurrentMode 是一个调度优化器，但实现的逻辑也比较复杂，加重了运行时负担。
+
+#### Template 的优势
+
+**原生性能**
+
+由于 Template 对节点进行直接渲染，因此与原生性能一致。
+
+**Runtime 更小**
+
+由于不需要额外优化，运行时代码会小很多。
+
+#### Template 的劣势
+
+**被 Template 语法约束，且无法拓展**
+
+对于 Template 不支持的，只能选择接受，因为除了框架自己，没有人能拓展 Template 的特性。当遇到一些非常动态场景，但 Template 不支持的情况，只能选择接受，并用比较 Hack 的方式绕过解决，除此之外别无他法。
+
+**模版冗长**
+
+JSX 可以利用循环语句或者变量赋值进行模版区块的复用，但 Template 模式每次新模版都要一行一行的打出来，这种冗长的开发体验不太友好。
+
+**运行时解析开销或者依赖编译期逻辑**
+
+要么通过编译器预先生成 AST，要么运行时动态将 Template 解析成 AST，无论哪种方案都有额外的开销，一种是工程依赖的开销，一种是运行时动态解析的性能开销。
+
+#### VDom + Template 的特色
+
+Vue 在 Template 基础上支持了虚拟 DOM，因此兼具两者特色。
+
+性能上，在编译时就进行 AST 解析，减少了运行时解析开销。
+
+功能上，支持模版与 JSX 两种语法。
+
+### 状态机制
+
+状态机制 [尤雨溪](https://github.com/yyx990803) 在 JSConf 提到要单独拆出来讲，因为内容较多，时间可能不够，本次精读也限于篇幅原因略过：
+
+- Mutable vs Immutable。
+- 依赖追踪 vs 脏检测。
+- 响应式 vs 模拟响应式。
+
+显然，状态机制方案更是仁者见仁智者见智的事情，同样得从多个维度进行独立分析，并根据实际业务场景具体选择。
+
+最后，意识到没有一个绝对均衡的框架设计方案，因为在工程领域，没有最好只有更好。
+
+## 3 精读
+
+我们再延伸谈一谈为什么框架设计要寻找平衡点。
+
+**框架设计没有银弹**
+
+与数学公式不同，框架设计甚至整个工程技术设计都没有所谓的真理，所谓条条大路通罗马，实现同一个技术目标的众多方案之间也许就是平行关系，可以根据不同维度列出一二三的对比，但无法得出一个总的结论，孰优孰劣。
+
+**使用场景不同**
+
+不同使用场景决定了对框架诉求的不同。
+
+比如开发非常定制、炫酷的可视化大屏，那么前端开发框架基本也用不上，因为关注点不会聚焦在项目路由、UI 描述、甚至是数据流，而是聚焦在性能、图形渲染等问题。解决这些领域的框架可能是 虚幻 4、Unity 等游戏引擎，但普通的前端开发框架绝不会涉足这种领域，框架一定要确定自己功能范围。
+
+即便仅局限在 Web 领域，也需要考虑是否要支持非 Web 场景，那么将 HTML 抽象成一个通用 DSL 就可能是一种选择，但非 Web 领域毕竟不是主打业务领域，在这种业务场景周边生态维护可能就比较少，这也是需要取舍的地方。
+
+**使用的人不同**
+
+不同团队对框架的要求也不同。
+
+刚起步的小团队可能更需要保姆式的框架，因为这样最节省人力成本。对于规模较大的团队，希望对框架拥有较大定制能力时，小服务范围的框架可能更受青睐。当然框架作者可以像 Vue 一样做出渐进式官方能力增强方案，以此满足不同需求的用户，但毕竟也不能将生态完全交给社区，还是要做取舍。
+
+所以当遇到更新更酷的框架时，需要冷静思考的不只是这个框架带来的收益与花费的迁移成本哪个更高，以及团队能否接受这套框架的开发习惯，更需要思考的是这个框架自身做了哪些权衡，如果这些权衡与 React、Vue、Angular 类似，那么仅仅变化了语法或者语言的改动其实意义不大，此时需要慎重考虑。
+
+## 4 总结
+
+这次没有提到的状态机制对比，你能分别列举出优缺点吗？欢迎留言。
+
+> 讨论地址是：[精读《寻找框架设计的平衡点》 · Issue #223 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/223)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）