# Clientside routing (if there is such a thing)

One thing you sometimes lose with a browser app is the proper handling of the browser's "back" button and the ability to "deep link" into some specific view of the app.

The good news is we don't actually have to make those tradeoffs. Through the clever use of Backbone's router and HTML5 push state, browser apps can take over the world. Here's how it works...

## Same sh*t different URL

From the server perspective, how do we actually "hand control of routing to the client"? Ugh... that's not how the web works, right? The server has to answer actual http GET request when a user types your app's URL in their browser.

So what I mean is simply that you return the same app HTML at multiple URLs.

For example, it doesn't matter if you hit:

https://andbang.com/andyet/chat

or

https://andbang.com/basecamp

Either way, the server will return this HTML:

<!DOCTYPE html>
<script src="/&!.js"></script>


It may be helpful to think about it as a block of URLs that all just serve the app.

If you're using Express and Node it's quite easy to do.

app.get('/other/thing', function () {
// You could still serve other support pages
// and simple things at specific URLs.
});

// But then you want some sort of catch all that matches
// the range of URLs you're going to want the single page app
// to be available at:
app.get('*', function (req, res) {
res.sendFile('sameSh*t.html');
});


But, of course, the same thing can be done in most any framework, or even with an nginx config.

But the big difference is that at this point we've made finding/fetching the right data and rendering the right view the responsibility of the browser app, not the server.

## How to deal with clientside routes

And Bang has a task detail page for every task at a URL structure that looks like this: