輕前端與前端工程化
這是一篇關於前端心得、感想的文章。
最近到了新公司，對於 Web 開發的環境有不小的變化，這也引起了個人一系列的思索，我該如何更有效率、更輕巧的開發前端網頁呢？
目前作為前端開發已邁入第三年，個人是轉職者，所以不像很多老前端那樣，一路從 Dreamweaver 年代走到現代前端開發。我只粗略的學了 HTML / CSS / JS 的基礎之後，就直接進入 Express.js 的 SSR 架構，接著就直接開始學 Vue 體系的 CSR (Client Side Render)。
雖然自己有研究 jQeury，也零星寫過 PHP + jQuery 的頁面，但終歸我沒經歷過那個年代，所以在認知上就覺得要做前端，就應該 React or Vue 挑一個。
認為直接上 create-react-app 或 vue-cli (亦或是走 vite app 體系) 才是高級且正確的作法。甚至也嘗試過 Next.js 這類基於 React 的高階框架，用 SSR、CSR、SSG 混合的方式做了些網站。
差不多在第一年後半，迷上了 Typescript，之後所有專案都改用 TS 來進行。有寫過 TS 的應該都知道，這玩意好歸好，但煩人的時候真的很煩人，常常寫一個頁面組件，引一些 lib，結果大半時間都花在調教 type 定義上頭。
在前一間公司時，由於該公司不是專門做 Web 的，所以沒有既存的 Web 開發體系。且大多工作需求都是獨立性質，只有 2–3 頁的活動網站，不太需要考慮長期維護。所以很大程度上，我可以愛怎麼來就怎麼來。
所以抱持著邊做邊學新技術的想法，常常會今天用 Vue2，明天用 Vue3，後天用 React，把我當下感興趣的技術，直接就在新專案做嘗試。
如今換新公司，這邊有一個經營很久的老網站，是走 PHP Server 的架構。每個頁面都是單個獨立的 .html 或 .php file，所以物理性上就無法引入 React、Vue 來做前端 App，真要硬來就會跟整個重作沒啥太大區別。
但是用習慣了這些前端框架，要再回去寫傳統網頁，用 vanilla js 與 jQuery，就格外的不舒適。我沒辦法對相似的 html 做 loop，沒辦法輕鬆的條件渲染，沒有現成的 Reactive 機制去連動我的頁面 state，也無法享受基於前端框架體系的各種便利 lib。
當我死命地寫了一整排 HTML 根本長的 95% 一樣的 products list 之後，一碰到修改需求，就得很蠢的一個一個手動改，HTML 還不能拆分，一大坨在那邊，真的會改到懷疑人生。
身為工程師，當碰到大量重複性的體力活時，就表示技術有優化空間了。
現在很多需求是活動、宣傳頁面，只有一頁，沒啥 JS 邏輯需要處理。如果每個活動頁都起一個 Vue / React 專案綁上 Webpack，實在太過笨重。但不上這些框架，寫起來還是有些難受的。
於是乎，這段時間就開始不停的思考，我有甚麼方法可以把前端工程化那套技術給拉進來，又不影響既有的網站架構，讓我工作可以更加效率化，同時保持技術棧的單純性呢？
主要訴求：
- 頁面內容組件化、使其可複用
- 對 HTML 與 CSS 做預處理，減少繁瑣重複的 coding
- 要考慮 SEO 需求，不能純 SPA，也不能走 Node Server SSR
- 技術棧要單純、輕量，可輕鬆裝卸讓 PHP Server 好處理
- JS 聯動 HTML 響應式開發 (可無)
頁面組件化跟預處理應該算是一塊的，既然能夠組件化了，也就表示被 JS 或 Node 接管了，自然可以做到預處理器該有的功能。這其實可以直接寫 .php 來解決，反正是 PHP Server，但沒事我實在不想混 PHP。
至於 JS 部分個人是覺得還好，畢竟大多是活動頁，沒啥複雜邏輯需要處理。
解決方案的部分，目前大致有這幾種想法：
- Pug + Sass，經典預處理體系
- Vue or React SSG (or pre-render)
- Next.js (Gatsby.js) or Nuxt.js (VuePress)，一樣走 SSG 那套 static export
- Vue or React，拉 CDN 走無編譯環境
- Svelte 新型態框架
來一個一個說明一下，其中 2 跟 3 是差不多的概念，只是要用啥方式框架作為 base 的問題而已。
前端預處理 Pug + Sass
這個老前端應該都不陌生，雖然我沒做過這樣的模式，但這學習成本估計會比那些現代前端框架要低很多，這作法要從傳統方式轉過來也相對容易。
只是這畢竟是上個世代的做法，考慮未來前端仍舊會持續演進，基於學新不學舊的原則，姑且先不考慮。
SSG (靜態生成) 或 Pre-Render (預渲染)
這兩個就我的理解，應該是在說同一件事。概念上，是為了解決 SPA 框架首屏渲染只有一個空 div ，造成 SEO 不良的問題。在編譯的時候，由程式先去執行一次 JS 內容，然後把完成的頁面快照下來存成 .html。
這樣就能獲得一個有初始 HTML 的頁面，不僅能改善 SEO，也能解決 SSR 回應太慢的問題。預渲染出的網頁，仍舊保有 Vue 與 React 的機能，可以在 Client 端上，繼續進行 CSR 的任務。
React 或 Vue 都有相關的插件可以做 SPA 預渲染，甚至也有 Gatsby.js、VuePress 這些專門用來做 SSG 的框架。也可以選擇用功能更多的 Next.js 與 Nuxt.js。
學習成本也是由簡至難，最簡單的就是用 create-react-app 或 vue-cli 直接套個 prerender-spa-plugin 之類的插件就完事了。React 跟 Vue 也有各自專門的第三方 SSG / Pre-render 插件，甚至也有 vite 的 (限 Vue)。
如果要採用其他框架來做 SSG，雖然功能更齊全，但學習成本也高，勢必也會碰到各式各樣的實作問題。
我個人是已經會 Next.js 了，所以對我來說直接用 plugin 或是 Next.js 是比較快能掌握的。就不用為了 SSG 而花時間再去學新框架。
這套做法雖然能保留這些前端框架的便利特性，能更方便的使用社群資源。但缺點也是很明顯的，就是太肥大了。
無論是要每個活動頁都起一個帶框架的專案，還是一個專案放一堆活動頁？在管理上勢必會延伸出各種問題。
拉 CDN，局部使用
這個是比較靈活且適配的方案，直接用 CDN 引入 Vue 或 React 核心，無 node 環境、無 webpack，獨立性強。針對活動頁這種需求，會比大費周章地用大框架，卻只出個一頁 SSG 要實在許多。
活動頁大多 JS 邏輯都不複雜，所以可以專注在 HTML 與 CSS 上，利用前端框架管理 DOM 的方便性，來讓我們更加高效、輕鬆的寫網頁。
React 本身比較討厭一點，如果不用 jsx 基本廢了大半，但 jsx 是瀏覽器不支援的玩意，必須要一併用 CDN 引入 babel standalone 才可以讓瀏覽器在運行時處理 jsx。
但這可想而知，是會影響效能的。所以有老外想出了替代方案，使用一套叫做 htm 的 jsx-like 套件來取代 jsx，就可以排除掉 babel 了。
而 Vue 這邊就比 React 要更有優勢，因為它是用一般 string 的方式來做 html template。使用 CDN 引入的話，似乎有更多前端會選擇用 Vue。不過個人對這兩邊用 CDN 寫網頁的經驗都不是很豐富，所以無法提出更多的觀點。
Vue 這邊也有個第三方 lib 叫做 vue3-sfc-loader，可以讓瀏覽器直接解析 .vue 檔案，寫起來會更加舒服。但這就會跟 React 的 jsx 問題一樣，勢必會拖慢瀏覽器的效能。
CDN 引入看來是個不錯的方案，每個活動頁專案都可以保持在無 npm 環境，想放到哪個 Server 就整包靜態檔案丟過去就好。
但這也是有些缺點的，像是 CDN 引入就無法享受 VScode 的智能提示，如果強迫症想用 Typescript，會非常痛苦。要拉相關體系的 lib 也比較麻煩，甚至未必有出 CDN 讓我們拉。
Svelte 新型態框架
最後來聊聊 Svelte，近幾年竄紅的新框架，雖然我是這一兩年才聽說這套，不過他好像已經存在一陣子。有別於御三家 Angular、React、Vue，用不同的思路來處理前端。
雖然還沒實際下去玩過，但粗略爬了一些文章，這套感覺很符合我的需求。它在概念上比較接近預處理器，是在編譯時把事情都處理掉，build 完後的頁面，不會像那三個 SPA 框架一樣，不會有個 Svelte 核心在瀏覽器上運作。
由於不是在 runtime 時工作，不用內嵌核心，打包後的 size 勢必會比 SPA 框架輕量很多。而且它的 example code 看起來非常的舒服，號稱學習成本低，似乎是一個很值得玩玩的東西。
Pug 這類東西，缺點就是它只處理 HTML。而 Svelte 會更像 Vue、React 那樣，可以把 HTML / CSS / JS 都打成一包組件。
目前看一些介紹，它似乎很適合處理那種用原生去寫有點麻煩，但拉 SPA 框架又有點殺雞用牛刀的場合，也就是各種獨立的活動頁。
詳細的介紹 Google 可以查到很多，這邊就不贅述了。等實際下去玩過之後，有緣再來分享心得吧。
最後來總結一下，上面講了一堆，好像沒呼應到標題的樣子 (苦笑)。
會去思考這些，主要還是因為現在的工作需求不適合無腦拉 React or Vue 了。但又不想放棄這些前端框架方便的地方。想著想著就開始思考，我真的需要 npm 環境、真的需要 webpack 嗎？
尤其是像 Next.js 與 Nuxt.js 這樣的框架，其實學習成本是很高的，混合使用 SSR、SSG、CSR，每個環節都很考驗工程師的知識儲備。在用這些框架的時候，時常感覺精力都浪費在的框架本身的各種設定、渲染流程，而不是網頁的核心內容上。
就在我思考這些問題的同時，看到網路上有一些「輕前端」的概念，在探討前端是否真的需要每個專案都拉個大框架來做？尤其是 React 那邊，還有一堆 re-render 之類的奇妙狀況要去考慮，處理這些事情是否會有過度工程化的疑慮？
前端工程化的核心目的是希望讓工作效率化，而不是增加工作的複雜度。每個網站都有不同的需求，適合不同的技術棧。能否靈活的適材適用，不同情況使用不同技術來處理，或許比死嗑單一技術要來的更為重要。
