> For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel.
I don't see any inherent conflict between preventing sites from having access to the local filesystem, while having powerful local filesystem access from the browser's integrated devtools. One does not exclude the other.
> Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.
Caching rules should be managed on the server, not the client. Properly configured servers/applications never need anyone to clear their caches explicitly. I don't see why you would need a special cache-less mode in the browser if you've set up your servers correctly.
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. Your browser should have the exact same app experience as the one your users use, so it shouldn't have any special developer-mode behavior. That doesn't mean you don't need powerful inspection tools, just that those tools should be built around that standard experience instead of altering it.
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 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.
> For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel.
I don't see any inherent conflict between preventing sites from having access to the local filesystem, while having powerful local filesystem access from the browser's integrated devtools. One does not exclude the other.
> Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.
Caching rules should be managed on the server, not the client. Properly configured servers/applications never need anyone to clear their caches explicitly. I don't see why you would need a special cache-less mode in the browser if you've set up your servers correctly.
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. Your browser should have the exact same app experience as the one your users use, so it shouldn't have any special developer-mode behavior. That doesn't mean you don't need powerful inspection tools, just that those tools should be built around that standard experience instead of altering it.