首頁‎ > ‎電子期刊‎ > ‎2007年10月號‎ > ‎

Single Page Application - 下一代的Web應用程式(上)

在Web Service, Ajax, Web 2.0, REST等Web應用與技術話題熱潮,帶動許多第二代的Web開發技術成長之後,這些話題也漸漸地消退。不過許多人可能不曾發現,其實這些技術名詞,是在 慢慢地顯露一點:Web應用程式逐漸從Server Side轉移到Client Side,也就是瀏覽器身上。

本篇文章要從以往的Server Side Web應用程式,其開發方式與演進來介紹Single Page Application(SPA) 與現今所有Web技術。

我在Web 2.0過去,現在與未來介紹Ruby On Rails都有提到一些Web技術的演進,比較明顯的趨勢就是從靜態到動態頁面,而設計的方式也更程式化。而在Web2.0:過去,現在及未來«就是愛程式 也有讀者在前言提到,技術並不是將一個名詞安上去就好。我相當贊同這句話,因此也在這篇文章中希望來做個總整理,以技術及歷史來看看Web是怎樣成長的。

本篇文章也同步發佈於 http://kiwi.csie.chu.edu.tw/blog/archives/156


Web應用程式的演進

動態網頁

儘管Web並不是一個三言兩語能拿個版本號碼來解釋,但實際上Web技術確實有些明顯的分隔點。

最早期我們熟知的就是靜態網頁,這應該沒啥問題。儘管在2000前,php,asp就開始流行,坊間的書上也都稱之為動態網頁。而我在此提及的動態網頁程式,實際上卻是從php4釋出的那一年開始。這邊要讓大家瞭解的分界點,其實是php4開始被許多商業公司所採用,而軟體的形式也更為套裝化,而不再像之前大家認定的「動態」網頁僅僅只是拿來完成一些簡單的區塊來與一般的靜態網頁整合。

在2004年的時候,Web Framework的產生,創造了Web應用程式另一個新的高峰。而在這個時候也開始有一些Rich Web Client概念的雛形了。我將Ruby On Rails定為一個分界點是因為,他顛覆了傳統動態網頁還在使用設計方式,而改用MVC。但要注意的是Ruby On Rails儘管整合了Ajax與進階Javascript函式庫,但還是沒有改變回傳完整或部分HTML的方式,意思便是HTML的產生始終在 Server Side。

Rich Internet Application

一直到現在,有相當多的Web應用程式,都還是維持使用URL來切換各種功能與畫面。而這些以「頁面」為主的程式,並不太需要控制DOM,就不常遇 到跨瀏覽器問題。然而自從Firefox逐漸也在市場佔有一席之地,Javascript的應用普及之後,跨瀏覽器問題也接著發生。為了避開各種不同的瀏 覽器所帶來的問題,各大企業都獨力發展自己可以嵌入在瀏覽器的應用程式。早期如Java Applet及微軟的的Active X,算是Rich Internet Application(RIA)的開始,但效能方面還是差強人意。

直到2004年的時候,RIA出現了兩種不同的實做方法:一種是承襲以往需要安裝額外Runtime或是在特定瀏覽器才能執行的方式,稱做 Sandbox;另一種是只採用CSS,HTML,並以Javascript控制HTML DOM的Dynamic HTML方式,優點就是只需要瀏覽器就可以執行。而後者也延伸出利用Offline Database或是Ajax+Web Service來傳送與儲存程式資料,並可以儲存成一個獨立頁面的Web應用程式,稱做Single Page Application(SPA)。SPA最典型的例子,就是Gmail。Google盡力克服了跨瀏覽器的問題,將Javascript發揮的淋漓盡致,讓大家驚嘆光靠純粹的Web技術竟能做到如此程度。

而我將2005定為Sandbox RIA真正開始的年代,也是因為Adobe併購Macromedia,而有了較完整的開發環境與資源,並不是以往單純地嵌入Flash。這個契機也促使微 軟改變策略,比起效能較差的Asp.Net,而拿Sliverlight作為Web下一代主力軍。

RIA或SPA都是學習歷程長,語言多又複雜的Web應用程式技術,也因此發展速度相當緩慢,但不可小看的是這些優點:

  • 相較以往在Server上產生HTML並回傳至瀏覽器,任何畫面皆利用瀏覽器本身或附加的功能來產生。形同於借用了Client Side CPU的運算資源,減少Server成本。使用者感受到的互動性與回應速度皆有大幅的提升。
  • 由於Server並不是回傳複雜龐大的HTML,而是純粹傳輸資料,使用的頻寬也相對變小。
  • Server Side除了使用傳統XML Web Service,更可以採用REST,讓Client的應用程式可以更快速掌握資料的新增修改刪除(CRUD)。
  • 能夠快速Mashup其他的Web應用程式資源,又能擁有高速的執行效能。

