Skip to main content

Hugo 心得雜談

從使用者變成主題維護者,對 Hugo 越來越熟悉所以決定寫一下我的理解,本文比較面向用戶而不是開發者。

Hugo 的優點

Hugo 最大的優點就是「完全無須理解前端複雜生態」,不管前端有什麼 npm yarn pnpm bun,什麼 React Vue Angular Next.js 各種框架,SSR CSR Hydration 一堆有的沒的問題全都與我們無關,基本上 Hugo 就只會有 HTML/CSS/JS 三個打天下,不用學一堆有的沒的奇怪知識,我們沒有要成為前端工程師。

Hugo 沒有任何依賴,只要一個二進制包就可以在任何地方運行,這也代表不管過 10 年 20 年永遠都可以用同一個二進制檔案編譯你的 Markdown 文件不需要任何語法更新,沒有套件失效找不到的問題,也沒有任何麻煩的依賴管理,20 年後唯一要更新的就是舊版 CSS 語法瀏覽器可能不支援了,但是 Hugo 的二進制包還是活的好好的。

Hugo 很快,甚至比 Zola 還快

Hugo 很容易客製化主題,內建的 override 機制可以任意客製化任何檔案,沒有任何檔案不能客製化的,對比 Docusaurus 高度支援但還是有限的客製化支援,以及 Vitepress 上手難度相對高的客製化,指定檔案的客製化輕鬆很多。hexo 雖然可以直接修改主題原始碼,但是沒有 override 功能,主題更新就需要手動合併上游更新。

Hugo 發展已經足夠久,支援各種想的到想不到的方法,例如 permalink 各種設定、相關文章、上下一篇文章等等,或是可以直接在 Markdown 裡面隨便寫 HTML,shortcode 簡單易懂能非常輕鬆的自定義,不用像 Docusaurus 寫彆腳的 MDX 語法,現在也整合 TS/SASS/Tailwind;主題爆多,絕對碾壓其他所有靜態網站生成器。

Hugo 由於其強烈基於 HTML 的原因,絕大多數主題即使沒有 JS 的環境大部分功能也能正常運作,而其他基於前端思維 SSG 做出來的網頁更依賴瀏覽器 JS 環境

Hugo 已經驗證可規模化

Hugo 的缺點

Template 的 return 功能是唯一一個回傳物件的方式,但是這種方式超級難以除錯

Hugo 的 Go 模板需要額外時間理解,Go 模板混用 HTML IDE 支援困難,需要額外理解 Hugo/Go 語法和渲染方式,不支援所有 Go 語法,文檔雖然非常詳細,但是編排對用戶和開發者都雜亂難理解。

Shortcode 功能雖然直覺易懂,但是讓 Hugo 的 Markdown 難以遷移到其他 SSG。

Shortcode 功能一樣也是模板不是一個函數區塊,因此巢狀 shortcode 很容易出現問題。

Hugo 要使用現代前端技術非常困難,因為基本上只有 HTML/CSS/JS 三件套,要搞 SPA 也不容易,根本沒有幾個主題支援 SPA,沒有框架所有東西只能手搓,這代表所有 Hugo 主題都不會太複雜。

Hugo 可以整合現代前端開發但是有點麻煩,因為他和 npm 就是不同系統的東西。

Hugo 可以當作沒有函式這種東西,唯一最像函式的 partial 限制一堆,連輸入輸出都沒辦法明確標示,開發很痛苦。

Hugo 沒有金主支援,像是 Next.js 有 Vercel,Docusaurus 有 Facebook,Hugo 是純開源的專案,看天吃飯。

Hugo 十年了還不是穩定版本,一天到晚在搞影響下游的更新,穩定程度甚至不如 JS-based 專案,除非你完全不升級。

Hugo 只有兩個維護者,沒有任何團隊組織,所有開發都是維護者覺得好就做,覺得好,不想做的也不做。

Hugo 邏輯奇特,沒理由的不處理就算了,還把自己不處理當作不接受的理由。用戶沒發問不代表不需要,大家都自己爬文或是繞路解決不會特地去發文,還是他期待大家不爬文一直問重複問題?