fix: re translate about "The Problems" (vitejs#34)

* fix: re translate about "The Problems"

* fix: re translate about "The Problems"

* fix: change the translation about "application"

* fix: re translate about "The Problems"

* fix: re translate about "The Problems"

Author: wjq990112

guide/why.md

@@ -2,13 +2,13 @@
 
 ## 现实问题
 
-在浏览器支持 ES 模块之前，开发者没有一种可以利用的原生机制来以模块化方式编写 JavaScript。这也是我们为什么有了 “打包” 这个概念：使用工具抓取、处理和链接我们的源码模块到文件中，使其可以运行在浏览器中。
+在浏览器支持 ES 模块之前，开发者没有以模块化的方式开发 JavaScript 的原生机制。这也是 “打包” 这个概念出现的原因：使用工具抓取、处理和链接我们的源码模块到文件中，使其可以运行在浏览器中。
 
-在过去我们见过诸如 [webpack](https://webpack.js.org/)，[Rollup](https://rollupjs.org) 和 [Parcel](https://parceljs.org/) ，这些工具大大改进了前端开发者的开发体验。
+时过境迁，我们见证了许多诸如 [webpack](https://webpack.js.org/)、[Rollup](https://rollupjs.org) 和 [Parcel](https://parceljs.org/) 等工具的诞生，这些工具极大地改善了前端开发者的开发体验。
 
-然而，随着我们开始构建越来越多的雄心勃勃的应用程序，我们处理的 JavaScript 数量也呈指数级增长。大型项目包含数千个模块的情况并不少见。我们开始遇到基于 JavaScript 的工具的性能瓶颈：通常需要很长时间（有时甚至是几分钟！）才能启动开发服务器，即使使用 HMR，文件编辑也需要几秒钟才能在浏览器中反映出来。缓慢的反馈会极大地影响开发人员的生产力和幸福感。
+然而，当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。大型项目包含数千个模块的情况并不少见。我们开始遇到性能瓶颈 —— 使用 JavaScript 开发的工具通常需要很长时间（甚至是几分钟！）才能启动开发服务器，即使使用 HMR，文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，迟钝的反馈会极大地影响开发者的开发效率和幸福感。
 
-Vite 旨在利用生态系统中的新进展解决上述问题：浏览器支持原生模块，越来越多 JavaScript 工具使用编译型语言编写。
+Vite 旨在利用生态系统中的新进展解决上述问题：浏览器开始原生支持 ES 模块，越来越多 JavaScript 工具使用编译型语言编写。
 
 ### 缓慢的服务器启动
 
@@ -32,9 +32,9 @@ Vite 通过在一开始将应用中的模块区分为 **依赖** 和 **源码**
 
 当基于打包器启动时，编辑文件后将重新构建文件本身。显然我们不应该重新构建整个包，因为这样更新速度会随着应用体积增长而直线下降。
 
-一些打包器的开发服务器将构建内容存入内存，这样它们只需要在文件更改时使模块图的一部分失活<sup>[[1]](#footnote-1)</sup>，但它也仍需要整个重新构建并重载页面。这样代价很高，并且重新加载页面会消除应用程序的当前状态，所以打包器支持了动态模块热重载（HMR）：允许一个模块 “热替换” 它自己，而对页面其余部分没有影响。这大大改进了开发体验 - 然而，在实践中我们发现，即使是 HMR 更新速度也会随着应用程序规模的增长而显著下降。
+一些打包器的开发服务器将构建内容存入内存，这样它们只需要在文件更改时使模块图的一部分失活<sup>[[1]](#footnote-1)</sup>，但它也仍需要整个重新构建并重载页面。这样代价很高，并且重新加载页面会消除应用的当前状态，所以打包器支持了动态模块热重载（HMR）：允许一个模块 “热替换” 它自己，而对页面其余部分没有影响。这大大改进了开发体验 - 然而，在实践中我们发现，即使是 HMR 更新速度也会随着应用规模的增长而显著下降。
 
-在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文件时，Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失效（大多数时候只需要模块本身），使 HMR 更新始终快速，无论应用程序的大小。
+在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文件时，Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失效（大多数时候只需要模块本身），使 HMR 更新始终快速，无论应用的大小。
 
 Vite 同时利用 HTTP 头来加速整个页面的重新加载（再次让浏览器为我们做更多事情）：源码模块的请求会根据 `304 Not Modified` 进行协商缓存，而依赖模块请求则会通过 `Cache-Control: max-age=31536000,immutable` 进行强缓存，因此一旦被缓存它们将不需要再次请求。