聊一聊 React 之 Next.js 11 的一些新特性

本文中，我們將深入研究其中一些對用戶和開發人員體驗都產生影響的更新。讓我們開始吧！

一致性

就其核心而言，一致性是一組原則或編碼指南，它將一些決策責任從開發人員手中奪走。通過設置默認值和提供指導方針，更容易實現預期結果并防止常見錯誤。

根據Next.js 團隊的說法，“一致性是一個系統，它提供精心設計的解決方案和規則以支持最佳加載和 Core Web Vitals”。

Next.js 11 中的新一致性原則可以分為三個方面：

1. 強默認值

框架必須在其核心建立某些設計模式，使開發人員難以做錯事。

2. 可操作的規則

盡管有很強的默認設置，但有時開發人員有責任在兩條潛在路徑之間進行選擇。一組可操作的規則將使應用程序更容易遵守強大的性能標準，同時仍然允許足夠的自定義級別。

3. 創作時間

創作時間更重視功能開發周期而非生產后的性能。在代碼提交之前必須考慮性能，而不是在產品發布后將其視為基于分析的指標。

強制執行創作時間原則的最簡單方法之一是通過 linting 規則。因此，Next.js 11 開箱即用的支持 ESLint。

要獲得這些功能的好處，您必須通過運行以下代碼升級到 Next.js 的最新版本：

npm i next@latest react@latest react-dom@latest

通過運行以下代碼啟用 linting：

npx next lint

一旦我們升級我們的版本并啟用 ESLint，我們將開始收到警告，這些警告會促使我們朝著行業最佳實踐的方向發展，幫助我們的應用程序遵守一致性準則。

腳本優化

許多網站都包含第三方腳本以啟用分析和廣告。

加載腳本的順序對頁面性能有巨大影響，尤其是在處理網頁上的多個外部腳本時。如果管理不當，腳本會嚴重降低用戶體驗。

Next.js 引入了一個腳本組件，它的strategy屬性可以處理很多這些問題。

讓我們來測試一下！一個明顯的變化是我們不再需要在標簽中包裝原生 HTML 腳本next/head標簽：

import Head from 'next/head'
function Home() {
 return (
    <>
      <Head>
        <script async src="https://polyfill.io/v3/polyfill.min.js?features=WebAnimations" />
      </Head>
    </>
  )
}

相反，我們可以直接使用原生 HTML 腳本標簽，如下所示：

import Script from 'next/script'
function Home() {
  return (
    <>
      <Script src="https://polyfill.io/v3/polyfill.min.js?features=WebAnimations" />
    </>
  )
}

在這個例子中，我們建議使用該beforeInteractive策略加載我們的 polyfill 。讓我們改變策略，看看它如何影響加載腳本！

beforeInteractive

腳本在服務器端被注入到 HTML 中，并在捆綁的 JavaScript 運行之前在瀏覽器上運行。使用下面的代碼塊，我們看到獲取 polyfill 的網絡調用是在網絡選項卡中的其他所有內容之前進行的：

