天空的垃圾場 - 使用 GatsbyJS 改版 Blog

06 June 2020 — Written by Sky Chang
#Node.js#Hexo#Hugo#Github#GatsbyJS#Wyam#Sky的IT碎碎念

10 Years - 天空的垃圾場

在 2010-05-03 的那一天,產生出了人生中的第一篇 Blog,而且還是寫 Flex 呢 XDD ( 為了寫這個序,剛剛還特別去查了一下 ),當然更早之前也用過 Workpress,但後來是覺得要管理 Workpress 很麻煩...所以就使用了 Google 託管的 Blogger,而過程中,也建立個分站 點部落天空的垃圾桶,但後來兩邊管理不容易,點部落就放棄掉了。

2020 06 06 13 55 52

而到了 2020-06-06,也剛好突破了 10 年的歷程,而且以前的 Blog 竟然也破了 120 萬的點閱 (驚),當然,朋友間很多都超過這個點閱,但還是讓小弟很驚訝啊啊啊。

不過也在這邊提醒一下,有些東西很舊了,查閱資料的時候,要注意有沒有更新的資訊喔~

2020 06 06 13 26 41

後來因為以前的 Blogger 開始不堪使用,再加上早期使用的 Live Writer 已經沒在更新了,潮流也開始走向 Markdown 格式,所以 2015-11-22 將 Blog 轉移到現在的位置,也就是 Github 上。

2020 06 06 13 52 58

其實轉移的過程,也是考量到,可能還是有些人需要查找就的資料,所以舊的 Blogger 和網址也原封不動地留著,但為了統一起見,也將所有舊的文章全部都轉成了 Markdown 格式,所以現在的 Blog 還是可以查到這 10 年來的資料。

( 也可以發現,要相依以前,真的不是容易的事情 QQ )

而除了將平台轉移到 GitHub 上外,當時,也從 Hexo 和 Jekyll 來做選擇,當時最大的大概就是這兩個產生靜態頁面的框架,也讓人感受到,原來寫 Blogger 也要用 CI / CD 啊!!,而當初因為像嘗試看看,所以選用了 Travis 當作 CI/CD 的服務對象,而這次改版,就是 天空的垃圾場 V2

而隨著時間,終於到了 10 年後的今天,也剛好因緣際會,又要再進行一次 Blog 的改版,也就是 天空的垃圾場 V3

天空的垃圾場 V3 技術的選擇

無論是 WordpressBlogger點部落Hexo、甚至是 Hexo 的 NexT 主題,都是非常棒的體驗,尤其是 NexT 主題,到現在 天空的垃圾場 V3 ,也還是有很多地方還沒辦法達到 NexT 主題的完整性,例如 : Google 分析 的整合、DISQUS 留言機制,標籤雲、Tag 頁、歷史軌跡、大綱模式 等等等 ( 列完突然有點不想換了 QQ ),真的是做得很棒,小弟也在這邊感謝這些技術軟體,開發這些的技術人,讓我們能方便的建立 Blogger ( 鞠躬 )

而這次,想要更換的原因,其實不是因為 Hexo 要被淘汰掉,時間差不多該換了、markdown 不好 等這些原因,反而是因為 markdown 越來越重要,而 Hexo 有一個從我一開始使用,到現在,都很在意的一個問題,所以才想說,過了那麼久了,有沒有更好的解決方案呢?

Markdown 和 圖檔無法在同一個資料夾

其實這個困擾我很久,就像下圖來講,我很希望能將 Markdown 和 圖檔放在同一個資料夾做管理,因為每篇都是獨立的,我要挑出來,複製出來到別的地方也方便。

2020 06 06 15 06 27

會有這個需求,就像上面提到的,近來用 Markdown 的需求越來越大,以前還是可能用 Word 編輯文件提供給客戶,近來,也打算開始全部採用 Markdown 編輯,輸出 pdf 給客戶,而也因此,一個有結構的管理,對我來講是必要的。

