Make debugging guide documentation more beginner-friendly

[Floriferous]

Repost of nodejs/node#25257.

I wish I understood node debugging better, but the guide really does not help when you're not already deeply familiar with the ecosystem. Those people would happily skip through it anyways. I think it'd be helpful if it was a bit more beginner-friendly to help newcomers get productive faster.

To illustrate what I mean, here's the very first paragraph:

When started with the --inspect switch, a Node.js process listens via WebSockets for diagnostic commands as defined by the Inspector Protocol, by default at host and port 127.0.0.1:9229. Each process is also assigned a unique UUID (e.g. 0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e).

This is literally the Getting Started part, for noobs, but there is so much dense information packed here, that the useful bits for beginners are lost:

• I'm not sure beginners care that node listens via WebSockets to do this
• I have never heard of diagnostic commands before reading this guide
• Should I really follow the link to the Inspector Protocol, and skim it, to understand the first sentence of a getting started guide?
• Host and port is great information!
• Why should I care that each process is assigned a unique UUID in this very first paragraph? Why not mention it in some other "How it works" section?

This is my first issue on the node project, so maybe the goal of documentation here is not to be beginner-friendly, or have this kind of a tone, but it'd be immensely helpful if it was a bit more like this:

Any node process can be started with the --inspect flag, which automatically allows you to visit 127.0.0.1:9229/localhost:9229 that lets you debug node from a browser or client.

Example

Let's consider this node script:

// main.js
var a = 2;
var b = 0:

debugger; // Add a debugger statement in your node script or server

var c = a / b;

You can now start your script with node --inspect main.js and visit the debugging URL in your browser to debug your nodeJS code.

[Trott]

I wouldn't mind seeing us try to do less of that type of guide writing on the website and rely more on external resources to do that sort of thing, but that's just my opinion (which I will repeat when the issue is opened in that other repo!).

I like your suggestions/comments and wouldn't mind seeing them implemented. (Feel free to open a pull request if you are sufficiently motivated!)

I guess one other thing to consider is whether the guide has sufficient advantage over the debugging API docs. Admittedly, it only includes information about Chrome Dev Tools and not a plethora of other projects, but I might suggest that could be a feature and not a bug. Too many options in a getting-started situation could be less friendly than providing a single way. In other words, there could be a case for simply removing the guide. (I'm happy to let blogs, Medium, and other resources handle explanations for VS Code and so on.)

[ghost]

I'll close this because it's fixed at #1969. Anything important or urgent can be left here by re-opening the case.