<Script src="https://polyfill.io/v3/polyfill.min.js?features=WebAnimations" 
`strategy="beforeInteractive" />

afterInteractive

如果我們將策略更改為afterInteractive，腳本將在頁面變為交互式后執行。網絡請求位于網絡選項卡中的頁面底部，它優先考慮更重要的任務。

lazyOnload

將策略更改為lazyOnload告訴 Next.js 在空閑時間加載腳本。獲取 polyfill 的網絡請求進一步向下移動到頁面底部；沒有其他延遲加載的腳本，如下面的屏幕截圖所示。

onLoad 屬性

除了上面的自定義之外，如果我們想在腳本加載后執行一些代碼，我們可以使用onLoad腳本標簽的prop。該onLoad屬性可確保上面的腳本加載，使功能使用腳本的功能和變量沒有崩潰：

<Script
  id="my-script"
src="https://polyfill.io/v3/polyfill.min.js?features=WebAnimations"
  onLoad={() => {
    // this executes after the script is loaded
  }}
/>

圖像改進

Next.js 11 包括對next/image組件的增強，例如減少布局偏移，為最終用戶提供更流暢的體驗。

靜態圖像的尺寸檢測

以前，要使用Image組件渲染圖像，必須使用height和width道具。這些道具允許 Next.js 識別圖像的大小并渲染占位符，防止布局偏移和混亂的用戶界面：

<Image
  alt="Fixing"
  src="/fixing.png"
  layout="intrinsic"
  width={700}
  height={475}
/>

Next.js 11 提供了對srcprop 的支持，可以使用import關鍵字來應用。如果以這種方式導入源，則不需要單獨指定height和width道具：

import source from '../public/fixing.png'
<Image
  alt="Fixing"
  src={source}
  layout="intrinsic"
/>

圖像占位符

在 Next.js 11 中，該next/image組件支持一個新的占位符屬性，該屬性設置value為blur較慢的連接。該next/image組件將在加載原始圖像時顯示模糊的低分辨率圖像：

<Image
  alt="Fixing"
  src={source}
  layout="intrinsic"
  placeholder="blur"
/>

在最終加載原始圖像之前，模糊圖像將顯示兩到三秒鐘。

此外，Next.js 11 提供了通過Image標簽提供自定義占位符的選項，可以使用blurDataURLprop 顯示。提供給此道具的值可以使用諸如blurha.sh 之類的應用程序生成。

Webpack 5 默認支持

Webpack 5 支持在 10.2 版中宣布，適用于所有文件中沒有自定義 webpack 配置的 Next.js 項目next.config.js。自定義 webpack 配置如下所示：

module.exports = {
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    return config; // return the modified config
  },
}

從版本 11 開始，無論自定義配置如何，webpack 5 都是所有 Next.js 應用程序的默認構建工具。webpack 5 附帶的所有以下優化將可用于新建項目。

改進的磁盤緩存

我們知道我們可以使用命令觸發構建next build。但是，如果我們為項目觸發的兩個連續構建之間幾乎沒有變化怎么辦？

Webpack 5 只允許有條件地重新編譯已更改的文件。性能得到了提高，因為我們不會冗余處理尚未更改的塊。

改進的快速刷新

有了 webpack 5，Next.js 11 將快速刷新識別為一項特殊任務，并以更高的優先級執行它，從而在每次保存任何代碼更改時都能更快地刷新。

長期 asset 緩存

使用 webpack 5，build命令的構建過程是確定性的。如果代碼段沒有更改，則后續構建時生成的哈希不會更改，這意味著在瀏覽器中散列的文件可以在更長的時間內重復使用。

改進的 tree shaking

Webpack 5 提供了tree shaking commonJS模塊的功能，從包中刪除未使用的代碼。

從 Create React App 遷移

由于社區的要求，Vercel 團隊推出了該@next/codemod工具，該工具支持 React 和 Next.js 項目之間的兼容性。

我們可以運行該工具，為它提供一個使用 Create React App 腳本生成的項目，并將其轉換為 Next.js 項目。讓我們試試吧！

首先，使用以下命令創建一個 React 應用程序：

npx create-react-app cra-demo

現在，我們已經初始化了一個新的 React 項目，我們可以使用以下命令運行我們的項目：

npm run start

你會看到熟悉的 React 屏幕：

接下來，運行腳本以從 Create React App 遷移到 Next.js 項目：

npx @next/codemod cra-to-next cra-demo

我們可以看到腳本對存儲庫進行了一些更改以將其移植到 Next.js。這些變化包括：

對腳本的更改 package.json
添加pages文件夾，這是 Next.js 存儲庫的主要功能
更改通過創建_app.js文件導入 CSS 的方式
創建next.config.js文件并填充它

Babel優化

Next.js 11 為 webpack 提供了全新的Babel 加載器實現，其中包括一個內存配置緩存層，通過 10.1 和 10.2 版本的改進進一步縮短了啟動時間。

Next.js Live

Vercel 的團隊使用了多種下一代前端技術，如 serviceWorker、WebAssembly 和 ES 模塊，以在瀏覽器內部提供協作環境。使用 Next.js Live 功能，開發人員和設計人員只需共享 URL 即可協作。Live 功能目前正在搶先體驗下運行。

結論

很明顯，這些升級構成了有史以來最突出的 Next.js 版本之一！

對內核進行了一些更改以減少啟動時間，例如 Babel 優化，以及促使開發人員采用經過驗證的解決方案的一致性建議。其他改進是加載圖像和腳本，使用戶體驗無縫。此外，我們現在可以使用 Live 功能改進協作。

由于這些以及更多原因，Next.js 11 版本看起來很有希望并且值得升級。試一試，讓我們知道你在評論中的想法！

istory API

HTML5 History API無疑是現代網站的發展方向，因為它完成了手頭的任務，同時還提供了額外的功能。您可以根據需求使用history.pushState()或history.replaceState()在瀏覽器中修改URL：

// 當前 URL: https://my-website.com/page_a

// 修改后的URL
const nextURL = 'https://my-website.com/page_b';	
const nextTitle = 'My new page title';
const nextState = { additionalInformation: 'Updated the URL with JS' };

// 這將在瀏覽器的歷史記錄中創建一個新條目，而無需重新加載
window.history.pushState(nextState, nextTitle, nextURL);

// 這將替換瀏覽器歷史記錄中的當前條目，而無需重新加載
window.history.replaceState(nextState, nextTitle, nextURL);

兩個方法的參數相同，允許您傳遞自定義的可序列化狀態對象作為第一個參數、自定義標題（盡管大多數瀏覽器會忽略此參數）以及要在瀏覽器歷史記錄中添加/替換的URL。請記住，History API只允許相同的源URL，因此您無法導航到完全不同的網站。

Location API

舊的Location API不是該作業的最佳方案，因為它會重新加載頁面，但是它仍然允許您修改當前URL，并且在使用舊瀏覽器時可能會很有用。您可以使用window.location.href、location.assign()或location.replace()修改URL：

// 當前 URL: https://my-website.com/page_a

// 修改后的URL
const nextURL = 'https://my-website.com/page_b';

// 這將在瀏覽器的歷史記錄中創建一個新條目，然后重新加載
window.location.href = nextURL;

// 這將替換瀏覽器歷史記錄中的當前條目，然后重新加載
window.location.assign(nextURL);

// 這將替換瀏覽器歷史記錄中的當前條目，然后重新加載
window.location.replace(nextURL);

如上所述，這三個選項都將導致頁面重新加載，這可能是不希望的。此外，與使用History API不同，您只能設置URL，而不需要任何附加參數。最后，Location API不會限制您使用相同的源URL，但使用不同的源URL，這可能會導致安全問題。

日分享最新，最流行的軟件開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支持，跪求關注，點贊，留言。

如今，當我們想要基于 React 創建一個新的 Web 項目時，我們有許多不同的框架選擇。

如今，當我們想要基于 React 創建一個新的 Web 項目時，我們有許多不同的框架選擇。作為一名開發人員，您會發現自己很難知道應該選擇哪一種，或者哪一種最適合您的需求。

您可能知道最常用的框架之一是Next.js，Netflix、Twitch 或 Uber 等公司通常使用它。它被認為是增長最快的 React 框架之一。

其他人很難與 Next.js 競爭，因為它涵蓋了三種不同的頁面渲染策略，但自 2021 年 11 月以來，我們似乎有了一個新的、新鮮的、強大的框架，稱為Remix。

對不起蓋茨比，我沒有忘記你，我喜歡你在生成靜態站點時的工作方式。

為什么需要 Next.js 或 Remix 而不是普通的 React
也許你沒有；這取決于。重點是了解 React 應用程序如何工作，您可能會發現哪些問題以及 Next.js 或 Remix 等框架如何解決這些問題。

關于 React 的要點是您可以制作單頁應用程序 (SPA)，其中僅使用一個 HTML 文件來呈現所有網頁，并且路由保留在客戶端。但這到底是什么意思呢？

當發出初始請求時，瀏覽器會立即收到一個包含所有應用程序的 HTML 框頁面。
沒有預渲染的內容。
當用戶導航觸發時，JavaScript 僅替換那些與請求的路由相關的組件和內容，但 HTML 文件保持不變。
簡而言之，瀏覽器負責管理應加載哪個 JavaScript 文件以呈現當前頁面。換句話說，客戶端呈現 (CSR)。

CSR 可以非?；ㄉ诓⑶矣兄趧摻ú恍枰P心 SEO、緩存或緩慢的初始渲染的應用程序。

SSlow Initial Render——當用戶第一次登陸時，可能需要很長時間才能加載第一個內容頁面。這意味著讓他們得到一個空白頁面，直到 JavaScript 加載并呈現所有內容。
SEO——因為內容只有一個 HTML 頁面，所以很難讓搜索引擎和社交媒體機器人對內容進行索引。
緩存問題——HTML 結構無法緩存，因為它在第一次渲染時不可用。
在這一點上，您可能認為 SPA 是魔鬼，但想想這么多公司使用的所有內部應用程序或他們銷售的應用程序產品。

當您想利用 SPA 的工作方式而又不失去我之前提到的三點時，Next.js或Remix就會出現。優點是網站可以在發送到客戶端之前在服務器端呈現。

SSR vs SSG vs ISR
我已經解釋了 CSR 的含義和工作原理，現在輪到我來談談其他花哨的頁面呈現策略。

Next.js是一個強大的選項，因為它提供了三個開箱即用的不同選項，而Remix完全依賴于 SSR（目前）。但這些策略究竟是如何運作的呢？

服務器端渲染 (SSR)
當一個頁面被請求時，它在發送到客戶端之前在服務器上完全呈現。對于那些擁有大量動態數據和內容的網站來說，這是一個很好的選擇。

靜態站點生成 (SSG)
該策略在構建期間按路由生成所有頁面。出現提示時，只會將請求的頁面發送給客戶端。也就是說，這構建了一個典型的靜態網站。

對于那些幾乎沒有或沒有動態數據且頁面不多的靜態網站來說，它可能是一個合適的選擇。數據中的每個更改都會觸發所有頁面的重新生成。

增量靜態再生 (ISR)
Next.js 提供了這個概念，是 SSR 和 SSG 的混合體。

它類似于 SSG，但您可以設置一個間隔時間，讓您知道何時應該重新生成您的頁面。適用于那些具有動態內容的靜態站點。

Next.js 的強項在于它允許您在每個頁面上的這三個選項之間切換，因此您可以讓每個選項遵循不同的策略。

所以也許你會問自己，“如果 Next.js 只適用于 SSR，我為什么要用 Remix 替換它”。答案很簡單，如今，應用程序和網站往往具有動態數據，并且很少有適合 SSG 或 ISR 場景的示例。

考慮到這一點，Remix 提供了一個較低級別的 API。例如，它公開了 Request 對象，因此您可以在呈現頁面之前輕松修改標頭，而在 Next.js 中，您需要中間件來實現它。

路由
這兩個框架都使用基于文件的路由系統來呈現頁面。

每個頁面都保留在不同的文件中。
每個頁面都與基于其文件名的路由相關聯。
最后，每個頁面都會呈現一個 React 組件。
混音中的路由
您將在中添加每個路由/app/routes，并且在其中創建的每個文件或文件夾都將被視為一個路由。

混音路由 1
此外，您會發現一個文件，/app/root.jsx,其中是“根路由”，是整個應用程序的布局。它包含 <html>、<head> 和 <body> 標簽，以及其他與 Remix 相關的內容。

Next.js 中的路由
您將在中添加每條路線/pages，它的工作方式與 Remix 完全相同。

nextjs 路由 1
在這種情況下，您可能有也可能沒有pages/_app.jsand pages/_document.js。其中App用于初始化頁面，文檔包含標簽。

Next.js 默認使用它們，無需額外配置。但是，如果您需要自定義它們，您可以創建這兩個文件，以這種方式覆蓋默認文件。

索引路線
他們都使用相同的系統來呈現容器路線。

Next.js 示例：

pages/index.js=> /（根頁面）
pages/posts/index.js或者pages/posts.js=>/posts
混音示例：

routes/index.js=> /（根頁面）
routes/posts/index.js或者routes/posts.js=>/posts
嵌套路由
Remix 建立在 React Router 之上，由同一個團隊開發，所以你可以想象在嵌套路由方面誰是贏家。
其背后的想法是創建一個活動路由來掛載包含多個嵌套路由的布局，以便每個路由管理自己的內容。

如果我必須用 React 語言來解釋它，我會告訴你想象每個嵌套路由都是一個組件，并且根據 URL 路徑，它們可以被掛載和卸載。

為實現這一點，Remix 使用了<Outlet />React-router 組件。它用在父路由上，告訴它們只要被觸發就渲染子路由元素。
請記住，所有這些嵌套路由都已預加載到服務器上，因此幾乎每個加載狀態都可以刪除。聽起來不像是 SSR 和 SPA 的混合體？

另一方面，Next.js 確實支持嵌套路由，但它們作為單獨的頁面工作。如果您想實現類似于 Remix 所做的事情，您可能應該自定義您的_app.js.

兩者的示例：

routes/posts/news/index.js=>/posts/news
動態路線
它們通過基于動態的 URL 參數呈現不同的內容來工作，但它使用單個路由文件。
在這種情況下，兩個框架都支持此功能，但使用不同的命名約定。

Next.js 示例：

pages/posts/[postId].js=>/posts/some-post-slug
pages/products/[category]/[productId].js=>/products/keyboards/some-keyboard-slug或/products/headphones/some-headphone-slug
它有自己的鉤子，useRouter將為您提供那些動態參數（postId、類別、productId）的當前值。

混音示例：

/app/routes/posts/$postId.js=>/posts/some-post-slug
/app/routes/products/$category/$productId.js=>/products/keyboards/some-keyboard-slug或/products/headphones/some-headphone-slug
您可以使用useParamReact Router hook 來訪問這些動態參數。

需要加載文件的路由怎么辦？
想象一下，您需要您的網站包含典型文件robots.txt和sitemap.xml文件。

在 Next.js 和 Remix 中，您都可以將它們添加到 /public 目錄。但是 Remix 可以讓你通過路由系統實現它，只需創建一個/app/routes/[sitemap.xml].js或/app/routes/[robots.txt].js

數據加載
這兩個框架都是服務器端的，因此每個框架都有不同的系統來獲取數據和手動調用 API。

對于 Next.js，您可以在兩個選項中進行選擇，具體取決于您要構建的頁面類型。

getStaticProps（SSG，如果設置了重新驗證間隔，則為 ISR）——它在構建時獲取數據并將其數據作為頁面的組件屬性提供。
export async function getStaticProps( {params} ) {
const productList = await getProductList()

return {
props: {
productList,
slug: params.slug
}
}
}

getServerSideProps (SSR) — 它在運行時在服務器端獲取數據，并將返回的數據作為頁面的組件道具提供。
export async function getStaticProps( {params} ) {
const productList = await getProductList()

return {
props: {
productList,
slug: params.slug
}
}
}

/**
* Here you would have your own getStaticProps/getServerSideProps functions
* depending on what system you choose.
**/

const PageName = (props)=> {
const { productList } = props
// Here you could render the requested data
return (<div>
<pre> {JSON.stringify(productList, null, 4)} </pre>
</div>)
}

Remix 使用不同的方式加載數據；

它為您提供了一個loader在每個路由文件上使用的函數，該文件將在運行時在服務器端運行。
在頁面組件本身上，您將能夠使用useLoaderData掛鉤來收集這些數據。
/**
* Here you would have your own getStaticProps/getServerSideProps functions
* depending on what system you choose.
**/
export const async loader = ( {params} ) => {
const productList = await getProductList()
return {
productList,
slug: params.slug
}
};

export default function PageName() {
const { productList } = useLoaderData();

// Here you could render the requested data
return (<div>
<pre> {JSON.stringify(productList, null, 4)} </pre>
</div>)
}

數據突變
Next.js 沒有內置的方式來執行突變，你必須手動進行。
另一方面，Remix 創建了一個表單組件，并像使用瀏覽器的本機 HTML 表單元素一樣使用它。如果您不輸入任何操作 URL，它將對表單使用相同的路由。

如果方法是GET，loader將觸發導出函數，如果方法是POST，action將觸發定義在組件中的導出函數。

此外，您可以使用提供的 useTransition 掛鉤根據請求狀態管理應用程序的行為，而無需像往常一樣手動管理它。

export const loader = async ({ params }) => {
// Each time this page receive a GET Request, this loader will be executed
const userData = await getSomeUserData(params.slug)

return {
userData // it contains the User Name
}
}

export const action = async ({ request }) => {
// Each time this page receive a POST Request, this loader will be executed
const form = await request.formData()
const content = form.get('content')

return redirect('/')
}

export default function App() {
const { name } = useLoaderData();

return (
<div>
<div>{`Hello there ${name}`}</div>

<Form method="POST">
<label htmlFor="content">
Content: <textarea name="content" />
</label>

<input type="submit" value="Add New" />
</Form>
</div>
)
}

造型
Next.js 帶有開箱即用的內置 CSS 支持，因此您可以直接將其導入到 /pages/_app.js 所需的任何 style.css 文件中。

您還可以添加其他 CSS 框架，使用一些配置或插件很容易實現。

linksRemix 更喜歡通過提供組件和導出功能來專注于對 Web 標準更加友好的解決方案。

import styles from "./styles/app.css";

export function links() {
return [
{ rel: "stylesheet", href: styles },
{ rel: "stylesheet", href: 'https://.....' },
];
}

export default function App() {
return (
<html lang="en">
<head>
<Links />
</head>
<body>
<Outlet />
</body>
</html>
);
}

您可能認為僅僅加載一個樣式表有點過分了，但是如果我告訴您可以在每個頁面上單獨使用它，讓您僅在需要時加載特定樣式/字體怎么辦？

另外，在這里你可以使用其他的 CSS 框架，只需很少的配置，比如 Tailwindcss。

圖像優化
Next.js 在這里獲勝，因為它有自己的內置組件next/image，可以實現圖像優化、延遲加載、大小控制和集成加載器。不幸的是，目前 Remix 沒有任何圖像優化支持。

搜索引擎優化
在本文的開頭，我告訴過您這些框架背后的要點之一是解決 SPA 的 SEO 問題。

它們都有自己的內置機制來動態管理每個頁面上應該使用哪些元數據，例如關鍵字、標題、描述等。

next/head在 Next.js 中，您可以通過將其導入頁面/路由來使用其內置組件。

import Head from 'next/head'

export default function PostPage() {
return (
<div>
<Head>
<title>Post Page Title</title>
<meta name="description" content="Post Page Description" />
</Head>
<p>
All the metadata inside Head component will be injected into the
documents head
</p>
</div>
)
}

另一方面，Remix 為我們提供了一個meta導出函數，可以接收頁面的請求數據以及 URL 參數。

export const meta = ({ data, params }) => {
charset: "utf-8",
viewport: "width=device-width,initial-scale=1",
title: `Post | ${data.title}`,
description: data.description,
};

export default function PostPage() {
return (
<div>
<p>
All the metadata returned on meta function will be injected into the
documents head
</p>
</div>
)
}

錯誤處理
Next.js 使您可以在捕獲某些錯誤時定義自定義頁面，例如 400 或 500 錯誤。但是除了路由或狀態錯誤之外的任何其他錯誤都會導致頁面中斷。

Remix 讓您盡情發揮想象力，這樣您就可以覆蓋和自定義您想要的每個錯誤。他們添加了錯誤邊界，這是一種處理錯誤的獨特概念——在 React v16 中引入。

您可以通過在您的甚至每個頁面上使用CatchBoundary, 和ErrorBoundary導出的函數輕松地覆蓋這些錯誤。root.tsx讓我們添加一些視覺示例。

// Here you will catch any controlled error and will tell the framework what information should be shown
const CatchBoundary = () => {
let caught = useCatch();

switch (caught.status) {
case 401:
// Document is a custom React Component which contains <html>, <head>,<body>, etc
return (
<Document title={`${caught.status} ${caught.statusText}`}>
<h1>
{caught.status} {caught.statusText}
</h1>
</Document>
);

case 404:
return <PageNotFoundComponent />; // Yes, you can also use a React Component
default:
throw new Error(
`Unexpected caught response with status: ${caught.status}`
);
}
};

// Here you will have a more generic advise for when an uncontrolled error has been triggered
const ErrorBoundary = ( { error } ) => {
return (
<Document title="Uh-oh!">
<h1>App Error</h1>
<pre>{error.message}</pre>
<p>
Replace this UI with what you want users to see when your app throws
uncaught errors.
</p>
</Document>
);
};

export const loader: LoaderFunction = async ({ params }) => {
const post = await getPost(params.slug);

if (!post) {
throw new Response("Not Found", {
status: 404,
});
}

return json({ post });
};

export default function PostPage() {
const { post } = useLoaderData();
return (
<div>
<pre>
{JSON.stringify(post, null, 4)}
</pre>
</div>
)
}

部署
Next.js 很容易部署在任何支持 Node.js 的服務器上。它還集成了無服務器部署到 Vercel 的功能，Netlify 有自己的適配器，因此您可以輕松部署應用程序。

Remix 基于 Web Fetch API 而不是 Node.js 構建，因此它可以在 Vercel、Netlify、Architect（Node.js 服務器）以及 Cloudflare 等非 Node.js 環境中運行。

它還會在您開始項目時為您提供開箱即用的適配器，因此如果您知道要將項目部署到哪里，就可以直奔主題。

Remix 最重要的事情之一是它不再使用 Webpack。相反，它使用 Esbuild，它在捆綁和部署方面速度極快。

其他提及
每當您想選擇 Next.js 或 Remix 時，還有其他要點需要考慮，但我想收集那些在我看來作為開發人員在開發項目時具有更大影響的因素。
但如果您想了解更多，這里有一些我在本文中沒有談到的事情的回顧。

實時重新加載。Next.js 使用熱模塊重新加載 (HMR) 并默認啟用，而在 Remix 上，您必須在 root.tsx 上添加一個組件以強制您的應用程序在代碼更改時重新加載。
Remix 支持 Cookie、會話和身份驗證，而 Next.js 不支持——您必須使用外部庫。
Next.js 內置了對字體和腳本優化的支持，而 Remix 則沒有。
兩者都讓您開箱即用地使用 Typescript。
Remix 無需執行 JavaScript 即可完成其大部分功能，而 Next.js 則不會。
Remix 可以在嵌套路由中包含獨立路由
兩者都可以使用 Tailwindcss 快速工作，并有自己的指南來實現它。
Next.js 內置了對國際化路由的支持。
Next.js 對 AMP 具有開箱即用的支持，而 Remix 則沒有。

在線咨詢

上一篇：30 個純 HTML5 實現的游戲
下一篇：寫個網頁更簡單了！讓AI根據手繪原型生成HTML - 教程+代碼

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

聊一聊 React 之 Next.js 11 的 一些新特性

一致性