而在 Hexo 上,這塊比較沒辦法有好的支援,雖然我也有查到,有一些外掛,或是修改 Source Code 的方法,甚至 Hexo 也提供了可以將圖檔放到與 md 檔案名稱同一個資料夾的功能,但外掛看下來太多,也沒有統一的解決方案,改 Source Code 依照小弟的個性,就算了 XDDDD ( 人懶,又笨 ),至於最後一個方案,其實這幾年都一直這樣使用,但也常常遇到一個問題,就是在 VS Code 下,Preview 產生出來的畫面,是看不到圖檔的..

簡單的說,雖然 Hexo 可以將圖檔放到與 md 檔案名稱同樣的目錄,但使用md 標籤的時候, ![](01.png) 裡面是不能包含實際路徑的,舉例來說,我有一個 Test.md 檔案,而我的圖檔就會是這個位置 Test\01.png,但我使用的標籤,只能使用 ![](01.png),不能使用 ![](test\01.png) 但如果在 vs code 編輯下,必須要是 ![](test\01.png) 才能正常顯示 ( 合理,因為原本就在 test 目錄底下 ),但因為 Hexo 會重新編譯成 HTML,編譯出來圖片的位置,就會將 01.png 和 index.html ( 從 test.md 來 ) 放到同一層目錄,也因此,你的 md 標籤,必須要寫成 ![](01.png) 才行。

老實說,這個問題困擾我很久 QQ.. 也是這次想換的主因。

Hugo 和 Hexo 網址的相容

於是乎,除了 Hexo 外,也看了 Hugo 這套由 Go Lang 寫的靜態網頁產生器,Hugo 也是非常棒的產生器,其實當初在評估 Hexo 的時候,也看了 Hugo,但當時 Hugo 才剛出,無論是樣板或是內部都還不太成熟,所以就選擇了非常成熟的 Hexo,而且上面提過,NexT 樣板真的是做得很棒,當時的 Hugo 比較沒辦法做到那麼完整。

而這次,也從新回過來看 Hugo,也發現,Hugo 也真的很棒,編譯的速度極快,文件樣板也很齊全,但.... md 和 圖檔的問題和 Hexo 一樣 ( 嘆 ),也花了很多時間找資料後,得到要解決這個問題,可以啟用 Hugo 一個 ugly urls 的功能,但這個功能就如字面的意思,網址會變得很醜...,會多出 xxx.html,其實,若是第一次寫 Blog 可能就沒差,但對我來說,這會影響到我現在 Blog 的 SEO ( 謎之聲 : 明明最近也沒啥文章啊 XDD )

像現在 天空的垃圾場 V2 的網址是 https://skychang.github.io/年/月/日/英文主題,我覺得這還不錯,有時太久的文章,技術價值可能就不夠,可以透過這個網址,可以讓看文章的人,馬上知道,這篇文章要不要捨棄 (咦),所以,在選擇上,我希望的是保留這個網址的格式,讓現在的連結都還能生效 ( 文章裡面也有很多 Ref 自己位址的連結啊!!,要一篇一篇改完死人的 ),所以雖然 Ugly urls 可能可以符合我的 md 和 圖檔同位置 的需求,但這樣,網址位置就不一樣了 ( 因為會多出 .html )

所以,Hugo 就被我捨棄掉了,但這純粹是小弟的需求考量,而非 Hugo 不好。

其他平台呢?

當然,從新選擇 Blog 平台也是不錯的,例如 老牌的 Wordpress,台灣技術大神,如 James 大大使用的 點部落,或是全球很多人使用的 Medium 等等等,都是不錯的平台,如果不想特別自己處理這些有的沒的事情的話,其實這些平台很適合隨心所欲的撰寫,但對於小弟,可能比較不適合。

還有選項嗎

