WRT caching, the experience of a developer is already completely different from that for a user - assets on a dev instance of you infrastructure (including both code and static files) are changing multiple times a minute.

I don't think that should necessarily be the case. By persisting resources in the cache after they are changed on the server there is an implicit promise of broken user experiences, since there is no control over which files are loaded from cache and which ones are not (so even for "harmless" images users will see mismatched artwork in the real world). Whatever caching strategy is used for production servers, it should involve a way to make sure users are fetching the latest version of a resource. The dev server can be configured identically and it will still do the right thing. Admittedly when you throw CDN's and other intermediates into the mix it becomes harder to have matching environments, but differences should be minimized as much as possible as a matter of development policy.

My dev server is set up identically to a production server, except that no concatenation or minification is done. I'm not happy with that last compromise, so fingers crossed that HTTP/2 gets here soon and we can stop concatenating, minifying and otherwise perverting our code and resources.

This is a lovely dream, but what if you're working on the caching software instead of the web app?

This discussion reminds me of Nescape Communicator of the old days, where a WYSIWG editor was bundled with everything else. Discovering HTML for the first time I actually used it to build small sites, but it got too heavy while being too limited very fast.

What I am saying is basically that I think we need powerful inspection tools, but Frankensteining editing and compiling tools to the normal browser would result in something way too complex, with lots of modes and settings to adjust, and it doesn't seem like a healthy path for something that is supposed to be user friendly, lightweight and high performance for everyone else.

In a way, I am afraid Chrome is precisely going in this direction, including all the features for the normal users (the Flash plugin for instance) with also progressively more and more power tools only relevant to developers.

> In my view developer modes (in browser or framework) are counterproductive because they create discrepancies between how your users experience your site or app and how you experience it.

I think we agree on this point, and having separate tools for building and testing a site would allow to switch between the two mindsets more easily. The testing would be done exactly on the same app, so on the same footing as the users, and not on an application with some hybrid half editing/half testing state. There would be fewer "it works for me, what's your problem people ?" moments I think.

Its not always caches being out of date, what about reproducing bugs that happen on page load? Sometimes you just need to force a fetch.