>It works by saving a copy of the page you're working on (or any other resource, like a JavaScript or CSS file), letting you edit that, and then serving that file instead of the live version.
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.
>1. You can already set up a local host on your machine to run tests. I thought that was standard practice.
Yes, run your own local server. You used to be able to just save local copy and click on it. Chrome killed this, now you have to run your own infrastructure even when all you want is testing one letter change.
Local overrides are super useful for testing site speed:
• 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.
Ok - I think this article pitches the wrong thing (or at least buries the lede).
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.
I find it most handy for debugging, especially if you've got the sourcemaps available (infinitely easier without minified code though). In that sense the developer console is an underutilised tool when trying to nail down problems, especially in highly stateful SPAs and I tend to use it as a REPL before I start putting pen to paper in my editor. So much easier than trying to create the ideal state locally if you already have it handy somewhere else.
Although I notice in general that this style of development (or its close friend REPL-driven development) is hard to teach for people heavily accustomed to print debugging or even TDD.
The snippet for fetching performance numbers is useful but it's cargo culting (ie, using incorrectly and needlessly) Number.EPSILON [1], besides not using the built in toFixed(2)
How universal is the drive to try to keep others from making needless mistakes?
I have coworkers who only use 2 of chromes debugging tools: the console and the network tab. They dont know about breakpoints, mapped typescript/react files, or local overrides. Every time they come to me with some issue they're facing, I have them set up breakpoints first before we do anything. Usually that's all that we need to do, and we figure out the problem in about 5mins
I usually recommend chrome dev tools to newer colleagues by saying that they are probably the dev tools with the biggest budget. No idea if I am right but so so many features.
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
In my humble experience, I know about them, yet I still never use them, I find it infuriatingly confusing to work with. The only time I've ever liked breakpoints and regular debuggers is when working with C, anything else feels off to me.
On a tangent, it is weird sometimes that people not always pick the right tool for the job, even if the effort is small and the results pay off immediately. Like slicing carrots using a potato knife or even a table knife.
You are right. But what I wanted to say is, some people stick to very basic tools, even after you show them more convenient tools like a sharp knife with a firm handle and a knife sharpener. Often the switching part of the process seems to big of a hassle.
Chrome dev tools are an engineering marvel; the downside is it’s quite hard to find the perfectly shaped tool.
I spent about a week tracking down a memory leak in our web app. About 5 days in I discovered you could compare heap snapshots which led to the root cause of a chrome bug with hidden classes. The fix was to move object spread to the bottom of an object literal.
If you'd care to list some of your most used - or most useful tools - I'd love to read it. I suspect that I don't even know about most tools available to web devs.
For what it's worth, I stick to server-side for most of my work. But occasionally I have to fix something on the front end - whether it be a UI issue in CSS/HTML or a real problem in Javascript. So a quick mention of those front-end tools available and what they do would be great. Thank you!
Not him but I use typescript with webpack. Webpack has webpack serve, which runs a simple HTTP server that shows an index.html for testing your script. It adds some file watchers on your source so if you make any changes it automatically compiles. Webpack will build the .map files so you can run breakpoints in your browser on the original source, but if you develop with vscode, you can create a launch profile which allows you to attach your vscode debugger to the browser and put your breakpoints in VSCode instead of the browser (which I prefer the UI for). This works with react as well
Thank you. I have been learning React lately (as a backend developer, I love it) and this will be helpful. I've considered using webpack or one of the competitors - there are so many that I've simply just avoided them until now.
line-of-code, cant set global ones, when I want to know if some object is used I need to manually hot patch/proxy it. One other drawback is inability to disable debug() call. Debugging third party/hostile code is real pain.
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.