virchau13

https://www.joshwcomeau.com/css/understanding-layout-algorit... is an article that could have easily been written without any interactive components. All the author did was replace traditional code blocks with an embed to a web playground (e.g. by s/Code/Playground/g in a MDX file). Ta-da, the demonstrations are immediately interactive.

> and thus will remain a minority.

Not if we put in effort to encourage them. On the other hand, if we put in effort to _discourage_ them (say, by splitting the web into documents without interaction and apps with interaction), they will disappear completely. It is not worth sacrificing these creations simply so that we can remove a few bad actors. (Mind you, there are many ways to act badly in non-interactive ways too. Image watermarks, embedded advertisements in videos, embedded advertisements in ASCII text...)

It's because of articles like this one, or 3Blue1Brown videos, that I feel like the idea of "the document web" is really a step backwards: the internet is not just a glorified transmission method for paper anymore. We have computers, which are able to do so much more than paper ever could. To not exploit them for their capabilities, simply due to fear of exploitation, is far worse. How much worse do you think https://thebookofshaders.com/ would be to learn from if it couldn't include live editable demnostrations? To divide up the web into "interactive" and "non-interactive" content is to remove the ability for creators such as the author of the Mechanical Watch article to add progressive interactivity to their documents, remove the ability for learning resources to fully utilize the power of computers, to remove the ability for small fun things to be added to sites such as a Konami Code easter egg or https://bruno-simon.com/'s interactive website. And before you reply with something like "these would all go on the interactive web", my point is that dividing the web like this would not only be pointless but would also be ultimately harmful to the creation of things such as these.

I personally find that both are good tools, but to know what you should be using, you need to think about which viewing angle you want to choose: which components of state do you want to inspect and which moments in time do you want to track? If the answer is "these specific state components/unknown" (e.g. "when is my program accessing invalid memory?"), that's where print debugging comes in, with specializations depending on which particular state components you're looking at (strace or eBPF for IO, valgrind for invalid memory accesses, etc.) If it's "unknown/these specific times" (e.g. "where is my program setting HTTP response headers when a request occurs?"), then a debugger is a good idea.

However, what you said does have truth to it. Good programming practices generally center around the management of program state* (using types, specifications, whatever). If your program is not designed well in those terms, then the more likely it is that you have no idea what state components you want to inspect, meaning you reach for a debugger first. And if it is designed well, you won't need a debugger nearly as often. But sometimes we have no choice, whether that's due to an inherently hard problem space or lots of bad code that we didn't write, so a debugger is necessary.

* I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)

[0]: A cool example of using them is https://www.brendangregg.com/blog/2021-08-27/slack-crashes-s....

[1]: https://www.sourceware.org/systemtap/