讓我們先來看幾個網站：
注意這幾個網站的相同點，那就是在瀏覽器中，做了原先“應當”在客戶端做的事情。它們的介面切換非常流暢，響應很迅速，跟傳統的網頁明顯不一樣，它們是什麼呢？這就是單頁Web應用。
所謂單頁應用，指的是在一個頁面上整合多種功能，甚至整個系統就只有一個頁面，所有的業務功能都是它的子模組，通過特定的方式掛接到主介面上。它是AJAX技術的進一步昇華，把AJAX的無重新整理機制發揮到極致，因此能造就與桌面程式媲美的流暢使用者體驗。
其實單頁應用我們並不陌生，很多人寫過ExtJS的專案，用它實現的系統，很天然的就已經是單頁的了，也有人用jQuery或者其他框架實現過類似的東西。用各種JS框架，甚至不用框架，都是可以實現單頁應用的，它只是一種理念。有些框架適用於開發這種系統，如果使用它們，可以得到很多便利。
開發框架
ExtJS可以稱為第一代單頁應用框架的典型，它封裝了各種UI元件，使用者主要使用JavaScript來完成整個前端部分，甚至包括佈局。隨著功能逐漸增加，ExtJS的體積也逐漸增大，即使用於內部系統的開發，有時候也顯得笨重了，更不用說開發以上這類執行在網際網路上的系統。
jQuery由於偏重DOM操作，它的外掛體系又比較鬆散，所以比ExtJS這個體系更適合開發在公網執行的單頁系統，整個解決方案會相對比較輕量、靈活。
但由於jQuery主要面向上層操作，它對程式碼的組織是缺乏約束的。如何在程式碼急劇膨脹的情況下控制每個模組的內聚性，並且適當在模組之間產生資料傳遞與共享，就成為了一種有挑戰的事情。
為了解決單頁應用規模增大時候的程式碼邏輯問題，出現了不少MV*框架，他們的基本思路都是在JS層建立模組分層和通訊機制。有的是MVC，有的是MVP，有的是MVVM，而且，它們幾乎都在這些模式上產生了變異，以適應前端開發的特點。
這類框架包括Backbone，Knockout，AngularJS，Avalon等。
元件化
這些在前端做分層的框架推動了程式碼的元件化，所謂元件化，在傳統的Web產品中，更多的指UI元件，但其實元件是一個廣泛概念，傳統Web產品中UI元件佔比高的原因是它的厚度不足，隨著客戶端程式碼比例的增加，相當一部分的業務邏輯也前端化，由此催生了很多非介面型元件的出現。
分層帶來的一個優勢是，每層的職責更專一了，由此，可以對其作單元測試的覆蓋，以保證其質量。傳統UI層測試最頭疼的問題是UI層和邏輯混雜在一起，比如往往會在遠端請求的回撥中更改DOM，當引入分層之後，這些東西都可以分別被測試，然後再通過場景測試來保證整體流程。
程式碼隔離
與開發傳統頁面型網站相比，實現單頁應用的過程中，有一些比較值得特別關注的點。
從單頁應用的特點來看，它比頁面型網站更加依賴於JavaScript，而由於頁面的單頁化，各種子功能的JavaScript程式碼聚集到了同一個作用域，所以程式碼的隔離、模組化變得很重要。
在單頁應用中，頁面模板的使用是很普遍的。很多框架內建了特定的模板，也有的框架需要引入第三方的模板。這種模板是介面片段，我們可以把它們類比成JavaScript模組，它們是另一種型別的元件。
模板也一樣有隔離的需要。不隔離模板，會造成什麼問題呢？模板間的衝突主要存在於id屬性上，如果一個模板中包含固定的id，當它被批量渲染的時候，會造成同一個頁面的作用域中出現多個相同id的元素，產生不可預測的後果。因此，我們需要在模板中避免使用id，如果有對DOM的訪問需求，應當通過其他選擇器來完成。如果一個單頁應用的元件化程度非常高，很可能整個應用中都沒有元素id的使用。
程式碼合併與載入策略
人們對於單頁系統的載入時間容忍度與Web頁面不同，如果說他們願意為購物頁面的載入等待3秒，有可能會願意為單頁應用的首次載入等待5-10秒，但在此之後，各種功能的使用應當都比較流暢，所有子功能頁面儘量要在1-2秒時間內切換成功，否則他們就會感覺這個系統很慢。
從這些特點來看，我們可以把更多的公共功能放到首次載入，以減小每次載入的載入量，有一些站點甚至把所有的介面和邏輯全部放到首頁載入，每次業務介面切換的時候，只產生資料請求，因此它的響應是非常迅速的，比如青雲的控制檯就是這麼做的。
通常在單頁應用中，無需像網站型產品一樣，為了防止檔案載入阻塞渲染，把js放到html後面載入，因為它的介面基本都是動態生成的。
當切換功能的時候，除了產生資料請求，還需要渲染介面，這個新渲染的介面部件一般是介面模板，它從哪裡來呢？來源無非是兩種，一種是即時請求，像請求資料那樣通過AJAX獲取過來，另一種是內建於主介面的某些位置，比如script標籤或者不可見的textarea中，後者在切換功能的時候速度有優勢，但是加重了主頁面的負擔。
在傳統的頁面型網站中，頁面之間是互相隔離的，因此，如果在頁面間存在可複用的程式碼，一般是提取成單獨的檔案，並且可能會需要按照每個頁面的需求去進行合併。單頁應用中，如果總的程式碼量不大，可以整體打包一次在首頁載入，如果大到一定規模，再作執行時載入，載入的粒度可以搞得比較大，不同的塊之間沒有重複部分。
路由與狀態的管理
我們最開始看到的幾個線上應用，有的是對路由作了管理的，有的沒有。
管理路由的目的是什麼呢？是為了能減少使用者的導航成本。比如說我們有一個功能，經歷過多次導航選單的點選，才呈現出來。如果使用者想要把這個功能地址分享給別人，他怎麼才能做到呢？
傳統的頁面型產品是不存在這個問題的，因為它就是以頁面為單位的，也有的時候，服務端路由處理了這一切。但是在單頁應用中，這成為了問題，因為我們只有一個頁面，介面上的各種功能區塊是動態生成的。所以我們要通過對路由的管理，來實現這樣的功能。
具體的做法就是把產品功能劃分為若干狀態，每個狀態對映到相應的路由，然後通過pushState這樣的機制，動態解析路由，使之與功能介面匹配。
有了路由之後，我們的單頁面產品就可以前進後退，就像是在不同頁面之間一樣。
其實在Web產品之外，早就有了管理路由的技術方案，Adobe Flex中，就會把比如TabNavigator，甚至下拉框的選中狀態對應到url上，因為它也是單“頁面”的產品模式，需要面對同樣的問題。
當產品狀態複雜到一定程度的時候，路由又變得很難應用了，因為狀態的管理極其麻煩，比如開始的時候我們演示的c9.io線上IDE，它就沒法把狀態對應到url上。
快取與本地儲存
在單頁應用的運作機制中，快取是一個很重要的環節。
由於這類系統的前端部分幾乎全是靜態檔案，所以它能夠有機會利用瀏覽器的快取機制，而比如動態載入的介面模板，也完全可以做一些自定義的快取機制，在非首次的請求中直接取快取的版本，以加快載入速度。
甚至，也出現了一些方案，在動態載入JavaScript程式碼的同時，把它們也快取起來。比如Addy Osmani的這個basket.js，就利用了HTML5 localStorage作了js和css檔案的快取。
在單頁產品中，業務程式碼也常常會需要跟本地儲存打交道，儲存一些臨時資料，可以使用localStorage或者localStorageDB來簡化自己的業務程式碼。
服務端通訊
傳統的Web產品通常使用JSONP或者AJAX這樣的方式與服務端通訊，但在單頁Web應用中，有很大一部分採用WebSocket這樣的實時通訊方式。
WebSocket與傳統基於HTTP的通訊機制相比，有很大的優勢。它可以讓服務端很便利地使用反向推送，前端只響應確實產生業務資料的事件，減少一遍又一遍無意義的AJAX輪詢。
由於WebSocket只在比較先進的瀏覽器上被支援，有一些庫提供了在不同瀏覽器中的相容方案，比如socket.io，它在不支援WebSocket的瀏覽器上會降級成使用AJAX或JSONP等方式，對業務程式碼完全透明、相容。
記憶體管理
傳統的Web頁面一般是不需要考慮記憶體的管理的，因為使用者的停留時間相對少，即使出現記憶體洩漏，可能很快就被重新整理頁面之類的操作沖掉了，但單頁應用是不同的，它的使用者很可能會把它開一整天，因此，我們需要對其中的DOM操作、網路連線等部分格外小心。
樣式的規劃
在單頁應用中，因為頁面的整合度高，所有頁面聚集到同一作用域，樣式的規劃也變得重要了。
樣式規劃主要是幾個方面：
基準樣式的分離
這裡面主要包括瀏覽器樣式的重設、全域性字型的設定、佈局的基本約定和響應式支援。
元件樣式的劃分
這裡面是兩個層面的規劃，首先是各種介面元件及其子元素的樣式，其次是一些修飾樣式。元件樣式應當儘量減少互相依賴，各元件的樣式允許冗餘。
堆疊次序的管理
傳統Web頁面的特點是元素多，但是層次少，單頁應用會有些不同。
在單頁應用中，需要提前為各種UI元件規劃堆疊次序，也就是z-index，比如說，我們可能會有各種彈出對話方塊，浮動層，它們可能組合成各種堆疊狀態。新的對話方塊的z-index需要比舊的高，才能確保蓋在它上面。諸如此類，都需要我們對這些可能的遮蓋作規劃，那麼，怎樣去規劃呢？
瞭解通訊知識的人，應當會知道，不同的頻率段被劃分給不同的通訊方式使用，在一些國家，領空的使用也是有劃分的，我們也可以用同樣的方式來預先分段，不同型別的元件的z-index落到各自的區間，以避免它們的衝突。
單頁應用的產品形態
我們在開始的時候提到，存在著很多新型Web產品，使用單頁應用的方式構建，但實際上，這類產品不僅僅存在於Web上。點開Chrome商店，我們會發現很多離線應用，這些產品都可以算是單頁應用的體現。
除了各種瀏覽器外掛，藉助node-webkit這樣的外殼平臺，我們可以使用Web技術來構建本地應用，產品的主要部分仍然是我們熟悉的單頁應用。
單頁應用的流行程度正在逐漸增加，大家如果關注了一些初創型網際網路企業，會發現其中很大一部分的產品模式是單頁化的。這種模式能帶給使用者流暢的體驗，在開發階段，對JavaScript技能水平要求較高。
單頁應用開發過程中，前後端是天然分離的，雙方以API為分界。前端作為服務的消費者，後端作為服務的提供者。在此模式下，前端將會推動後端的服務化。當後端不再承擔模板渲染、輸出頁面這樣工作的情況下，它可以更專注於所提供的API的實現，而在這樣的情況下，Web前端與各種移動終端的地位對等，也逐漸使得後端API不必再為每個端作差異化設計了。
部署模式的改變
在現在這個時代，我們已經可以看到一種產品的出現了，那就是“無後端”的Web應用。這是一種什麼東西呢？基於這種理念，你的產品很可能只需要自己編寫靜態Web頁面，在某種BaaS（Backend as a Service）雲平臺上定製服務端API和雲端儲存，整合這個平臺提供的SDK，通過AJAX等方式與之打交道，實現註冊認證、社交、訊息推送、實時通訊、雲端儲存等功能。
我們觀察一下這種模式，會發現前後端的部署已經完全分離了，前端程式碼完全靜態化，這意味著可以把它們放置到CDN上，訪問將大大地加速，而服務端託管在BaaS雲上，開發者也不必去關注一些部署方面的繁瑣細節。
假設你是一名創業者，正在做的是一種實時協同的單頁產品，可以在雲平臺上，快速定製後端服務，把絕大部分寶貴的時間花在開發產品本身上。
單頁應用的缺陷
單頁應用最根本的缺陷就是不利於SEO，因為介面的絕大部分都是動態生成的，所以搜尋引擎很不容易索引它。
產品單頁化帶來的挑戰
一個產品想要單頁化，首先是它必須適合單頁的形態。其次，在這個過程中，對開發模式會產生一些變更，對開發技能也會有一些要求。
開發者的JavaScript技能必須過關，同時需要對元件化、設計模式有所認識，他所面對的不再是一個簡單的頁面，而是一個執行在瀏覽器環境中的桌面軟體。