選用 ASTRO 的歷程 | Toolizer 兔來社部落格

2025年9月24日 社長 技術交流
#Astro框架#技術選型#MPA架構#SSG靜態生成#Islands Architecture#網站框架#前端開發#技術決策
從原生開發到框架選擇,分享在建構 Toolizer 兔來社過程中的技術決策歷程,以及為什麼最終選擇了 Astro 作為主要開發框架。

最初的理想:純手工打造

其實一開始是打算不使用任何框架的。那時候有著一種理想主義的想法:既然是做線上工具,為什麼不自己從零開始構建呢?不依賴框架,完全掌控每一行程式碼,聽起來很浪漫,也很有挑戰性。

但是在開發了幾個工具後,發現還是有一些技術瓶頸在。全部自己處理的話非常費工費時。像是重複的 HTML 結構、樣式管理、JavaScript 模組化、SEO 優化等問題,都需要大量的時間來解決。每個新工具都要重複造輪子,效率確實不高。

框架選擇的考量過程

於是還是開始思考要使用什麼框架來協助開發了。首要考量當然是先從三大框架來看:Angular、React、Vue,這三個是前端開發界的主流選擇。

Angular

曾經學過,但是覺得太過複雜了,而且也很久沒碰生疏了。Angular 的學習曲線比較陡峭,對於快速開發小型工具來說可能有點過度工程化。

React

相較於 Angular比較輕量,而且之前學起來也覺得蠻有趣的。Component 化的概念很適合構建可重用的工具介面。

Vue

Vue 之前沒有接觸過,雖然查資料都說上手難度最低,而且中文資料最豐富。漸進式框架的設計理念也很吸引人。

意外的建議:認識 Astro

最後問了 GPT,沒想到建議我聽都沒聽過的 Astro,於是開始查資料。一開始確實很困惑,因為從來沒聽過這個框架,但深入了解後發現它的設計理念很符合我的需求。

框架類型的重要區別

考量到本站的主體是工具加上一些文章的類型,其實不需要用到太多應用框架,比較需要的是網站框架(我也是查資料才知道這個差異)。這個認知很重要,讓我重新思考了技術選型的方向。

應用程式框架

適合:

  • 複雜的使用者介面
  • 大量的狀態管理
  • 即時資料互動
  • 單頁應用程式(SPA)

例如:社交媒體平台、線上編輯器、遊戲等

網站框架

適合:

  • 內容展示為主
  • 靜態或半靜態內容
  • SEO 重要性高
  • 載入速度要求高

例如:部落格、文檔網站、工具集合站等

Astro 的 MPA 架構優勢

因為內容大部分是固定的,所以立刻決定試用 Astro,他又是 MPA(Multi-Page Application),很符合本站的需求。

對於 Toolizer 這種工具集合站來說,MPA 架構非常合適。每個工具都是相對獨立的,使用者通常只會使用單一工具,不需要在工具間頻繁切換。MPA 的優勢能夠充分發揮:快速載入、良好的 SEO、簡單的部署。

靈活性與未來擴展

而且之後有需要的話可以再結合 React 或是 Vue,目前使用上來說覺得也是蠻不錯的。這就是 Astro 的另一個強大特性:「Islands Architecture」(島嶼架構)。

Astro 的 Islands Architecture

這個架構允許你在靜態 HTML 中嵌入互動性的「島嶼」:

  • 大部分內容保持靜態,載入速度極快
  • 需要互動的部分可以使用 React、Vue、Svelte 等任何框架
  • 每個島嶼獨立載入,不會影響整體效能
  • 可以根據需要選擇不同框架,不必受限於單一選擇
實際應用:例如在靜態的工具介紹頁面中,可以嵌入一個用 React 寫的互動計算器,既保持了頁面的載入速度,又提供了豐富的互動體驗。

實際使用體驗與心得

經過一段時間的使用,Astro 確實符合預期。開發體驗很流暢,學習曲線也不會太陡峭。特別是對於有 HTML、CSS、JavaScript 基礎的開發者來說,上手相對容易。

優勢體驗
  • 編譯速度快,開發體驗佳
  • 生成的網站載入速度極快
  • SEO 優化輕鬆達成
  • 部署簡單,支援多種平台
  • 元件復用很方便
注意事項
  • 相對較新,社群資源較少
  • 部分第三方套件可能不相容
  • 複雜狀態管理較為困難
  • 需要適應新的開發模式

技術決策的反思

回頭看這個技術選擇的過程,最重要的學習是:選擇技術不應該只看流行度或個人喜好,而要根據專案需求來決定

Toolizer 的核心需求是:快速載入、良好的 SEO、簡單的維護、適度的互動性。Astro 完美符合這些要求。如果當初選擇了 React 或 Vue,雖然也能達成目標,但可能會有過度工程化的問題。

結語:持續學習與調整

選擇 Astro 到目前為止是一個正確的決定。它讓我能夠專注在內容與功能的開發上,而不是花太多時間在框架本身的複雜性上。

當然,技術決策永遠不是一成不變的。隨著專案需求的演進,可能會需要調整或引入其他技術。但 Astro 的靈活性給了未來很多可能性,這也是當初選擇它的重要原因之一。

對於有類似需求的開發者,我會推薦考慮 Astro,特別是當你的專案以內容展示和工具提供為主時。但記住,最重要的還是要根據自己的具體需求來評估。

對於框架選擇有什麼想法或疑問嗎?

歡迎透過聯絡我們分享您的看法,或是討論技術選型的經驗!