Nice article, but applies to a world that nobody lives in anymore. 😔
Try an example written in TypeScript, put it through a complier, than through a bundler, then inject into live development env via hot reload tools. This makes debugging via DevTools more difficult that injecting simple console.log() into the codebase.
There is a way to join both worlds though. The debugger; keyword. It will drop you into debugger right where you want it, without digging through all these panels with obfuscated code. And being it a language keyword, you can make it conditional easily with if (way easier than DevTools conditional traps).
Source map is all you need.
I don’t think anyone will put debugger statements in production either
Does anyone put source map in production, though?
And on dev, source map is not a panacea - it does not translate 1:1 to the compiled code, which makes setting traps even more difficult. Also work horribly with code injected in live dev through eval().
No you won’t put source maps in prod, but in test or uat where it’s close to prod, but I don’t assume you put console.log in prod either, or wait for how many minutes your build will take for each debugging session
There were times I did put console.log() (or equivalent) to production - to debug a particularly difficult bug, that only appeared on production for very specific users. We managed to finally track the bug by log analysis.
I had the same thought when reading the article - when I am debugging a TypeScript-based app, the breakpoints are often not very useful. console.log() is crude, yes, but gets the work done.
You can connect your browser to vscode for example and with sourcmaps you dont even need to debug in the browser but in your Editor/IDE directly :)
This is so cumbersome, that I've never seen anyone actually doing this in real work.
i (have to) do this and yes, it's a PITA.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.