I thought long and hard about this all morning. This is a very interesting question.
I think the solution that Christian purposed, which is also the defacto-standard, is an inelegant solution that works against progressive enhancement. While it could be said that it is progressive because if the user does not have the site Javascript enabled, they will simply see a slim version of the website without the extra goodies loaded on view.
However, I don't like this approach. I have Javascript mostly disabled in my browser, and I run my windows at 1024 - 1280px most of the time, and a site designed for a base of 800px with Javascript on-loads will look pretty bare to me.
That said, I think I may have come up with a solution.
I think the best way to go about responsive design might be by using a tracking image and server-side intervention.
In your style sheets, you could have:
@media (screen and max-device-width(800px) {
#sometag {
background-image: url('track-800.gif');
}
}
@media (screen and max-device-width(496px) {
#sometag {
background-image: url('track-496.gif');
}
}
Now, provided that image is served on a cookie-enabled domain, the web browser will pass the session id back to the server, enabling sessions on that request. If you have these images served by a php-script, you can now track and store the size of the device the user is using.
Given this information now stored in a session variable, you can disable areas of the page (on subsequent page loads) that will never display for the users device resolution.
Disclaimer
This method would require utilizing max-device-width() media queries, rather than max-width() queries. The difference is the application size would be based on the size of the users display, rather than the size of the window.
I'm also somewhat skeptical that every new web app needs to be an SPA but one thing I'm 100% sold on as a generalist with the bulk of his experience on the client side is that a service-oriented architecture that hands off raw data rather than HTML to the client is the way to go whether you're loading prebuilt pages/views from the server and doing a lot of dynamic stuff with data after page load or building almost everything 100% with JavaScript.
The reasons this is preferable to a client-side dev are much the same as the reasons nobody wants HTML in the database. What's the client-side dev supposed to do when they want to resort a table for instance when they've been handed HTML? The performance cost of handling all that on the client is trivial compared to making another server request to do that for you. Also, HTML-building is pretty well-covered in JS-land. Sorting data and building new HTML table rows out of it is pretty trivial work for an experienced client-side dev.
And of what use is the back end architecture to a front end for another device that might need to do something exotic like implement widgets that are 100% canvas or a totally different HTML structure? Why should a client-side dev have to load up visual studio or knock on the back end devs door to make a strictly presentational tweak?
As for your concerns about the loss of strongly typed template validation, trust me when I say that if you're dealing with a competent client-side dev, you will find no .NET framework or visual studio tool that is more coal-to-diamond-to-dust-crushingly anal about well-formed, valid HTML than s/he is.
From the full-stack perspective, I like it because it means I'll never have to fish for business or app logic some yutz decided to drop into the templating layer. Not to mention the per-user load it takes off of your servers while in many cases actually improving load experience for the user in modern browsers with modern computers.
I think it's also easier to reason about the back end architecture when you've fully isolated it from all the presentation stuff. You're no longer grabbing data to mash it into some HTML. You're pulling it together to create an implementation-independent data structure that concerns itself more with general use than what's going to be done with it on the other side. IMO, that tends to lead to more consistency in how things are handled since the data is now an end goal rather than the second to last step of a process and there's fewer opportunities for unrelated concerns to get their wires crossed.
Best Answer
My first advice is when the action suggests it, use navigation. This doesn't tell a lot but think of nav buttons or links to articles from the same page, etc where users intuitively awaits full navigation responses.
Partial page request are for places where a new rendered page is too much, like photos slides, little pieces of information, or adding a post like here. You wouldn't expect a PPR when clicking on a stackexchange question but you do when voting up a question.
In addition, PPR and browser history is sometimes difficult to implement. Don't work in vain when users won't expect, need or appreciate partial loading.