zhangyuang · zhangyuang · Apr 25, 2021 · Apr 6, 2021 · Apr 6, 2021 · Apr 12, 2021
diff --git a/docs/public/images/homepage.png b/docs/public/images/homepage.png
diff --git a/docs/web/config/index.ts b/docs/web/config/index.ts
@@ -27,7 +27,7 @@ export const webSiteConfig = {
         label: '查看文档',
         path: '/docs/why'
       },
-      imgUrl: '/images/logo.jpeg'
+      imgUrl: '/images/homepage.png'
     },
     secondFloor: {
       title: '为什么要选择 SSR',

diff --git a/docs/web/markdown/api/config.md b/docs/web/markdown/api/config.md
@@ -223,8 +223,8 @@ module.exports = {
 }
 ```
 
-2. 我们通过 `chainWebpackCobfig` 的方式来让用户可以修改默认配置
+2. 我们通过 `chainWebpackConfig` 的方式来让用户可以修改默认配置
 
-但绝大部分情况下你不需要去修改默认的配置。我们默认的配置是基于 `create-react-app` 生成的配置上做了一些优化。已经极力做到最优。如果确定需要修改默认配置，应该先看看配置有无提供额外选项直接设置，而不是通过 `WebpackChain` 工具去重新设置规则。这样极易导致错误。
+但绝大部分情况下你不需要去修改默认的配置。我们默认的配置是基于 `create-react-app` 生成的配置上做了一些优化。已经极力做到最优。如果确定需要修改默认配置，应该先看看配置有无提供额外选项直接设置例如 `css.loaderOptions` ，而不是通过 `WebpackChain` 工具去重新设置规则。这样极易导致错误。
 
 我们后续可能会兼容一些 `vue-cli` 支持的配置，但不是全部。我们并不打算做成大而全的工具这样只会变成大黑盒。配置越多只会增加错误出现的可能性。参考 `vue-cli` 工具 400多个文件，3w 行源码 580个待解决 `issue`。
diff --git a/docs/web/markdown/why.md b/docs/web/markdown/why.md
@@ -106,23 +106,20 @@
 
 ## 方案对比
 
-与 `Next.js/Nuxt.js` 等框架的对比，详细的代码层面技术细节对比可以查看本人在2020年 [Node.js party 上所做的分享](https://github.com/zhangyuang/2020-NodeParty-PPT)，从以下 9 个技术细节方面与 Next/Nuxt/Easy-team 等等框架的做法进行对比。  
-相比于此 PPT 介绍的 2020 年的版本，我们最新的版本在此基础之上又做了许多优化。包括插件化的改造以及支持 `Vite`，优化渲染逻辑等等。相比于 Next/Nuxt 的一堆 [issue](https://github.com/vercel/next.js/issues)， 当你深度使用本框架时你会发现你几乎不会遇到什么问题。
+与 `Next.js/Nuxt.js` 等框架的对比，详细的代码层面技术细节对比可以查看本人在2020年 [Node.js party 上所做的分享](https://github.com/zhangyuang/2020-NodeParty-PPT)，从以下 9 个技术细节方面与 `Next/Nuxt/Easy-team` 等框架的做法进行对比。  
+相比于此 PPT 介绍的 2020 年的版本，我们最新的版本在此基础之上又做了许多优化将会在本文档进行讲述。包括插件化的改造以及支持 `Vite`，优化渲染逻辑等等。相比于 `Next/Nuxt` 的一堆 [issue](https://github.com/vercel/next.js/issues)， 当你深度使用本框架时你会发现你几乎不会遇到什么问题。无论如何，仔细阅读本文档，你会对服务端渲染应用有更加深度的认知。
 
 以下简单介绍一下比较显著的优点
 
 - 优先考虑 `Serverless`，我们为应用在 `Serverless` 场景使用做了诸多优化包括内置发布命令一键发布到多个平台，以及对 `Serverless` 场景下的代码包大小优化，事实上本文档的源代码便是直接用本框架进行开发以及部署的
 - 轻量，核心源代码 2400 行 vs Next.js 18w 行 vs Nuxt.js 2w行，简洁的核心代码意味着更少的黑盒以及更少的性能损耗，事实上我们的性能等于直接调用框架提供的原生 API 无任何中间层
 - 最轻量级的方式支持 [Vite](./features$vite)
 - 没有恶心的 `.next`, `.nuxt` 这种隐藏文件夹包含着几万行通过 `模版渲染/Webpack` 打包出来的可读性极差的代码，当你的应用出错时，你几乎无法从这些隐藏文件中获得任何有效信息
-- 接地气，在 SSR 场景使用 UI 框架是一件不简单的事情，我们内置对世界上最流行的 UI 框架 ant-design 的支持。无需用户做额外配置
+- 接地气，在 `SSR` 场景使用 `UI 框架`是一件不简单的事情，我们内置对世界上最流行的 UI 框架 `ant-design` 的支持。无需用户做额外配置
 - 没有传统模版引擎，多数开发者是都十分厌恶使用传统模版引擎且需要引入额外的库和学习成本。我们没有使用类似于 `nunjucks` `ejs` 这种模版引擎，根据场景 `All in JSX` 或者 `Vue SFC` 来编写 html 布局
 - 没有 `style-loader`，不存在本地开发使用 style 标签，线上环境使用独立 css 文件这种开发体验割裂的情况。我们统一使用独立的 css 文件且支持 HMR 和动态加载
-- 风格统一，无论是 React/Vue 运行的本质始终都是 js，我们在两种框架的 SSR 实现思路一模一样，实现代码的高度复用，使用本框架无论是从 React 切换成 Vue 或者反过来都十分轻易
+- 风格统一，无论是 `React/Vue2/Vue3` 运行的本质始终都是 `js`，我们在这些场景的 SSR 实现思路一模一样，实现代码的高度复用，使用本框架无论是从 `React` 切换成 `Vue` 或者反过来都十分轻易
 - 功能丰富，UI 框架、代码分割、HMR、TS、Serverless、SSR 降级 CSR 开发所需要的功能应有尽有
 - 示例丰富，默认示例 cover 大多数真实线上应用场景，包含 服务端框架选择、前端调用 Node.js 接口的方式、前端页面路由跳转的数据获取，应用部署等所有功能用例在 example 中都有体现。我们拥有丰富的线上大规模 SSR 应用开发经验，用户使用过程中遇到的任何问题都有策略解决。
-- 没有 runInNewContext，我们不像其他框架的做法一样使用 vm 模块创建上下文来解析服务端 bundle，所以我们的性能是极高的。
+- 没有 [runInNewContext](http://nodejs.cn/api/vm.html#vm_script_runinnewcontext_contextobject_options)，我们不像其他框架的做法一样使用 vm 模块创建上下文来解析服务端 bundle，所以我们的性能是极高的。
 
-## 总结
-
-个人看法来说，我并不喜欢 `Next/Nuxt` 等设计理念高度 template 化的框架。虽然要做好一个优秀的 SSR 框架非常不容易有许多细致的点需要关注，但我仍然认为它们把这件事情做的过于复杂了。除了具有除了巨无霸级别的源码以及极度黑盒的内部运行机制以外。在性能以及扩展性方面都是灾难性的。例如想要接入 `Vite`，或者做渲染降级在这些框架上都是非常困难的一件事。举个例子一个非常简单的需求我需要不同的页面渲染不同的 `meta` 标签以及 `title` 等信息，在大部分情况下都需要配合使用 [react-helmet](https://www.npmjs.com/package/react-helmet) 或者 `next/head` 这些库来完成。而仅仅这些库的复杂度本身就比整个 `ssr` 框架的复杂度都要高。而在 `ssr` 框架，要完成这个逻辑是非常简单的无需使用任何第三方模块。同样在整个 `ssr` 框架的实现过程，我们没有新造任何轮子。任何功能的实现都是基于社区已有的非常优秀的模块来实现。继续阅读下文你会得到更加详细的了解。