前端路由与后端路由

后端路由 意味着 浏览器刷新页面。显然很多 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 分别是：

1 2 3

http : //10.0.0.1/ http : //10.0.0.1/about http : //10.0.0.1/concat

那么其路径就分别是 /，/about，/concat。

当用户使用 http://10.0.0.1/about 来访问该页面时，Web 服务会接收到这个请求，然后会解析 URI 中的路径 /about，在 Web 服务的程序中，该路径对应着相应的处理逻辑，程序会把请求交给路径所对应的处理逻辑，这样就完成了一次「路由分发」，这个分发就是通过「路由」来完成的。

前端路由

前端的路由和后端的路由在实现技术上不一样，但是原理都是一样的。在 HTML5 的 history API 出现之前，前端的路由都是通过 hash 来实现的，hash 能兼容低版本的浏览器。如果我们把上面例子中提到的 3 个页面用 hash 来实现的话，它的 URI 规则中需要带上 #。

1 2 3

http : //10.0.0.1/ http : //10.0.0.1/#/about http : //10.0.0.1/#/concat

Web 服务并不会解析 hash，也就是说 # 后的内容 Web 服务都会自动忽略，但是 JavaScript 是可以通过 window.location.hash 读取到的，读取到路径加以解析之后就可以响应不同路径的逻辑处理。

history 是 HTML5 才有的新 API，可以用来操作浏览器的 session history (会话历史)。基于 history 来实现的路由可以和最初的例子中提到的路径规则一样。

1 2 3

http : //10.0.0.1/ http : //10.0.0.1/about http : //10.0.0.1/concat

用户可能都察觉不到该访问地址是 Web 服务实现的路由还是前端实现的路由。

前端路由应用场景就是所谓的单页应用。在业务允许浏览器允许的情况下使用前端路由可以让页面体验较好。但是在例如很多业务情景下就不适用了，例如展示广告，几乎不需要在页面上有其他逻辑，例如严谨的下单流程，后端路由可以严格控制前端不可进入页面，还有后端路由可以应用于API层面提供接口等等许多的场景都是可以的。灵活选择前后端路由会让你的业务体验相当不错，或者更深层次的你用到了同构，前后端共用一套路由，在直接由回车进入页面时将这套路由在服务端渲染输出，但是页面点击跳转等动作时又是前端路由…