下表列出了Web技術的演進,要注意到後三種技術集合,其時間是並行的:

  靜態網頁 動態網頁程式 Web應用程式 Rich Internet Application with Sandbox Single Page Application
時期 2000以前 2000(php4釋出)~2004 2004(Ruby On Rails釋出)以後 2005(macromedia被adobe併購)以後 2004(Gmail釋出beta)以後
表現層 CSS CSS,HTML,Javascript CSS,HTML,Javascript Flash, Sliverlight CSS,HTML(DOM)
邏輯層 Javascript Template或自行撰寫 Web Framework Action Script, C# Javascript或是撰寫Web Service的語言
資料層 HTML Database(SQL) Database(ORM) Database(ORM) Offline Database, Web Service
開發方式 網頁編輯程式 整合HTML及Server Side語言的編輯器 整合Web Framework的IDE 整合Sandbox的IDE 整合Server Side與Client Side語言的IDE
運算資源 所有資料直接透過Web Server送出,除了硬碟讀取,幾乎不需要額外的運算 因為使用了Server Side語言來Render表現層,運算多半會消耗在Server 因為使用了Server Side語言來Render表現層,運算多半會消耗在Server 運算資源平均被分散在Server及Client,但Client需要Sandbox去執行,所以會消耗更多CPU資源 運算資源平均被分散在Server及Client
資料格式 傳送完整的HTML 傳送完整的HTML 傳送部分或完整的HTML 只需第一次傳送HTML及內嵌程式(Flash或Sliverlight),其餘傳送XML 只需第一次傳送HTML及Javascript,其餘可傳送XML或JSON
優點 簡單易學 學習同一種Server Side語言,搭配簡單的HTML,CSS,JS觀念便能夠有成果 整合Ajax或進階Javascript函式庫,REST及MVC。使得設計概念更為物件導向化 使用者介面反應快速,變化多且美觀。兼顧視窗程式的反應速度,且能部分相容傳統HTML應用。 完全相容傳統HTML應用,及任何可能的Web應用程式Mashup。可以採用不同的傳輸方式,併和REST及瀏覽器快取來節省頻寬,使得整體反應相當快速。
缺點 無法讓使用者儲存任何應用程式資料,任何資料必須藉由人工設計 對於龐大的應用程式,便得花上大量的Server成本。程式反應速度受限於伺服器負載,需要叢集架構來彌補。 設計方式更為簡單快速,但相對於傳統的動態網頁程式付出更大的Server成本。 除了CSS,HTML,JS以外還需學習一兩種不同的語言才能進行開發。RIA通常程式資料較大,在開始使用前必須等候一段下載時間。 除了CSS,HTML,JS以外還需學習一種撰寫Web Service的語言。需要相當熟悉DOM及CSS,也需考慮瀏覽器的差異,開發起來相對地困難許多。

表現層的演進可以得知,不管是RIA利用sandbox或者是SPA利用DHTML作為表現層,相較起來傳統以文字HTML拼湊出畫面的作法已經無法符合使用者的需求。更動態,更彈性的作法才能讓使用者獲得操作感。

而在邏輯層上,演進到了SPA則是變得較為複雜。如果是使用Web Service作為Server Side,除了必須撰寫該語言外,也還是得撰寫Javascript來控制畫面的呈現。而這也影響到開發方式,以往的編輯器多半著重一種主要的語言上,但 現在的Web IDE多半都可以完整的處理所有瀏覽器的語言,及多種Server Side語言。例如Aptana IDE就是最好的例子。

資料層的演進就比較簡單,直到RIA的時期,還是相當依賴傳統的Database。但SPA的時期,就可以採用Offline Database,這裡指的就是Google Gears。但如果要使用傳統的Online Database,全部都尚未有Javascript的Client,就必須透過Web Service來轉換資料。而在SQL到ORM的演進上,雖然使用物件導向的作法減緩執行速度,但相對降低開發難度,帶來更大的價值。

小結

本篇說明了Web技術的歷史,來帶出現今的Web技術。下一篇要介紹的是Single Page Application與它在Ruby On Rails上的應用。

Comments