單頁式應用程式
此條目翻譯自其他語言維基百科，需要相關領域的編者協助校對翻譯。 |
此條目需要補充更多來源。 (2018年2月25日) |
單頁應用（英語：single-page application，縮寫SPA）是一種網絡應用程序或網站的模型，它通過動態重寫當前頁面來與用戶交互，而非傳統的從服務器重新加載整個新頁面。這種方法避免了頁面之間切換打斷用戶體驗，使應用程序更像一個桌面應用程序。在單頁應用中，所有必要的代碼（HTML、JavaScript和CSS）都通過單個頁面的加載而檢索[1]，或者依需（通常是為響應用戶操作）動態載入適當的資源並添加到頁面。儘管可以用位置散列或HTML5歷史API來提供應用程序中單獨邏輯頁面的感知和導航能力，但頁面在過程中的任何時間點都不會重新加載，也不會將控制轉移到其他頁面。[2]與單頁應用的交互通常涉及到與網頁伺服器後端的動態通信。
歷史
編輯儘管早在2003年就討論過這個概念，但單頁應用（single-page application）一詞的起源並不明晰。[3]Stuart (stunix) Morris在2002年4月編寫的自主網站slashdotslash.com有着相同的目標和功能[4]；同年稍晚，Lucas Birdeau、Kevin Hakman、Michael Peachey和Evan Yeh在美國專利8,136,109中描述了一個單頁式應用程式的實作概念。[5]
在網頁瀏覽器中可以使用JavaScript顯示用戶界面（UI）、運行應用程序邏輯，以及與Web服務器通信。成熟的開源程式庫支持構建一個單頁應用，從而減少開發人員要編寫的JavaScript代碼量。
技術舉措
編輯現今已有各種技術可以使網頁瀏覽器停留在單個頁面，並同時支持應用程序與服務器通信。
JavaScript框架
編輯諸如Angular、Ember.js、Meteor.js、ExtJS和React等網頁瀏覽器端的JavaScript框架採納了單頁應用（SPA）原則。
- Angular是一個全面的客戶端側框架。其模板基於雙向UI數據綁定。數據綁定是一種自動方法，在模型改變時更新視圖，以及在視圖改變時更新模型。其HTML模板在瀏覽器中編譯。編譯步驟創建純HTML，瀏覽器將其重新渲染到實時視圖。該步驟會在隨後的頁面瀏覽中重複。在傳統的服務器端HTML編程中，控制器和模型等概念在服務器進程中進行交互以產生新的HTML視圖。在Angular框架中，控制器和模型狀態在客戶端的瀏覽器中維護，從而使生成新頁面不依賴與服務器的交互。
- Ember.js是基於模型-視圖-控制器（MVC）軟件架構模型的客戶端側JavaScript Web應用程序框架。它允許開發人員在一個框架中通過常用的習慣用語和最佳實踐來創建可伸縮的單頁面應用程序。該框架提供豐富的對象模型、聲明性雙向數據綁定、計算屬性，Handlebars.js提供的自動更新模板，以及一個路由器管理應用程序狀態。
- Meteor.js是一個專門為單頁應用設計的全棧（客戶端-服務器）JavaScript框架。它具有比Angular、Ember或ReactJS更簡單的數據綁定特性[6]，並且使用Distributed Data Protocol[7]和一個發布/訂閱來自動將數據更改傳播到客戶端，無需開發人員編寫任何同步代碼。全棧反應確保從數據庫到模板的所有層都可以在必要時自動更新。諸如服務器端渲染[8]等生態系統包則解決搜索引擎優化（SEO）等問題。
- Aurelia （頁面存檔備份，存於網際網路檔案館）是一個適用於移動設備、桌面和網頁的JavaScript客戶端框架。它類似AngularJS，但更新、更符合標準，並採用模塊化舉措。Aurelia使用下一代ECMAScript編寫。[來源請求]
- Vue.js（通常稱為Vue）是一個用於構建用戶界面的開源漸進式JavaScript框架。
- React（通常寫為React.js或ReactJS）是一個構建用戶界面的JavaScript函式庫。它由Facebook、Instagram和個人開發者以及企業社區維護。React最大的優勢是易於使用——基本上任何熟悉HTML的開發人員都可以創建React應用程序。另一個所稱的優勢是可能使用相同的技術堆棧來同時創建Web與移動應用程序。有多家公司使用React和Redux庫來讓開發人員創建複雜但可擴展的Web應用程序。[9]
- Fulcro是一個全棧庫，它採用Netflix的Falcor，Facebook的Relay和Om Next對反應性，功能性，數據驅動軟件進行改編的數據驅動原則。[10][需要較佳來源]
Ajax
編輯目前最常採用Ajax技術。主要從JavaScript使用XMLHttpRequest/ActiveX對象（已不建議使用），其他Ajax方法包括使用IFRAME或script HTML元素。jQuery等流行的庫可以為不同廠商的瀏覽器的Ajax行為標準化，進一步推廣了Ajax技術。
Websocket
編輯WebSocket是HTML5規範中的一個雙向有狀態實時客戶端與服務器通信技術，在性能和簡單性方面優於Ajax[11]。
服務器發送事件
編輯服務器發送事件（SSE）是一種服務器向瀏覽器客戶端發起數據傳輸的技術。一旦建立了初始連接，事件流將保持打開狀態，直到客戶端關閉。該技術通過傳統的HTTP發送，並具有WebSockets缺乏的各種功能，例如自動重新連接、事件ID以及發送任意事件的能力。[12]
瀏覽器插件
編輯可以使用瀏覽器插件技術（如Silverlight、Flash或Java applet）實現對服務器的異步調用。此種方法在業界已經過時。
數據傳輸（XML、JSON）
編輯對服務器的請求通常會帶來原始數據（如XML或JSON）或傳回新的HTML。在服務器返回HTML時，客戶端上的JavaScript將更新DOM的部分區域。[13]在返回原始數據時，客戶端側的JavaScript通常將其轉換為HTML，然後用它來更新DOM的部分區域。
服務器架構
編輯瘦服務器架構
編輯SPA技術將邏輯從服務器轉移到了客戶端。這導致Web服務器發展為一個純數據API或Web服務。這種架構的轉變在一些圈子中被稱為「瘦服務器架構」，以強調複雜性已從服務端轉移到客戶端，並認為這最終降低了系統的整體複雜性。
胖的有狀態服務器架構
編輯這種設計是服務器在內存中保存必要的客戶端所處狀態。這種模式下，當任何請求到達服務器（通常因用戶操作）時，服務器發送適當的HTML和/或JavaScript，以及具體的更改，以使客戶端達到新的期望狀態（如添加、刪除或更新部分客戶端的DOM）。與此同時更新服務器中的狀態。這種設計下的大部分邏輯都在服務器上運行，HTML通常也在服務器上呈現。在某些方面，服務器是模擬Web瀏覽器，接收事件並執行服務器狀態下的增量更改，將這些更改自動傳播到客戶端。
這種方法需要更多的服務器內存和處理能力，但優點是簡化的開發模型，因為：1、應用程序通常完全在服務器中編寫；2、服務器中的數據和UI狀態在相同的內存空間中共享，不需要自定義客戶端/服務器通信隧道。
胖的無狀態服務器架構
編輯這是有狀態服務器方法的變體。客戶端頁面通常通過Ajax請求將表示其當前狀態的數據發送到服務器。服務器使用這些數據能夠重新構建需要修改的頁面部分，並生成必要的數據或代碼（如作為JSON或JavaScript），將其返回給客戶端使其它達到新的狀態。
此方法需要將更多數據發送給服務器，並可能需要更多計算資源才能部分或完全重建在服務器中的客戶端頁面狀態。不過，這種方法更容易擴展，因為服務器中不存在每個客戶端的頁面數據，因此可以將Ajax請求分派到不同的服務器節點，而無需會話數據共享或服務器關聯。
本機執行
編輯部分單頁應用可以使用file URI方案依賴本地文件運行。這使用戶可以從服務器上下載單頁應用並在本地設備中運行，而不需要依賴與服務器的網絡連接。這類單頁應用如果想要存儲或更新數據，則必須使用基於瀏覽器的網頁存儲。這些應用受益於HTML5提供的高級功能。[14]
SPA模式帶來的挑戰
編輯由於單頁應用偏離了最初為瀏覽器設計的無狀態頁面重繪模型，所以帶來了一些新挑戰。每個問題都有一個或一些有效的解決方案[15]：
搜索引擎優化
編輯由於一些流行的網絡搜索引擎的爬蟲缺乏JavaScript執行能力[20]，搜尋引擎最佳化（SEO）已成為面向公眾的網站採用單頁應用模型必須面對的一個問題。[21]
在2009至2015年間，Google網站管理員提出並推薦了一個「AJAX爬取方案」[22][23]，其中使用起始為感嘆號的片段標識符（#!）來標識有狀態的AJAX頁面。單頁應用網站必須實作特殊行為才能允許搜索引擎的爬取工具提取相關的元數據。對於不支持此URL散列方案的搜索引擎，單頁應用的散列網址會被視而不見。包括Jeni Tennison在內的許多作者認為這些「hash-bang」URI在W3C中被認為是存在問題的，因為它們使那些沒有在瀏覽器中激活JavaScript的人無法訪問頁面。這也影響HTTP參照位址標頭，因為瀏覽器不允許在Referer標頭中發送片段標識符。[24]2015年，Google不再建議使用散列AJAX爬取方案。[25]
還有一些周邊方法可以使網站表現為可抓取，它們都涉及創建反應單頁應用內容的獨立HTML頁面。服務器可以創建基於HTML的網站版本並將此提供給爬取工具，也可以使用PhantomJS等無頭(headless)瀏覽器運行JavaScript應用程序並輸出生成的HTML。
這種方法需要付出不小的努力，最終可能給大型、複雜的網站帶來很大的維護成本，並且也有潛在風險。如果服務器生成的HTML被認為與單頁應用存在較大差異，則網站排名將受到處罰。運行PhantomJS來輸出HTML可能會降低頁面的響應速度，一些搜索引擎（尤其是Google）可能因此對排名降級。[26]
客戶端/服務器代碼分區
編輯增加服務器與客戶端之間所共享代碼量的一種方法是使用如Mustache、Handlebars等無邏輯模板語言。這種模板可以用不同的託管語言來呈現，如服務器上的Ruby和客戶端的JavaScript。但是，單純共享模板通常需要重複使用業務邏輯來選擇正確的模板，並使用數據填充它們。僅更新頁面的一小部分（諸如大型模板中的一個文本的值）時，從模板呈現可能會產生負面的性能影響。替換整個模板也可能會干擾用戶的選擇或光標位置，只更新變更的值則可能不會。為避免這些問題，應用程序可以使用UI數據綁定或粒度DOM操作來更新頁面的相應部分，而不是重新呈現整個模板。
瀏覽器歷史記錄
編輯根據單頁應用（SPA）模型的定義，它只有「單個頁面」，因此這打破了瀏覽器為頁面歷史記錄導航所設計的「上一頁、下一頁」功能。當用戶按下後退按鈕時，可能會遇到可用性障礙，頁面可能返回真正的上一個頁面，而非用戶所期望的上一個頁面。
傳統的解決方案是不斷更改瀏覽器網址（URL）的散列片段標識符以保持與當前的屏幕狀態一致。這種方案可以通過JavaScript實現，並在瀏覽器中建立起網址歷史事件。只要單頁應用能根據網址散列所包含的信息重新生成相同的屏幕狀態，就能實現預期的後退按鈕行為。
而為進一步解決此問題，HTML5規範引入了pushState （頁面存檔備份，存於網際網路檔案館）和replaceState （頁面存檔備份，存於網際網路檔案館）來提供程式碼對實際網址和瀏覽器歷史的訪問。
分析
編輯諸如Google分析等分析工具高度依賴在瀏覽器中加載全新的頁面，而單頁應用的工作方式不同於此。
初次加載的速度
編輯單頁應用的第一頁加載會比基於服務器的應用程式慢。這是因為首次加載必須先拿到框架和應用程序的代碼，再在瀏覽器中呈現所需的視圖。基於服務器的應用程序只需將所需的HTML推送到瀏覽器，從而減少了延遲和下載用時。
加快頁面加載速度
編輯有一些方法可以加快單頁應用的初次加載速度，比如採用多項緩存措施、需要時再加載某些模塊（延遲載入）。但這依舊不可能擺脫需要下載框架的事實，某些部分必須在呈現前下載。這是一個「現在支付，或者稍後支付」的問題。性能與等待時間的權衡是開發者必須作出的權衡。
頁面生命周期
編輯單頁應用在初始頁面加載時被完全加載，然後頁面區域被替換或更新為按需從服務器加載的新頁面片段。為避免過度下載未使用的功能，單頁應用通常會逐漸下載更多內容，如所需要的功能、頁面的一小塊，或者完整的一頁。
單頁應用（SPA）舉措與原生桌面應用程序所使用的多文件介面（MDI）呈現技術類似。
參考資料
編輯- ^ Flanagan, David, "JavaScript - The Definitive Guide", 5th ed., O'Reilly, Sebastopol, CA, 2006, p.497
- ^ Fixing the Back Button: SPA Behavior using Location Hash. [2016-01-18]. （原始內容存檔於2016-02-13） （美國英語）.
- ^ Inner-Browsing: Extending Web Browsing the Navigation Paradigm. [2011-02-03]. （原始內容存檔於2014-03-27）.
- ^ Slashdotslash.com: A self contained website using DHTML. [2012-07-06].
- ^ US patent 8,136,109. [2002-04-12]. （原始內容存檔於2017-08-15）.
- ^ Meteor Blaze. [2018-02-25]. （原始內容存檔於2020-12-05）.
Meteor Blaze is a powerful library for creating live-updating user interfaces. Blaze fulfills the same purpose as Angular, Backbone, Ember, React, Polymer, or Knockout, but is much easier to use. We built it because we thought that other libraries made user interface programming unnecessarily difficult and confusing.
- ^ Introducing DDP （頁面存檔備份，存於網際網路檔案館）, March 21, 2012
- ^ Server Side Rendering for Meteor. [31 January 2015]. （原始內容存檔於2015年3月20日）.
- ^ blak-it.com, BLAKIT,. Single-page applications vs. multiple-page applications: pros, cons, pitfalls - BLAKIT - IT Solutions. BLAKIT - IT Solutions. 2017-10-17 [2017-10-19]. （原始內容存檔於2017-10-19） （美國英語）.
- ^ The Benefits of Fulcro. 2017-11-02 [2018-02-25]. （原始內容存檔於2017-11-07）.
- ^ Real-Time Monitoring using AJAX and WebSockets. [2016-06-01]. （原始內容存檔於2018-11-30）.
- ^ Server-Sent Events. W3C. 17 July 2013 [2018-02-25]. （原始內容存檔於2021-02-02）.
- ^ Using InnerHTML. [2016-01-21]. （原始內容存檔於2021-01-27）.
- ^ Unhosted web apps. [2018-02-25]. （原始內容存檔於2021-01-25）.
- ^ The Single Page Interface Manifesto. [2014-04-25]. （原始內容存檔於2020-11-12）.
- ^ Derby. [2011-12-11]. （原始內容存檔於2015-08-01）.
- ^ Sails.js. [2013-02-20]. （原始內容存檔於2020-12-17）.
- ^ Tutorial: Single Page Interface Web Site With ItsNat. [2011-01-13]. （原始內容存檔於2016-03-12）.
- ^ HTML5
- ^ What the user sees, what the crawler sees. [January 6, 2014]. （原始內容存檔於2020-12-12）.
the browser can execute JavaScript and produce content on the fly - the crawler cannot
- ^ Making Ajax Applications Crawlable. [January 6, 2014]. （原始內容存檔於2020-12-12）.
Historically, Ajax applications have been difficult for search engines to process because Ajax content is produced
- ^ Proposal for making AJAX crawlable. Google. October 7, 2009 [July 13, 2011]. （原始內容存檔於2020-12-12）.
- ^ (Specifications) Making AJAX Applications Crawlable. Google. [March 4, 2013]. （原始內容存檔於2020-12-12）.
- ^ Hash URIs. W3C Blog. May 12, 2011 [July 13, 2011]. （原始內容存檔於2013-09-01）.
- ^ Deprecating our AJAX crawling scheme. Official Google Webmaster Central Blog. [2017-02-23]. （原始內容存檔於2021-02-17） （美國英語）.
- ^ Holmes, Simone (2015). Getting MEAN with Mongo, Express, Angular, and Node. Manning Publications. ISBN 978-1-6172-9203-3