不只是另一个框架！

我确信很多人都看到了 Remix 引起的一些热潮，并在想

Ugh, 我还没有准备好学习新的东西… 东西变化太快了！

我明白！学习用不同的 API 解决相同问题是令人疲惫的。最糟糕的是感觉自己之前用现有工具积累的深厚知识现在都过时了，然后又变成了新手，从头开始。这确实很累人。

Remix 不是新框架吗？学习 Remix 会很累人吗？

我希望不会！在 Remix 中工作时，你主要是使用标准的 Web API。你可能已经熟悉它们，或者你将第一次学习它们。这些知识不仅能帮助你在 Remix 中构建出色的用户体验，而且也能帮助你在今天和未来使用 Remix 之外的其他工具。这就是我认为 Remix 值得你在这个疯狂而不断变化的 Web 开发世界中花费时间的原因。

不可转移的知识

我以前领导过一家公司的前端基础设施团队。在和一位要离开去新公司工作的同事交谈时，他们说了一些话，从那以后一直萦绕在我的脑海中

他们没有使用 [我们使用的框架]，所以我在过去两年里在这里学到的所有东西都变得毫无意义了！

这句话对我打击很大。我讨厌这种感觉。尽管那是一个 JavaScript 框架，但我们使用的框架几乎所有事情都有自己的处理方式，甚至添加数组元素也与众不同。我的同事感觉这段时间在公司几乎是白白浪费了！

当然，所有编程经验依然是经验。但当涉及到框架时，通常有很多知识无法转移到下一个框架。在我的职业生涯中，我使用过一些框架，它们有大量的 API 需要我记忆，而其中许多 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 实现的，直到你到达核心 API，这些 API 是用 JavaScript 本身实现功能的方式实现的：原型！你只要浏览一下 MooTools 的第一行代码 就能看到这一点。

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

… 我知道 功夫 JavaScript！

它让我深入学习了 JavaScript：从原型到上下文绑定，从对象标识到 DOM。在我的职业生涯中，MooTools 教给我的基础知识帮助我掌握了所有后来的 JavaScript 知识。

MooTools 提供了实用的、高级的抽象来完成工作，但它以一种在学习过程中补充我基础知识的方式来实现这一点——而不是让你去记忆一大堆 API。 (扩展内置原型最终证明是一个糟糕的主意，但这个故事以后再说。）

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

学习 Remix，无意中学习 Web

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

我们希望你在 Remix 中的经验能够帮助你在任何框架中构建更好的网站。说真的，我们希望为你提供基础，让你成为构建我们所有人之后都会使用的框架的人！ (不过请让我们先享受几年辉煌吧，我们有家人和孩子要养。）

在实际应用中，这意味着什么？

想想你在 JavaScript 中学习了多少个请求/响应 API。Node.js 有一个，express 有一个，aws、azure、Next.js、Netlify、hapi、restify 等都有自己的请求/响应 API。许多 API 类似，一些 API 只是对其他 API 的封装，但没有一个是 Web 标准。

当浏览器发布 fetch 时，它们也发布了一个 标准 API 用于网络请求和响应。我们没有自己发明 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 开发职业生涯。试一试，让我们知道你的感受 😁

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