Native 和 PWA：選擇，而不是挑戰者！

很難確切地說出“原生”和“網絡”之間的裂痕是從哪裡真正開始的。 我覺得這是自 Flash 早期以來一直在表面下攪動的事情之一，只是隨著移動平台的興起最近才爆發。 無論如何，開發人員已經克服了這個“巨大的鴻溝”，互相辱罵，試圖支持自己的立場。

我對那場戰鬥沒有興趣。 當然，我是一個“網絡人”，但這並不意味著我看不到原生開發的吸引力； 我也是一名軟件開發人員。 不過，最重要的是，我是一個實用主義者。 我意識到每個項目都是不同的，我們對每個項目的方法都應該根據項目的需求和目標量身定制。

隨著漸進式 Web 應用程序 (PWA) 蠶食原生開發的地盤，我認為現在可能是退後一步並評估這兩種構建產品的方法的好時機。 我希望我們都能夠清楚地看到每種方法的優勢，以期找到最適合我們創造的產品的能力。

速射比較

幾乎從一開始，基於 Web 的體驗就與從桌面軟件（最初的“原生應用程序”）到交互式 CD-ROM 到 Flash 以及最近的移動應用程序的所有內容進行了比較。 儘管多次被宣布死亡，但網絡仍然存在。 在許多情況下，它甚至比它所謂的殺手（RIP Flash）壽命更長。

網絡在這方面的主要優勢之一是它的適應性。 它幾乎可以去任何有互聯網連接的地方，並不斷獲得新的功能。 所有的編程語言都在發展，所以這並不出人意料，但隨著時間的推移，網絡不斷擴大的邊界繼續蠶食傳統軟件的地盤。

然而，網絡歷史上出現不足的一個領域是性能領域。 已安裝的軟件能夠以網絡無法做到的方式連接到底層操作系統。 它們是用宿主的通用語言編寫的，可以直接訪問硬件或我們常說的“更接近金屬”。 Web 幾乎總是在其之上運行一個或多個抽象層，在性能方面很難與之競爭。 雖然性能差距隨著時間的推移而縮小，但本機代碼可能會繼續比 Web 代碼運行得更快，至少在 Web 能夠直接從硬件引腳解釋信號之前。

與性能優勢齊頭並進，原生開發可以更多（和更早地）訪問設備功能，例如 NFC、藍牙、接近和環境光傳感器等。 網絡也在穩步獲得對這些功能的訪問，但它總是落後於原生，因為在網絡可以利用它們之前需要開發原生 API，並且跨瀏覽器的標準化需要時間。

此外，本機代碼可以與地址簿和日曆等操作系統級功能掛鉤。 推送通知是另一個重要功能，但 Service Worker 現在也使 Web 能夠利用該功能。 最近網絡上的支付處理也得到了類似的改進。 也許地址簿和日曆訪問最終也會出現在網絡上。

暫時回到 Service Worker，這個最近添加到 Web 開發人員工具箱的功能還有許多其他技巧。 首先，它提供了一個比 Web 之前使用 AppCache 更強大的緩存系統。 您可以使用 Service Worker 來管理離線請求、緩存特定資源、在用戶甚至沒有打開站點時與遠程服務器同步數據等等。 可能比任何其他單一技術更重要的是，Service Workers 使 Web 能夠提供更像應用程序的體驗。

Service Worker 是 PWA 的三個技術關鍵之一。 另一個是 Web App Manifest。 雖然聽起來有點無聊，但 Web App Manifest 實際上是一個非常強大的工具，它使網站能夠將自己宣傳為一個應用程序。 這種相對簡單的 JSON 文件格式提供了關於它所描述的網站的大量信息，並使支持 PWA 的瀏覽器和操作系統能夠像安裝本機軟件一樣安裝該網站。

一些應用商店甚至開始索引 PWA，使用它們的 Manifest 來填充它們的關聯條目。 從用戶的角度來看，應用商店中的 PWA 與它們周圍的原生應用沒有任何不同。 它們是可安裝的、不可安裝的，甚至可以將它們的設置暴露給底層操作系統的應用程序管理工具。 還值得注意的是，PWA 實際上並不需要用戶顯式安裝它們才能使用它們，因為它們存在​​於網絡上。

同時在網絡上和網絡上也意味著 PWA 始終是最新的。 用戶無需主動下載任何新內容即可訪問新功能。 即使確實推出了新的內容和功能，用戶也極不可能像大多數原生應用程序那樣需要重新下載整個 PWA。 如果有的話，他們可能會得到一些新的資產和一些新的 HTML，而且它會立即發生，不需要應用商店。 當然，您仍然可以使用應用商店提供的發現和分發選項，所以它確實是兩全其美的選擇。

在應用商店中，PWA 在發現、分發和貨幣化方面與原生應用處於同等地位。 事實上，它甚至可以使網絡超越原生網絡，因為 PWA 也可以通過搜索引擎發現，並且比應用程序具有無限的共享性，因為它們存在​​於 URL 中。 如果構建良好，PWA 還可以跨瀏覽器、平台和設備進行互操作。 PWA 甚至可以在不支持 Service Worker 等功能的瀏覽器中工作，因為 PWA 功能是漸進式增強。

