網站網頁呈現有兩種方式，一種是 SSR：伺服器渲染（server side render，SSR） ，wiki：https://zh.wikipedia.org/zh-tw/%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%AB%AF%E6%B8%B2%E6%9F%93
這個是全端，頁面由伺服器端產出完整的HTML內容。

另一種則是CSR：客戶端渲染（client side render，SSR），通常是前後端的架構，由瀏覽器呼叫API取得資料，再透過瀏覽器/JS產生HTML元素來呈現頁面。

這兩種方法當然各有其優缺點。不過實務上比較多是看開發商（乙方）用那個就那個，畢竟出問題，客戶（甲方）頂多也是開ISSUE/BUG單，再由開發維運商處理。

就以維運的角度來看，如果是只有純網站（web端）來說，純SSR，純全端依然是最經濟的選擇。修改，調整功能一個人就搞定。若是客戶不喜歡太工程的畫面，也可以再配個比較有美感，HTML/CSS/JS比較強的全端分工一下。

但如果多種client端的時後（web ＋ 手機andriod/ios）CSR就是比較好的用法，server上寫一套API，三邊都可以用。不過很少有全方位全才都會寫的人，所以維運上，若有要持續調整修改功能，現今普遍分工至少4個人跑不掉（後端＋前端＋Android＋IOS，不分4個會被風向嫌要求多、血汗沒sense、早點離開這個爛坑QQ），而且這4個人工作量還可能沒滿載，所以要是沒有富爸爸，服務產品不賺，沒有源源不斷的專案，可能就養不起。

當然也可以用一些web跨手機框架的來精簡人力，不過目前看，還是沒有特別明顯的主流。我最近看到Google倒是很認真的要推Fultter的樣子，算SSR ，wiki：https://zh.wikipedia.org/zh-tw/Flutter 。material design 3 納入Web的UI/UX在慢慢補，覺得明顯就是在推 Flutter，https://m3.material.io/ 。早期material design （https://m2.material.io/ , https://m1.material.io/ ）是Android的UI/UX官方版（Google自己出自己推麻），但是經過當年的歷史（X）白老鼠（O），發現IOS學Android，Android學IOS，覺得這兩個系統超搞笑，不過還是贏被消滅的Mongo。

回到網頁網站來說，WEB端瀏覽器網頁用CSR，缺點是資料太明顯，容易被瀏覽器外掛截取，或偽造。

我覺得目前比較好的方式是看服務應用混搭比較好，就是分前後台來規劃，由後台處理機敏性比較高的資訊管理部份，會有登入機制，而且有登入績核資料，使用者真的想亂搞，也是查得到的。再者使用後台的多是管理者，不會有管理者想給自己找麻煩，亂玩線上系統。在這些前題下，想要用SSR，CSR都沒問題。

而前台，一般純資料顯示，也不牽涉個資的內容，用CSR跑可以在畫面呈現上有比較多的美化，也有助於網頁呈現的速度。而且API在資料傳輸上有很大的優勢，省流量，資料少速度也就快。

以開發團隊的角度來看，要選那種方式，基本上就是看公司政策囉。反正公司在運作的話，就是缺什麼人就補什麼人的概念。

這次小程式，因為是單人實作，我都是本著會什麼，就用什麼。所以這次應該就主SSR配CSR吧？！