tl;dr:

• 借助服务器端路由，您可以在点击链接时下载一个全新的网页，
• 通过客户端路由，Web 应用程序会为您下载、处理和显示新数据.

想象一下用户点击了一个简单的链接:Hello!</a>

在使用服务器端路由的网络应用上:

• 浏览器检测到用户点击了一个锚元素.
• 它向 href 标签中的 URL 发出 HTTP GET 请求
• 服务器处理请求，并发送一个新文档(通常是 HTML)作为响应.
• 浏览器完全丢弃旧网页，并显示新下载的网页.

如果网络应用使用客户端路由:

• 浏览器检测到用户点击了一个锚元素，就像以前一样.
• 客户端代码(通常是路由库)捕获此事件，检测到 URL 不是外部链接，然后阻止浏览器发出 HTTP GET 请求.
• 路由库然后手动更改浏览器中显示的 URL(使用 HTML5 历史 API，或者可能是旧浏览器上的 URL hashbangs)
• 路由库然后更改客户端应用程序的状态.例如，它可以根据路由规则更改根 React/Angular/etc 组件.
• 应用程序(特别是 MVC 库，如 React)然后处理状态更改.它呈现新组件，并在必要时从服务器请求新数据.但这次响应不一定是整个网页，也可能是原始"数据，在这种情况下，客户端代码会将其转换为 HTML 元素.

客户端路由听起来更复杂，因为它是.但是现在有些图书馆真的让这件事变得很容易.

客户端路由有几个好处:你下载更少的数据来显示新内容，你可以重用 DOM 元素，向用户显示加载通知等.但是，在服务器端生成 DOM 的 web 应用程序更容易抓取(通过搜索引擎)，从而使 SEO 优化更容易.结合这两种方法也是可能的，优秀的 Flow Router s-s-r 就是一个很好的例子.>

I'm a little bit confused about this, and I feel slightly stupid asking this question, but I want to understand it.

So, say I'm working with a client side web framework, like Backbone, Angular or Durandal. This framework includes routing.

But I of course still have a server for database stuff, and so on, which also has routing.

My question now is:

When to use "client-side routing" or "server-side routing"?

How is it "decided" whether routing is already performed on the client side or whether the request is first sent to the web server?

I have a particularly hard time imagining this because the client side could do routing before the server ever gets to know about that request.

I'd be very thankful if someone could explain how these two routing systems work together.

P.S.: I have not included code samples because I'm not looking for an answer concerning a particular framework, but concerning the routing process in general.

tl;dr:

• with server-side routing you download an entire new webpage whenever you click on a link,
• with client-side routing the webapp downloads, processes and displays new data for you.

---

Imagine the user clicking on a simple link: <a href="/hello">Hello!</a>

On a webapp that uses server side routing:

• The browser detects that the user has clicked on an anchor element.
• It makes an HTTP GET request to the URL found in the href tag
• The server processes the request, and sends a new document (usually HTML) as a response.
• The browser discards the old webpage altogether, and displays the newly downloaded one.

If the webapp uses client side routing:

• The browser detects that the user has clicked on an anchor element, just like before.
• A client side code (usually the routing library) catches this event, detects that the URL is not an external link, and then prevents the browser from making the HTTP GET request.
• The routing library then manually changes the URL displayed in the browser (using the HTML5 history API, or maybe URL hashbangs on older browsers)
• The routing library then changes the state of the client app. For example, it can change the root React/Angular/etc component according to the route rules.
• The app (particularly the MVC library, like React) then processes state changes. It renders the new components, and if necessary, it requests new data from the server. But this time the response isn't necessarily an entire webpage, it may also be "raw" data, in which case the client-side code turns it into HTML elements.

Client-side routing sound more complicated, because it is. But some libraries really make it easy these days.

There are several upsides of client-side routing: you download less data to display new content, you can reuse DOM elements, display loading notifications to user etc. However, webapps that generate the DOM on server side are much easier to crawl (by search engines), thereby making SEO optimization easier. Combining these two approaches is also possible, the excellent Flow Router s-s-r is a good example for that.