Skip to main content

[Hard] 📄 Framework

1. Please explain and compare the advantages and disadvantages of SPA and SSR

請解釋並比較 SPA 和 SSR 的優缺點

SPA(單頁式應用程式)

SPA 優點

  1. 使用者體驗:SPA 的本質就是一個頁面,只是透過動態載入資料,結合前端的路由,讓使用者認為有在切換頁面,但實際上只是切換 component,這樣的使用體驗自然更為絲滑快速。
  2. 前後端分離:前端只需要負責頁面渲染與互動,而後端則只需要提供數據 API,不但減輕彼此開發的負擔,也更易維護。
  3. 網路優化:因為只需要載入一次頁面,不像傳統多頁面結構,每次切換頁面都需要重新載入,自然也就減少了請求的次數,降低 server 端的負擔。

SPA 缺點

  1. 搜尋引擎優化(SEO):SPA 的頁面都是動態載入的,因此搜尋引擎無法直接抓取到頁面內容(雖然近年 Google 聲稱有在改善這點),面對搜尋引擎的爬蟲,還是不如傳統的 HTML。
  2. 首頁載入時間:SPA 需要在 client 端載入並執行 Javascript,才能渲染出頁面,因此首頁的載入時間會比較長,尤其是在網路狀況不佳的情況下,可能會導致首次載入時間延遲。

SSR(伺服器端渲染)

SSR 優點

  1. 搜尋引擎優化(SEO):因為 SSR 是在 server 端就已經渲染好包含數據的頁面,因此搜尋引擎可以直接抓取到頁面內容,這也是 SSR 最大的優勢。
  2. 載入時間:因為 SSR 將原本的渲染負擔轉移到 server 端,可以縮短首次進入的渲染時間。

SSR 缺點

  1. 學習成本和複雜度:以 Next 和 Nuxt 為例,雖然他們本質都是奠基在 React 和 Vue 上,但是他們已經各自衍生出自己的生態系,無形中抬高了學習成本,以近期的 Next.js 14 改版來看,客觀來說,並不是每個開發者都能接受這樣的改變。
  2. 伺服器負擔:因為渲染的工作轉移到 server 端,可能會對 server 造成更大的負擔,尤其如果是遇到高流量的應用場景。

結論

原則上,如果是後台的系統,在沒有 SEO 的需求下,應該是沒必要使用 SSR 框架,除非是仰賴搜尋引擎的產品網頁,那確實可以評估採用 SSR 框架開發。

2. 請闡述使用過的 Web Framework,並比較其優缺點

兩者近年都往「以函式為主的組件開發」收斂:

Vue 3 透過 Composition API,把邏輯拆成可重用的 composable;React 則以 Hooks 為核心。在開發者體驗上兩者相當接近,不過整體而言,Vue 的上手成本較低,React 則在生態與彈性上更強。

Vue(以 Vue 3 為主)

優點:

  • 學習曲線較平滑
    SFC(Single File Component)把 template / script / style 聚在一起,對於從傳統前端(後端模板)轉過來的開發者很友善。
  • 官方約定明確、對團隊有利
    官方提供的風格指南與慣例清楚(檔案結構、命名、組件拆分方式),新成員接手專案時較容易維持一致性。
  • 核心生態完整
    官方維護 Vue Router、Pinia(或 Vuex)、CLI / Vite Plugin 等,從建專案到狀態管理、路由都有「官方解法」,降低選型成本。
  • Composition API 提升可維護性
    可以依功能拆出 composable(例如 useAuth、useForm),在大型專案中共用邏輯、減少重複程式碼。

缺點:

  • 生態與社群規模略小於 React
    第三方套件數量與多樣性不如 React,有些前沿工具或整合(例如設計系統、特殊場景的 library)會先以 React 為主。
  • 就業市場相對集中在特定區域/產業
    相較 React,國外或跨國團隊多半以 React 為主,在職涯彈性上相對劣勢很多(但在華語圈則持各半)。

React

優點:

  • 生態圈龐大、技術更新速度快
    幾乎所有前端新技術、設計系統或第三方服務,都會優先提供 React 版本(例如各種 UI Library、Chart、Editor、Design System)。
  • 彈性高、可因專案自由組合技術棧
    可搭配 Redux / Zustand / Recoil 等多種狀態管理,也有 Next.js、Remix 等 Meta Framework,從 SPA 到 SSR、SSG、CSR 都有成熟方案。
  • 與 TypeScript、前端工程化整合成熟
    社群對型別與大型專案的最佳實務討論很多,對長期維護的大型專案有幫助。

缺點:

  • 自由度高,團隊需要自訂規範
    在沒有明確 coding style、架構約定的情況下,不同開發者可能用完全不同的寫法與狀態管理方式,後續維護成本會提高。
  • 學習曲線實際上不低
    除了 React 本身(JSX、Hooks 思維)以外,還要面對 Router、狀態管理、資料抓取、SSR 等一連串選型,新手容易迷失在「要選哪個 library」。
  • API 變動與最佳實務演進較快
    例如從 Class Component 到 Function Component + Hooks、再到 Server Components 等,老專案與新寫法共存時,需要額外的遷移與維護成本。