阿川私房教材：
學 JavaScript 前端，帶作品集去面試！

63 個專案實戰，寫出作品集，讓面試官眼前一亮！

小編精選 - 技術文章翻譯 · 05月27日

我用這個模組替換了我的應用程式的 Next.js🔥

TL;DR

是的，我明白你會立即對我所說的話產生懷疑，因為「你怎麼能改變 Spotify、OpenAI 和其他大公司所使用的東西？」。

但我想說的是，這個主題在 2025 年顯然不是什麼新鮮事，我不會在這裡透露任何超自然的事情。 HTMX和Alpine.js已經充分向大家證明了這並非無稽之談。我只是在重述一切，但有一點很有趣——這是HMPL模板語言，它在某些任務上比前兩個更好。接下來，我將描述它為何以及如何幫助您替換Next.js。

讓我們開始吧！ 🏎️

👀 這是什麼應用程式？

一開始，我想製作一個小型的登陸頁面作為範例。純粹是為了我自己。為了簡歷，或其他目的，但我只是想快速做點什麼。

當然，我選擇了我每天在工作中使用的堆棧，即 Next.js，我以為我會很快用它做一些事情，但事實並非如此。

讓我們來看看該應用程式的設計：

它看起來像是一個可以在 5 分鐘內完成的簡單應用程式，但顯然，當你遇到一個重量級框架時，最困難的部分就開始了——實現。

🔨 建構結構、元件和第一個困難

當您開始使用 Next.js 做某事時，首先想到的是什麼？當然，你需要將它安裝到專案中。這裡我們談到了在框架上建立網站的方法的主要缺點之一，無論是 Next.js、Nuxt.js 還是 Remix。這裡的觀點有所不同。

但讓我們繼續安裝。我們在終端機中寫入初始化起點的命令：

npx create-next-app@latest

我設定了一個沒有額外 CSS 模組、沒有 TypeScript 和其他東西的起點，我只安裝了 TurboPack，以便一切都能更快地建置，這就是你所看到的：

終端機訊息

這是專案本身的重量，只有起始重量，沒有起始元件：

應用程式大小

我什至還沒有開始做任何事情，我只是安裝了該應用程式。如果我想要安裝 RTK-Query 或其他狀態管理器，那麼它會有多重呢？是的，即使在 Next.js 中，如果我開始認真製作應用程式會發生什麼？

我可以告訴你，它的重量將低於500 兆字節，如果我有很多元件的話，甚至會是1 千兆字節。

📦應用程式大小和可擴展性

我繼續進一步製作應用程式，建立合適的元件，上傳圖像，稍微更改配置以及其他類似的事情。

結果，我成功建立了以下元件：

標題
特徵
促銷
行動呼籲
頁尾

是的，它們在那裡，原則上這些元件沒有任何重量，因為它們是簡單的功能，但是，當然，增加了幾 MB，但這是可以理解的，因為應用程式很小。

最終應用程式大小

而且，我可能得出了更換框架的最重要原因之一——它們的沉重。

假設我們在 Next.js 上存取一個中型公司的常規網站，該網站位於 Gitlab 或 GitHub 上，如果不包含node_modules資料夾，無論如何減少，該網站的大小都會達到幾百兆甚至幾千兆。但如果我們承接非常大的專案怎麼辦？它們的程式碼庫可能有幾十 GB，就好像 Steam 上的一些嚴肅遊戲一樣。

以這個速度，我們即將達到雲端儲存過載的程度，全世界的資訊量高達數 TB，需要整棟建築的伺服器來儲存所有資訊——即使在普通公司中這也是難以理解的，但如果我們談論的是大型公司呢？

另外，我們考慮到從此類框架建立的程式重量相當大，有30-40 兆位元組的純 javascript，將在客戶端上執行。

💬 那麼體重怎麼辦？

當然，有些人認為最明顯的解決方案是使用 Web 元件，甚至像 21 世紀初那樣完全不使用此類系統來製作網站，但實際上這在生產專案中並不適用。

甚至在 Next.js 出現之前，人們早就想出了解決這一切的替代方案。此替代方案是一種透過標記直接建立動態 Web 介面的機制。粗略地說，這就是.ejs檔案所做的事情，但僅限於客戶端並透過屬性來實現。

<div data-some-custom-attr="getHTML()" @click="someFunction()">
</div>

一些最受歡迎的函式庫是HTMX 和 Alpine.js 。 Alpine.js，可能程度較輕，因為它強調的是標記中的 js 交互，而 HTMX 被人們視為框架的完全替代品。從某種程度上來說，這是正確的，我並不反對這種觀點，但這種方法有嚴重的缺陷：

幾乎最小化的 js 集成
幾乎不可自訂的請求
發送請求的舊標準

它更多是關於 HTMX，但很明顯 Alpine.js 在語法上存在一些缺陷，它就像.jsx等等。

📊 略有不同的方法

當我們既沒有 HTMX 也沒有 EJS 時，可以採用幾種方法的組合，但可以使用介於兩者之間的方法。這就是HMPL模板語言。

首先我們來看看我們改變的結果會是什麼樣的。

而不是page.jsx ：

<body>
  <Header/>
  <Features/>
  <Promo/>
  <CTA/>
  <Footer/>
</body>

我用常規的index.html替換它：

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Landing Page</title>
    <link rel="stylesheet" href="global.css" />
  </head>
  <body>
    <script src="./json5/dist/index.min.js"></script>
    <script src="./dompurify/dist/purify.min.js"></script>
    <script src="./hmpl-js/dist/hmpl.min.js"></script>
    <script src="global.js"></script>
    <script>
      const body = document.querySelector("body");
      const template = `
        <main>
            <!-- Header Component -->
            {{#request src="http://localhost:8000/api/get-header-component"}}{{/request}}
            <!-- Features Component -->
            {{#request src="http://localhost:8000/api/get-features-component"}}{{/request}}
            <!-- Promo Component -->
            {{#request src="http://localhost:8000/api/get-promo-component"}}{{/request}}
            <!-- CTA Component -->
            {{#request src="http://localhost:8000/api/get-cta-component"}}{{/request}}
            <!-- Footer Component -->
            {{#request src="http://localhost:8000/api/get-footer-component"}}{{/request}}
        </main>
      `;
      const { response } = hmpl.compile(template)();
      body.append(response);
    </script>
  </body>
</html>

我還將所有元件帶到伺服器並通過後台的fetch請求和直接在標記中加載它們。