I don't know why there are so many non-answers or flat out incorrect answers to your question.

Yes, js devs use debuggers and have for years. Firebug was created and popularized for browser js 10 years ago[1]. Node.js was released 7 years ago, got a debug option one year later using node debugger. It was CLI based and a bit shit. Tools which leveraged Node's debug protocol and Chrome's developer tools (node-inspector) for example were started 5 years ago[2]. Most recently some group associated (maybe on?) the Chrome team started creating a cleaner debug protocol and integrating directly with the Chromium project[3]. That's become the gold standard and is the standard way of debugging for Node 7+[4]. VSCode uses that protocol to offer debugging directly from the editor.

1. https://en.wikipedia.org/wiki/Firebug_(software)

2. https://github.com/node-inspector/node-inspector

3. https://github.com/nodejs/node/pull/9028

4. https://nodejs.org/api/debugger.html

It was console.log() all the way

The Chrome based dev tools have been an option for years using node-inspector. Had all of the basics that you would expect from a debugging. Breakpoints, step into/out/over, variables available at that location in the stack, REPL console etc.

It was kind of a pain in my experience to use the Chrome debugger to be your main editor. I've not used VSC for this, but I imagine it's nice to not have to flip back and forth between tools.

I was responding to the claim that it console.log was the only way.

You can't be serious.

printf-debugging is a fine way to debug a ton of cases, especially programs with concurrent components. The process of debugging step by step isn't necessarily superior or faster.

I'm not sure why not. AFAIK that's still your only option if you want to debug NodeJS code headlessly.

What about conditional break points, call stack, time travel, watch list, live editing, etc?

Wow, there are actually people using any of these?

More like all of these every day?

Running 'node debug script.js' will drop you into the command line debugger. It's a little painful though as the command line debugger does not have support for moving up/down stack frames.

I am pretty to the javascript/node world. The debugging situation is pretty pathetic in my view. Most people I know use a ton of logging like we did with C/printf 25 years ago.

Using awareness of how to use a debugger is a reasonable interview technique WRT javascript devs. In general, ignorance is not a pejorative but if a candidate walk into an interview claiming to be an expert and I find out that you debug in anger using console log, I'm calling bullshit. They're either very green or too lazy to have investigated the tools available. Jr devs are, obviously, another story. Read up on how to use node --inspect for newer versions of node or node-inspector for older versions.

One common need that is a sad state of affairs in the Node world is performance tooling. It's available and competent professionals should invest in it once it becomes necessary but is a pain in the ass to setup and run.

>In general, ignorance is not a pejorative but if a candidate walk into an interview claiming to be an expert and I find out that you debug in anger using console log, I'm calling bullshit.

Some of the best programmers advocate for printf over debuggers...

And some of the crappiest programmers run around the debugger for hours with no idea what could be wrong in the program, stepping blindly here and there...

To explain this further, I think printf is more focused and direct than running around in the debugger. You need to have a clearer idea of what you're looking for in advance and know how to exclude parts of the program as possible culprits, which I think helps with debugging in general.

And, come to think of it, with hot code reloading, printf can be just as immediate, but more direct and focused, than using the debugger. Shame that few languages/environments offer hot code reloading...

Using printf on everything is basically the same as debugger but a lot slower. People also tend to commit those added lines (sometimes commented for future uses) which clutters code base. I think that using permanent logs on higher verbosity plus debugger is a lot more productive.

It sounds like you are trying to sell lack of a debugger as a feature that forces devs to to be more aware and more precise. Then we should maybe go back to writing code on paper first, create punch cards, submit to the mainframe and get the result next day? Then you have an even better idea of what your program does.

Debuggers are a valuable tool that nowadays should be standard.

>Then we should maybe go back to writing code on paper first, create punch cards, submit to the mainframe and get the result next day?

Just because someone advocates taking a step back in some particular issue (and for specific reasons they argue about) doesn't mean it logically follows that they advocate going all the way back.

Two things: "slippery slope" fallacy and "marginal returns".

I'm pretty sure we can find some ways in which you yourself advocates NOT using some modern language feature in favor of an older practice (e.g. you might be against visual programming languages). Does that mean you are ultimately in the same "punch cars" camp as you suggest I am?

I agree. The best printf debugging I've seen is Mike Conley from Firefox Live Hacking. He has quite a few debugging tricks up his sleeve.

[1]: https://www.youtube.com/channel/UCTDXvmarLFnox4AO0w2NuiQ

As usual in this industry there is a whole new generation of devs coming up that have forgotten stuff that has been standard for a long time. Then somebody implements this old stuff for the new tech and people think it's major innovation. I am sure soon somebody will create a node profiler.

Sounds like a profitable model (introducing new devs to best practices).

You can debug in Chrome (or any other browser). For node, you can run node-inspector which uses a browser for debugging.

Some of us used debuggers way WAY back in 2002. Venkman was the new hotness: https://en.wikipedia.org/wiki/Venkman

Firebug quickly became the defacto later on. But telling your average web designer about breakpoints, stepping over and stepping into would cause their eyes to glaze over.

For client code I'd use the chrome debugger constantly. I mean for debugging a node server.

Maybe there was some way I didn't know about. There's the 'inspect' flag in node 6 now that prints out a link you can copy into your chrome browser to debug server node code.