---
title: "为什么需要 Farm？"
locale: "zh"
version: "1.x"
canonicalUrl: "https://farmfe.org/zh/docs/1.x/why-farm"
publicationStatus: "prerelease"
---
# 为什么需要 Farm？
## Farm 是什么？
Farm 是一个非常快的基于 Rust 的 Web 构建工具，类似 ` webpack ` 和 ` vite `，但**更快**。 farm ` resolve, load, transform ` 所有 ` asset(js/jsx/ts/tsx、css/sass/less、html、静态资源、json 等) `，并将它们打包成一系列` 可部署文件 `。 Farm 是一个速度极快的构建工具，可帮助您构建更快的 ` web/nodejs ` 应用程序。
## 为什么需要 Farm？
随着 web 项目规模的扩大，构建性能已经成为主要瓶颈，对于一个庞大的项目，使用 webpack 编译可能需要 10min 甚至更多，一次 hmr 更新可能需要 10s 甚至更多，严重降低了研发效率。
因此我们急需极速的构建工具，解决项目编译性能问题。然后 vite/snowpack 这样的 unbundled 工具应运而生，此类工具主要有下面三个特性：
1. 使用原生 ESM，在 dev server 启动时**不对**源文件进行编译和打包，源文件在入口模块执行时才会通过浏览器请求 dev server 编译，编译后的产物返回给浏览器
2. HMR 时，只重新编译一个模块，这样 HMR 的时间约等于一个模块的编译时间
3. 对外部依赖（如 node\_modules 下的依赖）进行预打包
这使得 dev 服务器热启动和 HMR 非常快，但 vite 等工具使用的 Unbundled 模式并不完美，对于大型项目来说仍然存在很大的问题：
- **大量的模块请求**：对于一个大型项目，使用上述策略 1、2，首次启动可能需要加载数千个模块，使用原生模块系统加载数千个模块会导致浏览器卡住甚至崩溃。虽然 Dev Server 的启动快了，但是请求时的模块的首次编译依然会耗费大量时间，会有数十秒起步的白屏，编译时间只是转移了，并没有消失。
- **开发和生产之间的不一致**：出于兼容性和请求数量、请求层级的考虑，原生 ES 模块在大多数情况下无法在生产中使用。 因此 vite 选择在生产环境选择用 rollup 打包。 这就带来了不一致，当这种不一致导致生产错误时，调试起来非常困难且非常痛苦。 而 vite 在 dev 中使用 esbuild，在生产中使用 rollup，这更加就放大了不一致性。
- **拆包优化困难**： 受限于 Rollup，拆包配置不够灵活、易用。
- 而 Vite 在 dev 上之所以这么快，esbuild 功不可没，它是用 go 编写的。 Go 利用了原生平台的优势，远快于 Js。
事实上，我们真正需要的是一个快速、强大、一致的 Web 构建工具，可以在解决上述问题的基础上，提供更加极致的编译效率。因此我们设计并开发了 Farm。
不过 Farm 不仅仅是一个用 Rust 重写的打包工具，它还有很多强大且先进的设计：
## Farm 设计理念
- **性能优先**：一切都会用 Rust 编写，只有少数不是性能瓶颈的部分会用 JS 编写
- **一致性**：默认情况下确保开发和生产完全相同，您在开发中看到的将与您在生产中得到的相同。
- **局部打包**：Farm 的打包目标不是将所有东西打包在一起，而是限制资源的请求数量。 Farm 会根据依赖关系和资源大小将您的项目捆绑成 20-30 个小资源，在不损失缓存粒度的情况下获得最佳的资源加载性能。
- **所有资源视为一等公民**：Farm 不再需要将所有内容转换为 Javascript，它将任何内容视为一等公民，如 ` html `、` js/jsx/ts/tsx `、` css/scss `、` png/svg/... `都是 Farm 支持的基础模块，更多类型的模块可以通过插件支持。
- **兼容性**：Farm 将适用于旧版 (ES5) 和现代浏览器。
- **Rollup 风格的插件系统**：轻松创建自己的插件，并轻松从 ` rollup/vite/webpack ` 迁移您的插件/项目。兼容 ` Vite/Rollup/Unplugin ` 插件
Farm 的目标是成为真正的下一代构建工具，快速、强大、一致，并为 Web 开发人员提供最佳的开发体验。