開場白：所以，到底要不要做PWA？
今天要來聊聊「網頁版App」，也就是 PWA (Progressive Web App)。最近好像又很多人在問，特別是那種預算有限、想快速驗證市場的新創團隊。他們最常問我的就是：「欸，我們到底該不該做 PWA？還是直接捏著預算衝原生 App？」
老實說，這個問題沒有標準答案，但我的想法是這樣：如果你想快速接觸使用者、不想被App商店綁架、而且你的應用程式不是那種需要動用所有手機底層硬體功能的怪獸，那 PWA 絕對是個值得你認真考慮的選項。 簡單講，它就是一個讓你網站「偽裝」成 App 的技術，使用者可以直接從瀏覽器「安裝」到手機桌面，有圖示、能離線用、還能推播通知。
不過呢，事情總沒那麼單純。PWA 雖然聽起來很美好，但它在不同手機（特別是 iOS）上的支援度還是有些坑，而且使用者知不知道可以「安裝」網站，也是個大問題。 所以這篇草稿，我會把我腦中的一些想法整理出來，從技術選擇、開發工具有哪些，一路聊到現實中的優缺點，希望能幫大家理出一個頭緒。
重點一句話：PWA就是用最低成本，賭一個App的未來
如果你沒時間看完全部，那我會說：PWA 讓你可以用一套網頁程式碼，同時搞定桌面和行動裝置，不用養兩組開發團隊，也不用被應用程式商店抽成。 這對於初期市場驗證、內容發布、電商這類型的服務來說，真的是省時又省錢。很多大公司像 Twitter Lite 和樂天24，都是用 PWA 來拓展新市場或提升使用者留存。 當然，這是有取捨的，你會犧牲掉一些原生 App 才有的極致效能和完整的硬體整合。
怎麼做？PWA的關鍵三要素與開發框架
好了，進入正題。要讓你的網站變成一個 PWA，基本上就是要搞定三樣東西：
- 一個安全的連線 (HTTPS)： 這沒什麼好說的，現在的網站標配。瀏覽器規定 PWA 必須跑在 HTTPS 上，這是為了安全。
- 一個描述檔 (Web App Manifest)： 這是一個叫做 `manifest.json` 的檔案。 你可以在裡面定義你的 App 名稱、圖示、啟動畫面顏色等等。瀏覽器會讀這個檔案，才知道怎麼把你網站「安裝」成一個像 App 的樣子。
- 一個服務員 (Service Worker)： 這東西是 PWA 的靈魂。它是一段在背景運行的 JavaScript 腳本，可以攔截網路請求，讓你做到離線快取、背景同步、推播通知這些酷東西。 簡單說，就是靠它，你的網頁才能在沒網路的時候還能顯示一些東西，而不是直接給使用者看「無法連上網路」的恐龍頁面。
聽起來好像很複雜？其實現在很多開發工具都把事情變簡單了。如果你是用現代前端框架，基本上都有 PWA 的「一鍵啟動」套餐。 像我自己在用的幾個：
- React： 可以用 `Create React App` 直接建立一個 PWA 模板。
- Vue： `Vue CLI` 在建立專案的時候，勾選 PWA 支援就行了。
- Angular： 也有 `Angular CLI`，一個指令 `ng add @angular/pwa` 就能幫你把 Service Worker 跟 manifest 都設定好。
對了，還有一個 Google 開發的函式庫叫 Workbox，它專門用來簡化 Service Worker 的撰寫，可以讓你輕鬆設定各種快取策略，蠻推薦大家去看看的。
開發工具怎麼選？React、Vue、Angular大亂鬥
這個問題嘛，老實說有點像在問「滷肉飯、控肉飯、雞肉飯哪個好吃？」，其實各有優缺點，看你的團隊習慣跟專案需求。我這裡直接用一個表格來呈現我的主觀想法，可能會比較清楚。
| 框架 | 我的感覺 (優點) | 我覺得麻煩的地方 (缺點) | 適合誰用？ |
|---|---|---|---|
| React.js | 社群超大，基本上你遇到的 PWA 問題，網路上都找得到解答。 `Create React App` 開始很方便，而且像 Next.js 這種框架對 PWA 的支援也超好。 | 自由度太高了...有時候反而很煩惱。你要自己決定路由、狀態管理，還有 Service Worker 的細節設定，新手可能會有點不知所措。 | 團隊已經熟悉 React 生態系的，或是需要高度客製化、靈活度的專案。 |
| Vue.js | 學習曲線真的很平滑！ Vue CLI 的 PWA 插件設定很無腦，幾乎是下一步、下一步就搞定了。官方文件寫得也清楚，對新手非常友善。 | 雖然社群也很大，但有些比較冷門的 PWA 進階應用，資源就沒有 React 那麼鋪天蓋地。 | 新創團隊、中小型專案，或是想從傳統 jQuery 開發轉過來的人，我覺得 Vue 是個很棒的起點。 |
| Angular | 它就是一個「全家餐」。從頭到腳都幫你規定好了，非常適合大型企業專案，大家照著規矩走，程式碼比較不會亂掉。它的 CLI 整合 PWA 也很強大。 | 架構龐大，學習門檻高。 如果你只是想做個簡單的 PWA，用 Angular 有點殺雞用牛刀的感覺。而且 TypeScript 是標配，不習慣的人要花點時間適應。 | 大型企業、需要長期維護、對程式碼一致性要求很高的團隊。 |
限制與現實：PWA不是萬靈丹
講了這麼多好話，也該來潑點冷水了。PWA 最大的痛點，說穿了就是「Apple」。 雖然 iOS/Safari 現在也支援 Service Worker 跟 Manifest，但體驗就是比 Android/Chrome 差一截。
比如說，在 Android 上，Chrome 會很聰明地跳出一個「新增到主畫面」的提示，引導使用者安裝。 但在 iOS 上，使用者得自己手動點「分享」按鈕，然後在長長一串選項中找到「加入主畫面」，這個操作流程藏得太深，大部分使用者根本不知道。 這是個很大的推廣障礙。
另外，推播通知在 iOS 的 PWA 上也是個大問題，支援度很不穩定。還有一些深度的硬體整合，像是藍牙、NFC，PWA 的存取權限還是不如原生 App。 所以如果你的應用非常依賴這些功能，那可能還是得走原生 App 的老路。
還有一個很有趣的觀點，我是在國外開發者論壇 web.dev 上看到的，他們提到 PWA 有個「認知問題」（awareness problem）。 就是說，不只使用者不知道 PWA 是什麼，連很多企業主、產品經理也搞不清楚。他們會用原生 App 的標準來要求 PWA，這就會產生很多溝通上的困難。反觀台灣的一些技術部落格，像是 iT 邦幫忙或 Huli's blog，大家比較多是從開發者的角度分享實作經驗，點出 iOS 的支援度問題，但比較少提到這種商業溝通層面的挑戰。 我自己是覺得，在台灣推 PWA，前期的使用者教育成本真的要考慮進去。
常見錯誤與修正
最後，整理幾個我剛開始玩 PWA 時常踩的坑，希望大家可以避開：
- 離線體驗亂做： Service Worker 最大的好處是離線，但很多人只是隨便快取了首頁，結果使用者點了其他連結就壞了。你應該要設計一個完整的離線體驗，至少要有一個美觀的離線提示頁面，告訴使用者現在沒網路，而不是直接顯示瀏覽器錯誤。
- 忘記更新 Service Worker： Service Worker 一旦安裝，就會一直用舊的快取。當你網站更新版本後，一定要有機制去更新 Service Worker，不然使用者永遠都看到舊的東西。Workbox 在這方面處理得不錯。
- Manifest 檔亂寫： 像是圖示尺寸沒給對，或是忘了設定 `display: standalone`，結果安裝後還是用瀏覽器分頁開啟，那 PWA 的感覺就全沒了。 建議用 Lighthouse 工具跑一下，它會幫你檢查 PWA 的設定是否完整。
- 把 PWA 當成原生 App： 心態要調整。不要一開始就想做出跟原生 App 100% 一樣的功能。接受它的限制，從核心功能開始「漸進式增強」（Progressive Enhancement），這才是 PWA 的精神所在。
總結來說，我自己是蠻看好 PWA 的發展啦。 雖然它有缺點，尤其是在 iOS 生態系下，但對於很多專案來說，它提供了一個更輕、更快、更符合成本效益的選擇。與其一開始就投入大筆資金開發兩個平台的原生 App，不如先用 PWA 試試水溫，等確定市場反應熱烈，再考慮把資源投入到原生 App 也不遲。
換你說說看： 如果你要開發一個新服務，你會優先選擇 PWA 還是原生 App？你最在意的點是開發成本、使用者體驗，還是上架商店的便利性？在下面留言分享你的想法吧！