Web 還提供了非常成熟的可訪問性支持，從而相對容易地確保您的項目可供最廣泛的用戶使用。 複雜的界面在編程方面確實需要更多的努力，但語義 HTML 提供的可訪問性優勢可以從容地處理基線可訪問性——尤其是在涉及大量文本、信息或簡單的基於表單的產品時。 相比之下，您幾乎總是需要了解可訪問性 API 並將其合併到您的本機代碼中。

關於開發的話題，我認為在開發體驗方面沒有明顯的贏家。 每種語言都有它的粉絲，開發者工具也是如此。 你喜歡你喜歡的東西，並且你傾向於使用你所知道和熱衷的工具和語言來提高效率。 Web 和本地開發都沒有任何明顯的優勢。

然而，本機開發的亮點在於確保使用其 SDK（軟件開發工具包）構建的 UI 質量始終如一。 大多數原生 SDK 提供用於測試性能、設計、功能等的工具。 它們還包括樣板代碼、設計系統和其他有助於提高本地軟件產品整體標準的工具。 當然，也有類似的 Web 工具，但它們分散在 Web 中，並不是在人們用來構建網站的所有不同開發環境中都通用。 沒有一個實體可以定義高質量的 Web 體驗並提供構建它們的工具（儘管許多人已經嘗試過）。

在為產品開發人員配備人員時，僱用知道如何為網絡構建的人肯定更容易。 在我打字時，編程語言索引目前將 JavaScript 列為最流行的語言，Java 緊隨其後。 C# 排名第 5，HTML 排名第 7，CSS 排名第 9，Swift 排名第 15。 該索引交叉引用了 Stack Overflow 標記，並在 GitHub 上的公共存儲庫中更改了行，因此應該對它持保留態度，但它提供了一個非常明確的指示，表明許多人都知道（並使用）Web 技術。 另一方面，尋找和僱用有才華的本地開發人員通常具有挑戰性，因為他們人數較少且需求量很大。

人才稀缺意味著您最終可能會為本地開發支付更多費用。 每個項目顯然都不同，並且具有不同的功能和要求，但將平均開發成本作為比較可以說明問題。 Comentum 建議構建一個中等大小的網絡應用程序的成本在 10,000 美元到 150,000 美元之間。 在原生端，Appster 估計中等規模的移動應用項目的構建成本在 110,000 美元到 305,000 美元之間。 可以肯定的是，原生項目的開發成本可能是 Web 項目的兩倍。 這是每個平台。 原生應用程序通常也需要更長的時間來開發。

值得注意的是，可以選擇使用 Web 技術構建本機軟件，而無需構建 PWA。 React Native、PhoneGap、Ionic 和 Appcelerator Titanium 等框架使您能夠從 HTML、CSS 和 JavaScript 生成本機代碼。 與僱用本地開發人員團隊相比，使用其中一種工具可以降低您的人員配備和開發成本，但在訪問設備功能方面，您的項目將僅限於框架已實現的那些。 相應地計劃。

開發應用程序後，您還必須考慮所述應用程序的持續維護成本。 在回應 Clutch 進行的一項調查時，Dom & Tom 建議第一年將產品初始價格的 50% 預算，第二年預算 25%，之後每年預算在 15-25% 之間。

一旦您對 Web 和原生開發的比較和對比有了相當的了解，您就可以開始評估哪些優勢和劣勢與您的項目相關。 您可能必須做出一些權衡，這是意料之中的。 沒有一種萬能的解決方案。 如果有，它不會適合任何人。

讓我們通過幾個假設的項目來更清楚地了解原生開發和 PWA 開發之間的區別。

項目 #1：現有的原生應用程序

假設您已經完成了構建本機應用程序的過程。 如果一切順利，就沒有理由改變方向。 不要放棄所有現有工作來切換到 PWA，除非你有充分的理由這樣做。 我只能真正想到一種可能需要考慮切換到 PWA 的場景：將對新操作系統的支持納入其中。 即便如此，只有當您的應用程序的需求可以僅通過 Web 來滿足時，它才真正有意義。

如果您正在為產品添加對新平台的支持，則它為評估項目的需求和目標以及滿足這些需求的成本創造了絕佳的機會。 如果網絡不能勝任這項任務，請堅持使用本機。 但是，如果是這樣，請停下來考慮一下：使用 PWA 添加對新平台的支持將使您能夠支持其他平台（包括 Web），甚至可以讓您在 PWA 有後替換現有的本機應用程序進行了徹底的測試。

如果用 PWA 替換現有的原生應用程序對您來說似乎是不可想像的，請考慮一下：星巴克和 Twitter 已經在探索這個想法。

