Single Page Application - 下一代的Web應用程式 Single Page Application - 下一代的Web應用程式
Single Page Application - 下一代的Web應用程式
在Web Service, Ajax, Web 2.0,REST等Web應用與技術話題熱潮，帶動許多第二代的Web開發技術成長之後，這些話題也漸漸地消退。不過許多人可能不曾發現，其實這些技術名詞，是在慢慢地顯露一點：Web應用程式逐漸從ServerSide轉移到Client Side，也就是瀏覽器身上。
本篇文章要從以往的Server Side Web應用程式，其開發方式與演進來介紹Single PageApplication
我在Web2.0過去，現在與未來及介紹Ruby OnRails都有提到一些Web技術的演進，比較明顯的趨勢就是從靜態到動態頁面，而設計的方式也更程式化。而在http://atedev.wordpress.com/2007/01/09/Web2.0：過去，現在及未來/也有讀者在前言提到，技術並不是將一個名詞安上去就好。我相當贊同這句話，因此也在這篇文章中希望來做個總整理，以技術及歷史來看看Web是怎樣成長的。
Web應用程式的演進
動態網頁
儘管Web並不是一個三言兩語能拿個版本號碼來解釋，但實際上Web技術確實有些明顯的分隔點。
最早期我們熟知的就是靜態網頁，這應該沒啥問題。儘管在2000前，php,asp就開始流行，坊間的書上也都稱之為動態網頁。而我在此提及的動態網頁程式，實際上卻是從php4釋出的那一年開始。這邊要讓大家瞭解的分界點，其實是php4開始被許多商業公司所採用，而軟體的形式也更為套裝化，而不再像之前大家認定的「動態」網頁僅僅只是拿來完成一些簡單的區塊來與一般的靜態網頁整合。
在2004年的時候，WebFramework的產生，創造了Web應用程式另一個新的高峰。而在這個時候也開始有一些Rich WebClient概念的雛形了。我將Ruby OnRails定為一個分界點是因為，他顛覆了傳統動態網頁還在使用設計方式，而改用MVC。但要注意的是Ruby OnRails儘管整合了Ajax與進階Javascript函式庫，但還是沒有改變回傳完整或部分HTML的方式，意思便是HTML的產生始終在ServerSide。
Rich Internet Application
一直到現在，有相當多的Web應用程式，都還是維持使用URL來切換各種功能與畫面。而這些以「頁面」為主的程式，並不太需要控制DOM，就不常遇到跨瀏覽器問題。然而自從Firefox逐漸也在市場佔有一席之地，Javascript的應用普及之後，跨瀏覽器問題也接著發生。為了避開各種不同的瀏覽器所帶來的問題，各大企業都獨力發展自己可以嵌入在瀏覽器的應用程式。早期如JavaApplet及微軟的的Active X，算是Rich InternetApplication(RIA)的開始，但效能方面還是差強人意。
直到2004年的時候，RIA出現了兩種不同的實做方法：一種是承襲以往需要安裝額外Runtime或是在特定瀏覽器才能執行的方式，稱做Sandbox；另一種是隻採用CSS,HTML，並以Javascript控制HTMLDOM的Dynamic HTML方式，優點就是隻需要瀏覽器就可以執行。而後者也延伸出利用OfflineDatabase或是Ajax+WebService來傳送與儲存程式資料，並可以儲存成一個獨立頁面的Web應用程式，稱做Single PageApplication(SPA)。SPA最典型的例子，就是Gmail。Google盡力克服了跨瀏覽器的問題，將Javascript發揮的淋漓盡致，讓大家驚歎光靠純粹的Web技術竟能做到如此程度。
而我將2005定為SandboxRIA真正開始的年代，也是因為Adobe併購Macromedia，而有了較完整的開發環境與資源，並不是以往單純地嵌入Flash。這個契機也促使微軟改變策略，比起效能較差的Asp.Net，而拿Sliverlight作為Web下一代主力軍。
RIA或SPA都是學習歷程長，語言多又複雜的Web應用程式技術，也因此發展速度相當緩慢，但不可小看的是這些優點：
· 相較以往在Server上產生HTML並回傳至瀏覽器，任何畫面皆利用瀏覽器本身或附加的功能來產生。形同於借用了Client SideCPU的運算資源，減少Server成本。使用者感受到的互動性與響應速度皆有大幅的提升。
· 由於Server並不是每次都回傳複雜龐大的HTML，而是利用XML或JSON傳輸資料的部分，使用的頻寬也相對變小。
· Server Side除了使用傳統XML WebService，更可以採用REST，讓Client的應用程式可以更快速掌握資料的新增修改刪除(CRUD)並簡化呼叫的服務URL。
· 能夠快速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以外還需學習一種撰寫WebService的語言。需要相當熟悉DOM及CSS，也需考慮瀏覽器的差異，開發起來相對地困難許多。 |
表現層的演進可以得知，不管是RIA利用sandbox或者是SPA利用DHTML作為表現層，相較起來傳統以文字HTML拼湊出畫面的作法已經無法符合使用者的需求。更動態，更彈性的作法才能讓使用者獲得操作感。
而在邏輯層上，演進到了SPA則是變得較為複雜。如果是使用Web Service作為ServerSide，除了必須撰寫該語言外，也還是得撰寫Javascript來控制畫面的呈現。而這也影響到開發方式，以往的編輯器多半著重一種主要的語言上，但現在的WebIDE多半都可以完整的處理所有瀏覽器的語言，及多種Server Side語言。例如Aptana IDE就是最好的例子。
資料層的演進就比較簡單，直到RIA的時期，還是相當依賴傳統的Database。但SPA的時期，就可以採用OfflineDatabase，這裡指的就是Google Gears。但如果要使用傳統的OnlineDatabase，全部都尚未有Javascript的Client，就必須透過WebService來轉換資料。而在SQL到ORM的演進上，雖然使用面向物件的作法減緩執行速度，但相對降低開發難度，帶來更大的價值。
Single Page Application
定義
請參考 http://www.answers.com/topic/single-page-application?cat=technology
Single Page Application是一種WebApplication，完全地在瀏覽器上執行。也就是說，標準的SPA程式是不需要網路聯機的。
像這些範例，你可以使用firebug來觀察聯機的動作。
· TiddlyWiki http://www.tiddlywiki.com/：這個wikieditor，除了整整一萬行的javascript以外，只有一個很簡單的起始頁。就算你拔了網路線，也只是不能夠儲存而已。但他要如何儲存編輯好的wiki內容呢？必須設定外部伺服器進行同步作業。
· Protopage http://www.protopage.com/：外型設計得很漂亮，操作感也很順暢。仔細觀察你也會發現在進行網路傳輸的時候都是傳遞JSON。
而畢竟沒有網路聯機的程式很難作為應用，所以我在SPA架構一節會提出兩種SPA程式的演進。
在此也必須提出一個概念，SPA並非只是一個「不切換頁面」或是「URL不變」的程式。而SPA所使用的觀念，就如同前言，已經是將瀏覽器當作client端了。
既然是client端，那勢必代表中間是必須傳輸資料，而並非HTML；也因此HTML的產生也會發生在client端，而並非傳統由server產生HTML再由瀏覽器載入。
所依賴的Web技術
Ajax為Asynchorous Javascript AndXML，早期Ajax被用作來傳輸單純的HTML或是XML，並且利用DOM的innerHTML屬性來更新部分HTML內容。如今Ajax在SPA中被當作重要的傳輸媒介(Transport)，無論模板資料到應用程式資料，都是利用Ajax在背景傳輸完後，再由JavascriptTemplate來產生HTML。
JSON為Javascript Simple ObjectNotation，在標準的Javascript語法中，以{ }及[]這兩個語法，可以宣告物件與陣列，並可以使用eval函式將他轉換為Javascript物件。例如object=eval_r(”({a:’b'})”)，此時object物件便有一個屬性”a”其值為”b”。在SPA中，JSON被運用來作為一種資料格式，藉此取代複雜的XML，以節省頻寬。而傳輸的JSON資料又可以快速還原為javascrip物件，又更節省程式執行的時間。
在SPA中，HTMLDOM是一個最重要的元素，尤其是DIV及SPAN等Container的操作更是。由於絕大多數的畫面都不進行任何換頁的動作，程式裡大部分都是在控制DOM及Container。而對於A(Anchor)而言，href裡的URL也沒有太大意義，多半都是在onclick裡寫javascript，或是用Javascript函式庫去bindonclick事件。由於直接呼叫瀏覽器提供的DOM函式庫功能，會遇到像IE一樣不符合W3C規格的問題。要選用一個合適的Javascript擴充函式庫，如Prototype.js或是jQuery，如此才不會有太多跨瀏覽器問題。
CSS在以往的Web應用程式中，多半都拿來當作畫面的修飾，佈景主題或是顏色特校。但在SPA中，必須要熟悉CSS的Dimentation(長寬控制)，Classification(顯示行為)，Positioning(定位)。在無法換頁的狀況下，只能靠著移動，隱藏，顯示這些方法來控制畫面的元素。如果要了解這些進階CSS的主題，都可以在w3school裡的教學找到。
Trimpath是Google為了SPA而開發出來的一個函式庫集合，也可以說是Rails的Javascript版。如果要撰寫上述第一種SPA，就必須利用到Trimpath的全部，而第二種只需要用到TrimpathJavascript Template即可。JavascriptTemplate(JST)如同PHP的Smarty一樣，是標準的模板技術，只是採用的語言是Javascript。為了撰寫SPA，必須要好好地運用JST。
快取的機制在SPA也相當的重要，為了達到讓使用者感受到程式的反應快速，就必須應用多方面的快取。
· ViewCache：SPA中的View就是指已經顯示出來的HTML，很多常用，而不需要經常改變的HTML，就可以將放在Container(DIV或SPAN)裡。不用的時候就隱藏，需要的時候就顯示。而另一種方式是可以用z-index將選單或是清單的Container放在最下層，而要回到這個清單的時候就將蓋在其上的container隱藏。
· Template Cache：一般來說JST的模板資料只要讀取一次就可以，又因為這些只是字串，可以直接就存在Hash裡。
· JavascriptCache：在我提出的SPA實做中，有一個特性是將各個JST的「行為」程式程式碼分開，就如同sap.net將aspx與cs檔分開的作法一樣。而如果採用這個作法，不需要重複讀取的javascript就必須要快取。
· DataCache：資料快取是最難的一部份，牽扯到了快取一致性的問題。而現在在javascript中並沒有對於XML或JSON的資料快取解決方案，未來如果能夠有這樣的函式庫，就能夠更提升整體的效率。
以上說明的都是Client Side所必須要使用到的技術，而ServerSide的技術多半與Service Design息息相關。
REST為Representational StateTransfer，他比較像是一種設計樣式(DesignPattern)，而不是Web技術。在以往Web應用程式的規劃中，URL並不完全具有意義，傳輸的內容型態多半是HTML，而HTTP的各種動作也並未完全利用。在SPA中，由於需要在不同時間傳輸各種資料，如HTML模板，JS模板，或是XML及JSON資料。此時REST的設計技巧就可以節省下很多重複的命名，而讓程式程式碼整體更有意義。支援REST設計樣式的Web Framework如Ruby OnRails，讓整體設計較為簡單。
SPA的架構
SPA就分類而言，算是RIA的一種，只是不採用任何的sandbox而已。典型的SPA是不需要任何的後端的WebService或是Offline Database，只需要一個htm檔或是一個網頁就能夠運作，如微軟的HyperTextApplication(HTA)就是，但還是缺乏完善的資料儲存能力。
第一種SPA程式，如同著名的GoogleReader離線版，具有一個離線資料庫與一個同步管理程式，在有網路聯機的時候，會將資料同步回線上的資料庫。這個最大的優點就是完全利用了Client的CPU資源，使用者雖然看見的是網頁，但卻是在使用在本機執行的獨立應用程式，因此速度是相當流暢。比起一般的動態網頁，這樣子的使用體驗更能夠顛覆一般人對於「網頁」的看法，而逐漸瞭解何謂Web應用程式。另一個例子是使用Trimpath函式庫撰寫成的NextAction，是一個多功能的ToDoList。
另一種就是較簡單的SPA，不具有離線瀏覽的能力，但是承襲了使用javascript的高效能。必須提及的是ServerSide並不是採用XML，而是可以快速轉換為Javascript物件的JSON，來當作Web Service。如此ServerSide的語言只需要具備能夠快速將物件serialize成JSON的能力即可。
Rails與SPA
這個小節所要說明的是相當技術性的部分，無法說明的太詳細，有興趣的讀者可以寫mail一起討論。為了簡化觀念，我使用SequenceDiagram來說明Rails要如何應用在SPA上：
· URLRequester是一個javascript函式，主要的工作就是以REST方式對一個URL進行不同Content-Type的Request，並且將回傳的資料產生HTML，並填到container裡顯示出來。
· HTTPRequest在這裡作為進行Ajax呼叫的傳輸媒介。
· RailsController表示伺服器端對應至特定URL的程式，在這裡也必須使用REST方式來響應。也因此如果要求content-type為HTML的時候就傳JST模板，要求JSON的時候就傳資料，要求javascript的時候就傳javascript檔案。
· RailsModel代表伺服器端的資料庫，在要求資料的時候，勢必定要連資料庫來取得資料的。而回傳的時候，就將ruby物件serialize成JSON。
1. Client呼叫URLRequester函式，例如http://servername/controller/action/id。
2. HTTPRequest送出一個要求，並指定Content-Type為HTML。
3. RailsController接到指定的URL，並執行controller#action。我將JST寫在rhtml裡面，JST基本上也是html，不過是模板的卷標換成{}而已。因為REST設計方式會因為指定的content-type回傳對應的型態，此時直接將內容的JST檔案傳回。
4. 在前面我有提及快取的重要性，所以這裡就快取住這個JST，下次要求同樣的內容就可以直接使用而不用重複傳輸。
5. 對於同一個URL，使用HTTPRequest送出要求，並指定Content-Type為JSON。
6. 因為REST的特性，這次會執行到content-type為JSON時的程式程式碼，接著就可以照一般方式使用RailsModel讀取資料庫。
7. Model傳回的Ruby物件，當然就要轉換成JSON回傳。而在ruby中相當簡單地便是呼叫to_json就可以轉換了。
8. 回傳的JSON，並和剛剛快取的JST，使用trimpath javascripttemplate函式庫產生成HTML，並更新至container裡。
9. 在這裡我採用行為javascript程式程式碼與範本分離的方式，所以還是以HTTPRequest再次傳送要求，並將Content-Type指定為Javascript。
10. 同樣地根據要求的content-type，會回傳javascript檔案。
11. 快取，並呼叫eval執行回傳的javascript。
12. 將container顯示在想要放置的畫面區域。
結論
許多人都在說Web2.0可能又是另一次的泡沫化，這個熱潮怎樣開始的，又怎樣消退的，也是相當明顯。網路上對於各種新技術名詞的炒作，將不同應用層次的技術，全部攪和在一起說明或稱做是最終解決方案，也模糊了使用者的眼睛。那麼，在這個時代，到底還有什麼可以相信，可以學習的？
唯一能夠做的就是重新審視這些技術，瞭解因果。就可以知道哪些作法是適合用在自己現在的專案，那些是本質相同的，哪些是跨大其詞的。根本的觀念正確，就不需要擔心這些延伸的技術是否會有誤解或誤用。