并非又一个框架！

我确信你们很多人看到围绕 Remix 的兴奋之情时，会这样想：

唉，我还没准备好学习新东西...变化太快了！

我理解！学习如何用不同的 API 解决相同的问题让人筋疲力尽。最糟糕的是感觉自己目前工具的深厚知识都过时了，我又成了一个初学者。这确实让人疲惫。

Remix 不是新的吗？它不会让人疲惫吗？

我希望不会！当你使用 Remix 时，你主要是在使用标准的 Web API。你要么已经熟悉它们，要么会第一次学习它们。这些知识不仅能帮助你在 Remix 中构建出色的用户体验，而且今天和未来都会在你使用 Remix 之外有所帮助。这就是为什么我认为在当今这个瞬息万变的 Web 开发世界中，Remix 值得你花时间学习的原因。

不可转移的知识

我以前在一家公司领导前端基础设施团队。在和一位即将离职去新公司的同事聊天时，他们对我说的一句话一直萦绕在我心头：

他们不使用 [我们正在使用的框架]，所以我过去两年在这里学到的一切都无关紧要了！

这句话深深地打击了我。我很讨厌这样。即使它是一个 JavaScript 框架，我们使用的那个框架也有自己独特的方式来做几乎所有事情，甚至向数组中添加元素的方式都不一样。我的同事感觉在这里的时间基本上都浪费了！

当然，所有的编程经验仍然是经验。但当涉及到框架时，通常有很多知识无法转移到下一个框架。在我的职业生涯中，我曾使用过一些框架，它们有大量的 API 需要我去记忆，其中许多 Web 平台已经有解决方案了。这些知识现在基本上都没用了。

当我们设计 Remix API 时，我们会考虑这一点。我们希望你在 Remix 中的经验能够普遍地转移到 Web 开发中。

可转移的知识

这对我来说有点个人化，因为这关系到我如何学习 JavaScript 的。

虽然我在 JavaScript 甚至还没有被创造出来之前就开始了 Web 开发，但我直到 Prototype.js、MooTools 和 jQuery 之间爆发了伟大的框架战争时才真正开始接触 JavaScript。

有一天，我向我的页面添加了一个 jQuery 插件，一切都崩溃了。我已经有了一个 MooTools 插件，这两个插件不兼容！经过一番谷歌搜索，我了解到什么是“JavaScript 框架”，一场战争正在进行，我必须选择一边😲。

我太缺乏经验，甚至不知道如何做出这个决定，但我想到一个有趣的方法，用一定程度的客观性来做出决定：我会用 XHTML 验证器运行它们的首页😂。XHTML 在当时非常流行。我认为，如果一个框架在他们的 HTML 中很用心，那么他们的 JavaScript 也可能很用心。

jQuery 有很多错误，Prototype 有一些，而 MooTools 没有错误！我找到了我的框架。

我真的很高兴我选择了 MooTools，因为在接下来的几个月里，当我学习 MooTools 时，我意外地学习了 JavaScript。

MooTools 的 API 设计非常小心，我至今仍然惊叹不已。MooTools 中的几乎每一个功能都是使用 MooTools 的一些低级 API 实现的，直到你接触到以 JavaScript 本身实现功能的方式实现的核心 API：原型！你可以通过扫描 MooTools 中的第一行代码 来看到这一点。

有一天，我突然明白了。我看到的不是 MooTools，而是黑客帝国，我意识到

... 我知道 功夫 JavaScript！

它诱使我深入学习 JavaScript：从原型到上下文绑定，从对象标识到 DOM。在我的职业生涯中，MooTools 给予我的基础知识帮助我掌握了之后出现的每一个 JavaScript 技术。

MooTools 提供了实用的高级抽象来完成工作，但它是以一种沿途补充我对基础知识的了解的方式来实现的——而不是需要记住的庞大 API。（最终扩展内置原型被证明是一个坏主意，但这故事以后再说。）

React 对我来说也类似。它没有使用特殊的对象和语法来“绑定视图”，而是带来了一种全新的方法，你只需编写 JavaScript 然后说“设置状态！”。所以虽然你确实需要学习一些 React 特有的 API，但你的大部分代码都只是 JavaScript。这是可转移的知识！

学习 Remix，意外地学习 Web

我们明确的目标是设计足够高级的 API 来帮助你完成工作，但又足够接近 Web 来补充你对 功夫 Web 的基础知识的了解。

我们希望你在 Remix 中的经验能帮助你在任何框架中构建更好的网站。实际上，我们希望为你提供成为构建 Remix 之后我们使用的框架的人所需的基础！（但请先给我们几年的辉煌，拜托了，我们有家庭和孩子要养。）

在实践中，这意味着什么？

想想你在 JavaScript 中学到了多少请求/响应 API。Node.js 有一个，express 有一个，aws、azure、Next.js、Netlify、hapi、restify 等等都有它们自己的请求/响应 API。很多是相似的，有些包装了其他 API，但没有一个是 Web 标准。

当浏览器发布 fetch 时，它们也发布了一个用于网络请求和响应的标准 API。我们没有提出我们自己的东西，而是为我们的服务器抽象使用了这个 Web 标准。例如

export function loader({ request }) {
  // request is a web fetch Request!
}

当你学习如何在 Remix 中处理请求和发送响应时，你实际上是在学习浏览器中已有的 Web Fetch API。fetch API 也正在新兴的边缘平台（如 CloudFlare workers 和 Deno）中被采用。这个知识是可以转移的！

这种理念也驱动着 Remix 中的其他几个 API

• 数据突变被建模为 HTML 表单。你编写一个普通的表单，然后 Remix 管理服务器通信，为你的应用程序提供所有状态以构建最现代的 Web 应用程序用户界面。你知道 <button> 可以像 <input> 一样有一个值吗？这种对 HTML 的关注使得构建数据驱动的 Web 应用程序变得轻而易举。HTML 知识是可以转移的。
• 你在服务器上使用的表单值是标准的 FormData 对象。
• 在客户端突变期间用于待处理和乐观 UI 的表单值也是 FormData 对象。
• Remix 依赖于静态页面的 HTTP 缓存，而不是用特殊的 SSG API 来包装它：结果相同，但一个是可转移的标准 Web 技术。
• 文档和示例使用 new URL(request.url).searchParams，而不是使用特殊的中间件以非标准方式解析 URL。
• Cookie 和会话是基于 Web Fetch API Request 和 Response 对象构建的。

Remix API 主要是一堆生命周期钩子，它们最终会为你提供来自 Web 平台的东西。过一段时间，你会发现你花在 MDN 上的时间比在 Remix 文档上的时间还多。不要相信我们的话，在 Twitter 上搜索 "@remix_run mdn"！

尝试一下 Remix

Web 开发变化很快。收集和清除所有不可转移的知识确实让人筋疲力尽。我们相信，你在 Remix 中花费的时间将提供可转移的知识，这将影响你未来的 Web 开发职业生涯。试一试，让我们知道进展如何😁

快速入门教程是一个很好的起点！