I don't quite see it that way.

> 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 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.

>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.

https://code.google.com/p/chromium/issues/detail?id=328026

>Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.

Chrome Inspector -> [x] Disable cache (while DevTools is open)

Or Firefox Dev Tools -> Settings -> [x] Disable Cache (when toolbox is open)

:)

I suspect a lot of the "dev edition" will just be a different set of defaults :)

> https://code.google.com/p/chromium/issues/detail?id=328026

Interesting. I think there is also a plugin for WebStorm to send back modification made in the style panel to the actual files. Sadly sass/less resources makes it difficult to edit CSS and have it applied back to the sass source for instance.

> Chrome Inspector -> [x] Disable cache (while DevTools is open)

Yes, that's what I use for all my projects. Also there is a "Disable Caches" option in the Develop menu of Safari.

A fellow developer in my office uses Incognito mode, and it seems to work fine for him.

That reminds me: It would be nice if you could open several different incognito windows, each with their own session. That way one can debug user interactions without needing as many browsers as users in the interaction (or half of it because each browser has it's own incognito session in addition to the normal session).

A workaround that I've used before is to connect to my site via the domain name in one tab, and the IP address in another - cross domain protection ensures I get two nicely partitioned sessions.

Yep, I also used that. And several entries in /etc/hosts.

These are great points but also speak to one of my concerns about forking--what if Firefox continues to receive lots of security scrutiny but this new-but-still-pretty-intimately-related product aimed at devs mostly doesn't, for whatever reason (e.g. far fewer people using it)?

I see more value for both developers and users currently because it means that in order to keep Firefox safe (for some definition of safe), the Mozilla security team also has to keep people like us--and the functionality we use--just as safe. It also means derivatives like the Tor Browser Bundle and Iceweasel might be more likely to preserve the feature set and benefit from security team's work in relation to it.

A live example: If you are developing a chrome extension on Windows, everytime you open Chrome you'd be bugged with a popup which suggests "Disable Developer Mode Extensions". [1] Although developers are annoyed as hell, the Chrome team insisted this decision on the ground of protecting users.

[1] https://code.google.com/p/chromium/issues/detail?id=337734

Their point is entirely valid though, and it all boils down to: there is no such thing as a secure backdoor.