用過Facebook在iOS還有Android上App的朋友，應當都知道，過去，Facebook App是使用HTML5的技術來做為使用者介面的主要基礎，但是使用過之前Facebook App的人應該都有諸多的不滿意，像是介面的操作反應，以及執行上的速度等等，其實都不盡理想。
所以在今年八月左右，Facebook重新推出了iOS版本的App，而且做了重大的技術決定，也就是捨棄原有以HTML5為基礎的架構，改用原生 （native）的方式來重新打造。當這個重新以原生方式設計而成的App上架之後，立即獲得廣大的迴響，使用者紛紛對示其運行速度及流暢，感到驚艷。
在此之後，Facebook的創辦人Mark Zuckerberg 在今年九月出席《TechCrunch》Disrupt 大會時，也表示舊式以HTML5為基礎的Facebook App因為反應慢而且穩定度不足，他甚至說出了「以HTML5撰寫而成的Facebook App，是Facebook成立以來最大的策略錯誤」。使得他們決定重新開發原生版本的App。當然，新版本的Facebook App大獲使用者青睞。不過，這是否說明了，對於在選擇使用者介面基礎技術的戰爭中，HTML5明顯落於下風呢？
對於HTML5的擁獲者而言，自然不能如此輕易的吞忍下去。
有一家位在美國加州的行動App開發商——Sencha，對Facebook App的功能做了研究，並且選出了其中他們認為最難的部份，利用他們工作之餘的時間，以HTML5的方式予以撰寫，並且取名為「Fastbook」，挑戰意味相當濃厚。
而且，他們還錄製了一段影片來說明Fastbook運行速度還勝過Facebook官方的App。這結果自然又引起眾多的討論——關於以HTML5為使用者介面基礎技術，以及用原生方式打造，究竟二者孰優孰劣呢？
HTML/JavaScript成為伺服器端應用程式開發的要角
在Web成為主流的應用程式平臺之後，以HTML/JavaScript為基礎技術的應用程式架構，幾乎就支配、主宰了伺服器端的應用程式開發。談到了伺服器上的應用程式開發，幾乎快要和Web應用程式畫上了等號。
除了伺服器端之外，也有不少應用程式將腦筋動到了客戶端的使用者介面上，也就是說，利用這種以HTML/JavaScript為基礎技術的應用程式架構，來做為客戶端使用者介面的主軸。
例如，你可以開發一個Windows上的客戶端應用程式，以微軟的MFC應用程式框架寫成，但是，這個MFC應用程式只負責做為Windows上應用程式 的起點，本身並不提供真正使用者介面的功能。而這個MFC應用程式骨子裡其實是內嵌一個瀏覽器的元件，在Windows上通常就是一個IE瀏覽器中的 ActiveX元件。這個元件擁有完整的瀏覽器能力，能處理所有的HTML呈現，以及JavaScript程式的執行。
對於此元件中要載入的HTML頁面內容，你可以選擇將它導到遠端的伺服器上，也就是說，即使是在客戶端應用程式所呈現的使用者介面，事實上，其內容的展 現、資料的取用，都可以在伺服器上完成。只不過，在客戶端的瀏覽器元件裡，應用程式可以透過諸如Ajax之類的技術，和伺服器端互動，並且透過 JavaScript，來動態呈現各種介面上的效果。
這麼一來，即使是客戶端的應用程式，其實也是套用了伺服器端應用程式的技術，甚至骨子裡本來就是伺服器端的應用程式。
除了IE這樣的瀏覽器元件之外，像是WebKit，有不少人運用在非Windows的平臺。而在Mac上，開發應用程式時，也有現成的瀏覽器元件可用。
網頁應用程式開發的先天限制
在說明這種方式的優點之前，我們先來看看這樣子做有什麼缺點。
首先，使用者介面上的元素會受限於HTML所能提供的，也就是說，在原生的平臺上，不論是Windows或是Mac OSX，不屬於HTML所能提供的使用者介面元件，在你的應用程式裡都無法使用。
第二個問題是，由於客戶端上能執行應用程式部份是以JavaScript為主（應用程式的另一部份是在伺服器端），所以，一些存取本地端資源的動作，例如 開啟本地端的檔案並進行讀寫等等，都是沒有辦法倚靠JavaScript程式來做到的。這當然是基於安全性的考量，瀏覽器是不會允許自遠端載入的程式存取 本地端的資源，否則，使用者本機上的檔案被遠端的程式任意存取，肯定是個大問題。
除此之外，有很多原生應用程式上可以做的動作，是Web應用程式做不到的，這些通常是透過一些原生作業系統上的API，以及原生的程式碼才能做到的。例 如，你想開發的是個影音多媒體串流的應用程式，而播放影音串流的動作，卻是單純的HTML或JavaScript程式所無法提供的。
在本文中最後要提的一個問題是，應用程式的效能會取決於瀏覽器元件對於HTML呈現，以及JavaScript程式運行效能的最佳化結果。也就是說，倘若 所使用的瀏覽器元件先天上在呈現及運行程式上，就有效能不夠快的問題，那麼，想要從應用程式來改善，其難度就會很高。不過，運行效能的問題，在個人電腦上 通常問題不大，在行動裝置上受限於CPU的計算力，這個問題才會突顯出來，待我們談到行動裝置上的App時，再回過頭來細談。
克服限制的代價——失去跨平臺特性
對於採用這種方式又想要取得原生支援，或是打破對存取本地端資源限制的應用程式來說，有一個開後門的方式，使是採取各瀏覽器下「外掛」元件的方式。在IE 的瀏覽器上，你可以撰寫自有的ActiveX元件，它可以是用Windows原生平臺上可運行的程式語言，例如C/C++寫成，也可以像原生程式一樣的進 行任何動作，就像執行原生的程式。另一方面，JavaScript程式也可以和ActiveX元件溝通，不論是讓JavaScript程式呼叫 AcitveX的函式，或是ActiveX產生JavaScript的事件，讓JavaScript程式收到來自ActiveX元件的通知，都可以做到。
這麼一來，倘若你的應用程式中存在非要不可的原生功能時，就可以利用這種方式。除了IE底下的ActiveX元件之外，還有像Safari的 Plugin，或是NSAPI（Netscape Server Application Programming Interface）的Plugin等等。
不過，一旦運用了此類的原生支援，你的應用程式就會失去了跨平臺的特性，也就是說，原先你採用HTML/JavaScript為基礎的方式，其目的之一， 可能是想得到跨平臺的好處（這是優點之一，容後再述），但是，一旦動用了原生的支援，這個好處就會消失一些，最起碼，動用原生的部份，必須隨著不同的平臺 而分別提供。
也就是說，如果你想要讓你的應用程式兼容於Windows上和Mac上，那麼，在Windows上你必須撰寫一個ActiveX元件來提供原生的部份，而 在Mac上，則用類似的Plugin技術，撰寫等價的部份。這當然不是說，可攜性完全消失，但是，仍有一部份的程式碼，是有平臺相依性的。和單純的 HTML/JavaScript的應用程式相比，跨平臺的能力顯然失色不少。
不過，即使是存在這些限制和麻煩，還是有愈來愈多的開發者採用這種方式來開發，當然，Facebook之前以HTML5為基礎的方式，也算是這種模式。這當然是因為這種方式有不少的優點，而這，就讓我們留待下回再繼續介紹了。
