SPA是什麼？

認識SPA

最先單頁面的應用無從知曉，在2004年，google的Gmail就使用了單頁面。到了2010年，隨着Backbone的問世以後，此概念才慢慢熱了起來。

隨着後來React、Angular、Vue的興起，單頁面應用才成了前端圈裏人人皆知的架構模式。

接下來將經過對比傳統頁面應用和單頁面應用來講明SPA具體是什麼。

 

傳統的頁面應用

早期web應用的先後端交互模式是這樣的，每一個html做爲一個功能元件，經過刷新、超連接、表單提交等方式，將頁面組織起來後給用戶提供交互。

後期不少流行的框架都是基於此模式進行設計的，好比 Ruby on Rails，Spring MVC，Express 等等

傳統的web應用中，瀏覽器只是做爲展現層，路由、服務調用、頁面跳轉都是服務端來處理的。也就是MVC的架構都是放在後端的，只有V這一層，將頁面經過網絡發送到瀏覽器端，渲染給用戶。

傳統的模式具備如下特色：

• 重服務端：瀏覽器只做爲展現層，將MVC全置於後端，加劇了服務端的體量，開發中主要之後端爲主。
• 頻繁刷新：頁面展現依賴於不一樣的功能元件，因此必須依靠刷新頁面，或者跳轉路由來實現功能塊的切換，這種方式嚴重耗費資源，同時用戶體驗不好。

 

單頁面應用

和傳統應用相比較，單頁面應用就是將MVC個架構搬到了前端來實現

• 控制器：將處理路由的功能放在前端，當瀏覽器的路由發生變化時，由控制器來響應其變化，指向其對應的處理邏輯（組件），最終將頁面展示給用戶。
• 視圖：這一層就是功能元件，也就是單個的組件，當路由發生變化的時候由組件來處理，只處理變化的那部分，最後組織成頁面。
• 數據層：單頁面應用有本身的數據層定義，簡化了後端服務的複雜度，後端只要提供公共的數據接口便可，而數據層會對數據服務API進行進一步的封裝，而後提供數據給視圖層。

如此看來單頁面應用很像移動客戶端，後端的精力就是提供高質量的、可複用的Rest API服務。

 

單頁面應用的出現依然存在着爭議性，咱們該如何看待他的兩面性呢？

單頁面應用的優點：

• 無刷新體驗：沒有了使人詬病的頁面頻繁刷新，同時節約瀏覽器資源，路由響應比較及時，提高了用戶的體驗。
• 共享組件：前端組件化是將獨立完整的功能模塊封裝到一個組件中，代碼結構更加規範，便於代碼維護，同時模塊化後的組件能夠在不一樣的場景中進行復用，極大地加快了迭代開發的速度。這也是爲何主流的前端框架都提倡組件化編程的緣由。
• 共享API：給後端減負，前端加碼的好處就是，前端能有一點口糧吃了（開玩笑，前端那麼牛怎麼能沒飯吃呢？），前端擔起家務的事，後端就能夠安心地處理業務邏輯了，因而才能寫出高質量並可共享的API，供本身或者其餘的合做夥伴使用。一個優秀的產品背後，必定有一羣出色的前端（小生臉皮太厚）。

單頁面應用的劣勢：

• 擡高了前端門檻：SPA模式的流行，引領了前端技術的飛速發展，與此同時對前端人員在學習和使用上的能力就有了更高的要求，同時工做量也增長了，前端想活的更好就要付出的更多，因此不要再覺得前端就是切切圖，畫畫頁面這麼簡單。too young, too naive。
• 首次加載大量資源：既然只有一個頁面顯示，那許多功能元件（組件）所依賴的靜態資源就須要在初次時進行加載，加載時間相對比較長。
• 不利於SEO：單頁面應用，數據都是在前端進行渲染的，因此就影響了SEO。

 

 

 

 

原文：https://segmentfault.com/a/1190000011325283