以Web為中心的客戶端程式開發

去年，Facebook在行動裝置上的App棄用HTML5技術，並且宣稱使用該技術是公司創立以來最大的策略錯誤。身為指標性的網路應用平臺及開發商，Facebook的決策和論點當然引起了廣泛的討論。究竟，以HTML相關技術為基礎的客戶端應用程式，和原生的技術相比起來各有什麼優劣、應用時又需考量那些因素呢？本回讓我們繼續探討下去。

為前端應用程式賦予可攜性
即使在一開始，以HTML為使用者介面基礎的模式，是應用在使用者以瀏覽器連上Web伺服器的架構下，但是，因為具有不少好處，所以，漸漸也有不少人將這種方式應用在客戶端（client）應用程式。

傳統上，客戶端應用程式都是以原生（native）的方式開發而成，使用作業系統或平臺上原生的API、原生的使用者介面元件，但是在應用以HTML為基礎的技術之後，原生的部份主要只剩下啟動的應用程式本身，絕大多數使用者所接觸到的介面部份，皆是以HTML為基礎的技術（當然包括了JavaScript）所完成的。

為什麼有愈來愈多的開發者對這種模式趨之若鶩呢？我想最主要的因素之一，便是這種模式在應用程式的前端提供了極佳的可攜性。

很多年前，就有不少人預言，作業系統做為應用程式運行平臺的特性，將會愈來愈不明顯，接下來只會有一種主要的平臺，那就是Web。這樣的預言到了今天來看，幾乎可以論斷它的實現。即使不同的作業系統依然存在（但Windows平臺也不若以往那般強勢），但是，人們對於作業系統的倚賴卻愈來愈低，原因便是人們早就習慣在瀏覽器上連往各種不同的網路服務、使用各種應用程式。

以往，瀏覽器尚有大大小小的相容性、標準化的問題，而到了今天，這些問題已經消除了許多。以Web做為一個共通的平臺，在各種瀏覽器上呈現、運行，難度也降低很多。無論你使用什麼平臺，從手機、平板、到個人電腦，都有瀏覽器。即使仍然有若干細節性的問題，但我們應該可以說瀏覽器是目前最具可攜性的平臺。

當你採用以HTML技術為基礎的模式來開發客戶端的應用程式時，即使提供啟動應用程式本身還是原生的，但主要的應用程式仍然是在原生應用程式所內嵌的瀏覽器之中所運行。對於不同的作業系統平臺，你只需要分別為它們做出原生的啟動程式即可。

所以說，在Windows上，你可以用MFC做出一個啟動程式內嵌瀏覽器的ActiveX控制元件；在Mac OSX上，你也可以用Cocoa也做個啟動程式，接著內嵌WebView。無論是那一種瀏覽器元件，都連上相同的Web伺服器端，都應用相同的HTML技術、運行相同的JavaScript程式。尤其在特定作業系統的影響力愈來愈低的今天，客戶端應用程式的可攜性愈形重要，這種模式所提供的可攜性也愈來愈關鍵。

應用程式更容易修改與部署

除了提供更高的可攜性之外，許多軟體開發者會考慮使用以HTML為基礎的技術於客戶端應用程式，是因為便於彈性的修改，以及動態的部署。

如果你開發過原生應用程式，就會知道，在你的原生應用程式部署出去之後，一旦日後因為像是臭蟲的修正、功能的擴展等種種原因而改版，除了對原生應用程式做必要的修改之外，你還會需要面臨重新部署到客戶端的問題。

所以，很多開發者必須在他們的應用程式中加上自動更新的機制，無論是使用者手動檢查、或是應用程式自動檢查，都要能夠檢查是否有新的版本，並且下載新版本，接著予以更新。這無疑是個複雜的機制，而且你不見得能夠確定客戶端應用程式的確無誤的完成版本升級的動作。當你的伺服器端已經改版到新的邏輯，但客戶端應用程式卻沒有時，就有可能引發一些不可預期的問題。 客戶端應用程式也有可能好長一段時間都沒有改版了，更新程式還得檢查其版本和最新版本間的組態差異，才能正確將其更新。總之，這並不是一個容易處理的議題。

