1. You can already set up a local host on your machine to run tests. I thought that was standard practice.

2. I'm glad browsers are offering a similar solution which is easier to set up and useful for front end work. I just checked to see if Firefox has similar functionality, and it seems they support diffs for CSS only, but there is an add-on called Resource Override that appears to have similar functionality.

• Your local setup is likely different from production (not serving from production domains, not using image resize services, using different HTTP compression...)

• You might not be able to run tests on localhost, e.g. if you're an external consultant or working in technical SEO (who often want to give specific recommendations to devs as dev attention is scarce and expensive)

There are still some limitations of testing changes in DevTools:

• Testing a fresh load is a pain (need to clear OS-level DNS cache, need to clear the connection cache in Chrome, need to clear cookies/service worker)

• DevTools throttling doesn't represent server connections accurately (you need to throttle at the OS level for accurate data, which slows down your whole computer and requires admin rights)

WebPageTest [1] and my own tool DebugBear [2] now support experiments to make it easy to try out content changes in a controlled lab environment.

[1] https://product.webpagetest.org/experiments [2] https://www.debugbear.com/docs/experiments

It works well for me since I'm not allowed to export the production data onto my machine or testing environments for HIPPA reasons.

This is way better than reviewing an exception from obfuscated javascript (without sourcemaps) and trying to figure out where it occurred.

I think the key point is that by using overrides, he can basically implement a deployed change that uses production data, but without having any access or control over production infrastructure, and with no risk for other users.

Lots of folks have correctly pointed out that running locally is essentially a solved problem. He can do it against prod data, because he's overriding the prod configuration.

I've done exactly this for non-browser (and some browser) applications before (using local MITM proxies) but it's nifty that chrome lets you skip the certificate headaches and just loads a resource from disk.

How universal is the drive to try to keep others from making needless mistakes?

[1] "FCP is " +Math.round((fcp + Number.EPSILON) * 100) / 100

That said, 95% of my usual problems can be debugged with the console. Often it is faster, easier to grok and does not interrupt flow as much as a forgotten breakpoint would.

console.time, console.count, debugger; (breakpoint set in code) and $0 (code ref to highlighted html element) are super useful as well. Usually that is enough before manually setting breakpoints

also nice to know: Safari is great for (offscreen)canvas debugging

Because they suck. Afaik there is no way to setup triggers like

break if variable X created

break if variable Y >= 123

break before calling Z web api/method