有的,過程中,我也看到好友 Alan Tasi : Wyam 是什麽? 這篇的介紹, Wyam 是 .NET 家族出的靜態頁面的工具,裡面就是用我熟悉的 Razor 等撰寫的,而 Alan Tasi 就是用這套建立的,除此之外,這篇文章也提到,StaticGen,一個靜態工具的整理網站,裡面有列出非常多的工具,包含前面提到的那些工具,甚至提供了 GitHub Star 的數量當作參考,至於 Wyam,雖然是自己原生習慣的東西,也可以看到 Alan Tasi 的 Blog 也是滿滿功能,我相信應該也沒什麼問題,但不到為何,Wyam 就是興趣缺缺 QQ,但如果對這太有興趣的話,可以問問 Alan 大神 XDD ( 立馬推坑 )

為什麼沒選 VuePress

除此之外,從這個網站,也看到 VuePress,據說目前 Vue 的官網也是用這個做的,尤雨溪大大也在 Core Team,但小弟本身是 Vue 白痴,不像 Kuro 大神一樣,那麼熟練 Vue,所以就沒深入研究,有興趣的可以自己參考看看,我相信也是非常不錯的一套。

在看 GatsbyJS 之前

後來,發現除了 Nuxt 外,還有一個非常高星星數的框架,而這套就是 GatsbyJS,而會被他吸引到的其中一個原因就是,嗯,他是髮蠟嗎 XDDD

( 題外話,Nuxt 小弟也沒深入去看,因為看了 GatsbyJS 後,就決定試試看了 )

再繼續往下看之前,我先說說結論....

基本上,GatsbyJS 並不是一個簡單容易使用的工具,這邊說不簡單,不是說 GatsbyJS 設計得不好,GatsbyJS 設計得很棒,但對於一般只想寫 Blog 的朋友來說,就沒那麼單純使用。

如果以難易度來說,用 Medium、Wordpress、點部落都是開箱即用,有線上編輯器,甚至可以不用瞭解 Markdown,對於一般人來說非常友善,適合只想專心寫作的朋友。

而 Hexo、Hugo 對我來說,比較像中度,你可能需要下一些指令,例如 npm install 來安裝 Hexo-cli,也可能要用 Hugo 的 Cli 進行編譯,甚至有時還要滿足工程師的虛榮心 (笑),來完成文章的 CI/CS,但對於一般工程師來說,這是 ok 的,是可以接受的,甚至用完後,還有點滿足 (咦),但不管怎樣,處理完指令後,載入樣板後,接下來大概就是專心寫作了。

GatsbyJS,基本上,他的定位,本來就不是用來當作寫 Blog 的 ( 雖然一樣可以 ),他的出發點本來就是不同的 ( 後面再提 ),但不管怎樣,GatsbyJS 很多細節,你要自己去刻畫面和調整。

說更明確一點,如果你想使用 GatsbyJS,強烈建議要先滿足這些技能

  • JavaScript & CSS
  • ReactJS
  • GraphQL

沒錯,你要熟悉 ReactJS ( 至少要會寫簡單的 CRUD 應用 ) 不熟悉ReactJS,你用 GatsbyJS 可能會很慘 QQ

而小弟是因為特殊需求,選了 GatsbyJS,但如果你只想開心地寫文章,不想管這些,就千萬不要選擇 GatsbyJS...

淺談 GatsbyJS

沒錯,後來小弟選擇的是 GatsbyJS,其實選擇這個,就快要等於自己刻 Blog 了 QQ,在看自己刻這件事情之前,我們先看看 GatsbyJS。

以數據為導向

GatsbyJS 的官網,一張圖能解釋 GatsbyJS 的就是這張圖,就如這張圖一樣,其實你可以看到,他的目的,本來就是不做 Blog,而是一種以數據為基礎的架構。

2020 06 06 16 17 43

上方是資料來源,換言之ㄝ你可以從任何地方,取得資料 ( 透過 GatsbyJS 大家撰寫的 PlugIn),你就可以從 Wordpress、Facebook、Markdown 等等取得資料。

對,沒看錯,並不是只從 DB 而來,你可以將你以前寫的 Wordpress,透過 GatsbyJS 的 Wordpress PlugIn,將 Wordpress 文章轉成 JSON,給 GatsbyJS 吃進去,同樣的,不只是 Wordpress,很多的 CMS 都支援,處此之外,熟悉的 Markdown、APIs、Databases、YAML、JSON、CSV,都有對應的 PlugIn,可以吃進去,而吃進去的資料篩選,就是使用 GraphQL。

