後端路由 意味著 瀏覽器重新整理頁面。顯然很多 webapp 的需求上是不希望這樣的體驗的。網速慢的話說不定螢幕全白再有新內容。

前端路由就不會有這樣的問題了。隨意控制，邏輯也可以都放在前端。前端慢慢複雜化，自己的路由這種東西是必不可少的啦。

從效能和使用者體驗的層面來比較的話，後端路由每次訪問一個新頁面的時候都要向伺服器傳送請求，然後伺服器再響應請求，這個過程肯定會有延遲。而前端路由在訪問一個新頁面的時候僅僅是變換了一下路徑而已，沒有了網路延遲，對於使用者體驗來說會有相當大的提升

前端路由的實現由兩種方式：

一是通過改變hash值，監聽onhashchange事件，這種方式的優點是可以相容低版本瀏覽器

二是通過historyAPI,監聽popState事件，用pushState和replaceState來實現

前端路由和服務端路由的區別

• 服務端路由：每跳轉到不同的URL，都是重新訪問服務端，然後服務端返回頁面，頁面也可以是服務端獲取資料，然後和模板組合，返回HTML，也可以是直接返回模板HTML，然後由前端JS再去請求資料，使用前端模板和資料進行組合，生成想要的HTML。

• 前端路由：每跳轉到不同的URL都是使用前端的錨點路由，實際上只是JS根據URL來操作DOM元素，根據每個頁面需要的去服務端請求資料，返回資料後和模板進行組合，當然模板有可能是請求服務端返回的，這就是 SPA 單頁程式。

什麼是路由？

對於沒有開發過後端，也沒有開發過 SPA 的前端來說，「路由」這個名詞可能會讓人比較困惑，這裡的路由並不是指「硬體路由」，也不是網路七層協議中的「網路層路由」，但是其思想原理是一樣的。我儘量簡單通俗的介紹一下。

假如我們有一臺提供 Web 服務的伺服器的網路地址是：10.0.0.1，而該 Web 服務又提供了三個可供使用者訪問的頁面，其頁面 URI 分別是：

那麼其路徑就分別是 /，/about，/concat。

當用戶使用 http://10.0.0.1/about 來訪問該頁面時，Web 服務會接收到這個請求，然後會解析 URI 中的路徑 /about

前端路由

前端的路由和後端的路由在實現技術上不一樣，但是原理都是一樣的。在 HTML5 的 history API 出現之前，前端的路由都是通過 hash 來實現的，hash 能相容低版本的瀏覽器。如果我們把上面例子中提到的 3 個頁面用 hash 來實現的話，它的 URI 規則中需要帶上 #。

Web 服務並不會解析 hash，也就是說 # 後的內容 Web 服務都會自動忽略，但是 JavaScript 是可以通過 window.location.hash 讀取到的，讀取到路徑加以解析之後就可以響應不同路徑的邏輯處理。

history 是 HTML5 才有的新 API，可以用來操作瀏覽器的 session history (會話歷史)。基於 history 來實現的路由可以和最初的例子中提到的路徑規則一樣。

使用者可能都察覺不到該訪問地址是 Web 服務實現的路由還是前端實現的路由。

前端路由應用場景就是所謂的單頁應用。在業務允許瀏覽器允許的情況下使用前端路由可以讓頁面體驗較好。但是在例如很多業務情景下就不適用了，例如展示廣告，幾乎不需要在頁面上有其他邏輯，例如嚴謹的下單流程，後端路由可以嚴格控制前端不可進入頁面，還有後端路由可以應用於API層面提供介面等等許多的場景都是可以的。靈活選擇前後端路由會讓你的業務體驗相當不錯，或者更深層次的你用到了同構，前後端共用一套路由，在直接由回車進入頁面時將這套路由在服務端渲染輸出，但是頁面點選跳轉等動作時又是前端路由…