如果有特定原因需要保持應用程序原生，仍然值得考慮將某些應用程序功能“外包”到網絡。 幾年前，我正在為一家大型金融服務公司做一個項目，他們選擇將其本地應用程序的登錄流程轉移到網絡上，以使他們能夠比典型的應用程序商店更快地推出安全功能審批流程使他們能夠實現。 也許您的項目有類似的需求，網絡可以讓您的原生應用程序滿足這些需求。

項目 #2：現有的跨平台應用程序

如果您有一個現有的跨平台應用程序，您可能會為該應用程序的持續開發和維護花費大量資金。 您還可能會看到一些不同的應用內功能，因為每個原生平台往往都有自己的開發時間表。 例如，零售商 Target 的應用程序目前允許用戶在 iOS 上管理購物清單，但 Android 版本沒有該功能。 在許多方面，它類似於我們有時在網站的“桌面”和“移動”版本之間看到的差異。

如果 Web 已經是你跨平台組合的一部分，那麼它提供了一個很好的機會，可以加倍投資，並考慮用 PWA 替換你的原生應用程序。 聲納和 Lighthouse 等工具可以讓您深入了解現有站點對 PWA 化的準備情況，它們還可以告訴您需要做什麼。 從那裡開始，將您的網站變成 PWA 相對簡單。 甚至還有一些免費工具可以幫助您在幾分鐘內將您的網站升級為 PWA。 但是，如果不是這樣，那麼除非平台之間的功能差異變得非常嚴重，或者您正在考慮將另一個原生平台（或網絡）添加到組合中，否則實際上沒有太大的動力去採取這一舉措。

項目#3：一種新的跨平台產品

如果您要啟動一個針對多個平台的新項目，那麼絕對應該將其作為 PWA 在一個地方創建和維護。 根據您的預算和員工，可能會最大限度地擴展您的預算。 也就是說，如果您的產品需要直接連接到硬件或底層操作系統，您可能仍需要採用原生方式。 但在你走這條路之前，列出你的所有要求，然後驗證網絡可以做什麼（以及不能做什麼）。 一定要檢查多個瀏覽器的支持。

項目#4：一個新的超聚焦產品

如果您正在構建一個新產品，並且該產品的整個目的的一部分是它與特定平台的深度連接，那麼一定要為該平台構建。 例如，如果您的產品依賴於 Apple 的 Messages 平台或與 HomeKit 的集成，請務必使用 Swift 為 iOS 和/或 macOS 構建。 如果您的產品通過小部件最能滿足用戶需求，或者您正在構建自定義啟動器，那麼您最好構建 Android，並且您需要使用 Java。

然而，並非所有本土特色都是圍牆花園。 雖然 Amazon 的 Alexa、Apple 的 Siri 和 Google Assistant 都需要本地代碼（或 JSON API）來與您的應用程序集成，但有趣的是，Microsoft 的 Cortana 將僅使用從您的 HTML head鏈接的 XML 文件為您的 PWA 啟用語音。 也許其他人會跟隨他們的腳步。

PWA 還是原生？ 這是你的選擇

網絡和原生都有很多東西可以提供。 如果您要問我哪個更好，我會簡單地回答“這取決於”，因為確實如此。 我不是在迴避或不置可否； 確定哪個最適合您的項目完全取決於您項目的具體需求。 它需要考慮您正在構建的內容、負責構建它的現有團隊的組成或您需要雇用的團隊，以及您必須使用的預算。 在許多情況下，網絡可能會提供您完成項目目標所需的一切，但總有例外。 如果您想探索網絡提供的可能性，我在本文末尾提供了一些資源。

在權衡不同的軟件開發方法（或不同的框架、庫、語言、設計系統等）時，您可以做的最重要的事情是考慮與手頭項目相關的選項。 做你的研究並權衡你的選擇。 並且不要讓自己被聰明的營銷、性感的演示或狂熱的粉絲所左右。 包括這個。

PWA 相關資源

• PWA 構建器
  一個包含有用建議和食譜的 3 步網站到 PWA 創建工具。 它還使您能夠將您的 PWA 轉變為適用於 Windows、Android 和 iOS 的可安裝本機應用程序。
• 漸進式 Web 應用程序的漸進式路線圖
  Jason Grigsby 講述了他的團隊如何在幾個月的時間裡開始將 PWA 的各個方面整合到他們的網站中，很好地展示瞭如何一次添加一些不同的功能。
• 是的，那個 Web 項目應該是 PWA
  PWA 的 UX 機會（和風險）概述，由您真實撰寫。
• MDN 上的漸進式 Web 應用
  您需要了解的有關高質量 PWA 特徵的所有技術信息的中心。
• 網絡今天能做什麼
  查看您的設備、操作系統和瀏覽器支持的 API。 你的發現可能會讓你大吃一驚。
• 我可以用嗎
  每個主要瀏覽器中可用的 API 和功能以及相對於人們實際使用的瀏覽器的支持如何衡量的權威數據庫。 它還可以讓您及時了解某些功能的向後兼容性。