接下來,每個頁面,並不是動態渲染了 ( 像 PHP、ASP.NET MVC、JSP 等都是動態渲染出 HTML 後,傳給 Browser ),而 GatsbyJS,則會在編譯期間,將資料與 ReactJS Bind 後,產生靜態的 HTML。

也因此,你可以輕鬆地將此靜態網頁部署到 GitHub Page、Azure Static Website,而不需要有 .NET Core、JAVA 等等的後端引擎。

也因為都是靜態的,所以 SEO 就會很好 ( 之前 Google 說好的 SPA SEO 呢?? ),也非常適合產品介紹的官網、Blog 等等。

而說到這,其實也可以發現,他的彈性很高,也因次,你有很多客製化的空間,但相對的,這個客製化的空間,就是開發人員自己要弄了 (哭)

不過,至少不用再去搞 Webpack 這類東西就是了 (其實現在三大框架也都把 Webpack 封裝了,想想以前 QQ )

Starter

接下來,我們可以看看 starters,在第一次看到的時候,原以為這就類似其他框架的樣板 XDDDD

2020 06 06 16 32 33

對,你可以把你的它當作樣板,但他為什麼不用 Template 而用 Starter 在你深入的時候就知道了 XDDDDD。

他就像 React 依樣,我們在寫 React 的時候,一開始可能要兜很多有的沒有的東西,會很辛苦,所有有類似 Bootstrat 的東西,可以讓你快速的將基礎的東基建後好後,再依據這個基礎建構開始自己修改與使用。

而 Starter 就是這種東西,你當然可以從頭開始使用 GatsbyJS,那你就會和他的教學課程一樣,對,一開始什麼都沒有 (翻)。你需要自己去載入讀取 Markdown 的 PlugIn,要自己去處理 React 和 Markdown Source 的 Bind,要去處理網址的路由,要去處理分頁,要去寫 Tag 等等等。

所以 Starter,就是有很多神人,將自己的設計,和一些基本的 Code 都準備好,讓你安心上路 (喂),但反過來說,並不是用了 Starter 就可以開始寫文章了,而是這個坑才開始呢 (誤)。接下來,你就要自己去調整裡面的內容,開心地寫寫 React,玩玩 GraphQL...

像我自己,我就調整了路由,CSS 等等,而如果未來要使用 Google 分析,也要自己加上去、討論區,也要自己整合,標籤雲,也要自己弄 ..... ( 感覺有點後悔了 ),但也因此,他可以完全符合我想要的文章結構,路由結構,甚至,我願意的話,我甚至可以將 Study4 粉絲團的貼文,直接整理到我的 Blog 裡面呢!! ( 當然,我覺得我應該沒時間搞這塊 = =|| )

速度

以整個編譯速度來說,其實 GatsbyJS 並不快,和 Hexo 或是號稱神速的 Hugo 來說,GatsbyJS 其實慢很多,但速度其實對小弟沒影響,第一,原本就在VS Code 裡面,先預覽畫面了,再來,後面其實會整合 GitHub Action 做 CI/CD,所以寫完,簽入上去 GitHub 後,就不關我的事情了 XDDDD,所以速度上的影響,不是小弟的考量。

後記

總之,隨著寫文章十週年,也終於來到新高度 (咦),也因為自己有一些奇怪的需求,而開始使用了 GatsbyJS,來當作未來 3 年左右的 Blog 平台框架,也可以發現,雖然感覺只是短短的十年,但技術的進步也真的是神速,從動態頁面,到服務,到產生靜態頁面,到嶄新的透過各種資料來源產生靜態頁面,搞不好 10 年後,就是 AI 自動寫文章了呢。

不管怎樣,這十年來,感謝各位技術朋友們的關愛,就讓我們繼續邁入下一個十年吧!

參考資料

Sky & Study4.TW