在過去產品更新週期長的時候，這個問題或許影響不那麼大。但是，自從Web來到2.0的世代之後，產品改版的週期更加頻繁。就像Facebook，你或許隨時都可能發現到它又做了程度不同的功能修改。在這種情況下，客戶端應用程式需要支援更頻繁的更新模式，若是沒有處理好，就會變得相當的惱人。舉例來說，相信，許多人都不太適應iTunes的頻繁改版，以及它的更新方式吧。

不過，當你使用HTML來做為客戶端應用程式的基礎時，應用程式可以說是隨時從伺服器上取得，隨時都是最新的版本。在這種架構下，資料是在伺服器上取得計算、產生HTML網頁的邏輯則是在伺服器上產生，再搭配瀏覽器上執行的JavaScript程式，提供一些動態生成的效果及互動方式。即使應用程式需要改版，也只需要部署到伺服器端即可。除非客戶端的啟動程式需要修改，否則，只要在伺服器端完成部署，客戶端即可隨時使用到最新版本的應用程式，不需要針對客戶端的應用程式做任何的改版。

這麼一來，對於想要頻繁對應用程式改版（無論是問題的修正或是新功能的擴增）的開發者而言，此種模式便顯得十分方便。

除了個人電腦上的客戶端應用程式，可以藉此解決頻繁改版的部署問題之外，對於像iOS平臺上，也能提供一些額外的便利性。

因為在iOS App的上架規範下，每當你的應用程式要改版時，就得進行重新送審的程序，而重新送審的程序通常耗時頗長。這對於想要時常修改、調整App功能，尤其是使用者介面部份的開發者而言，無疑會構成一大障礙。

不過，一旦採用以HTML為基礎的模式來開發，送審的部份只是啟動程式，日後有功能的修改，只要在伺服器端修改，客戶端所看到的、所使用到的，都會是最新的版本。而且，這樣的修改不需要任何新版的客戶端應用程式，而這也意味著並不需要重新將App送審、重新再等待一段冗長的流程。

以Web為中心，不需投入各種原生平臺的開發
除了部署方便之外，當你採用HTML為基礎的模式來開發客戶端應用程式時，你所需要的開發技巧還是和Web應用程式設計一樣，並不需要隨著不同的原生平臺，而使用該平臺下的語言、應用程式框架、SDK及API等，只需要專注在相同的技術領域即可。

對於開發團隊而言，也不需要招募太多技能組合的程式設計者，只需要以Web應用程式技術領域為主即可。不論是技術、平臺、人、還有思維，一切依舊以Web為中心。在現今這種以Web程式設計為主流的開發世代來說，這可以說是一大優勢。對於想要兼容網站使用者，以及特定客戶端應用程式使用者的網路服務來說，更是可以共用資源。

當Web應用程式開始流行在MVC的基本概念下，在前端大量倚賴JavaScript來動態呈現資料，同時運用Ajax方式至伺服器端取得資料時，不同的客戶端，無論是個人電腦瀏覽器、平板電腦瀏覽器、手機瀏覽器、或是平板、手機、個人電腦上的專用客戶端應用程式，都可以共用伺服器端上的所有服務，以及和客戶端溝通的協定，唯一需要隨著平臺而改變的，僅有在客戶端處理使用者介面的部份而已。

以Web為中心的開發概念，可以將對多種平臺的支援，都集中在單一的計算資源之下，這也是以HTML為基礎的模式的好處。

正因為以HTML為基礎的模式有這麼多好處，才會有這麼多的開發團隊決定採用，當然也包括Facebook，而後來Facebook竟然放棄這種模式！下回中，讓我們試著來將它和原生的應用程式再比較。