別再有新框架了！

我確信你們很多人看到 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 插件，這兩個插件不相容！在 Google 搜尋了一番之後，我了解了什麼是「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 是相似的，有些包裝了其他 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 和 Session 是建立在 Web Fetch API Request 和 Response 物件之上的。

Remix API 主要是一堆生命週期鉤子，最終會向你提供來自 Web 平台的東西。過了一段時間，你會發現你花在 MDN 上的時間比在 Remix 文件上的時間還多。不要只聽我們的，在 Twitter 上 搜尋 "@remix_run mdn"！

試試 Remix

Web 開發變化很快。收集和清除所有不可轉移的知識**是**令人精疲力竭的。我們相信你在 Remix 中的時間將提供可轉移的知識，這將影響你未來的 Web 開發生涯。試試看，並讓我們知道情況如何 😁

快速入門教學 是個很棒的起點！