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

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

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

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

目錄目錄

[隱藏]

[ 編輯 ] Web應用程式的演進 [ 編輯 ] Web應用程式的演進

[ 編輯 ] 動態網頁 [ 編輯 ] 動態網頁

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

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

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

[ 編輯 ] Rich Internet Application [ 編輯 ] Rich Internet Application

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

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

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

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

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

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

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

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

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

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

[ 編輯 ] 小結 [ 編輯 ] 小結

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