I don't know, I don't use intelliJ and I don't want to pay for webstorm. Somebody else probably knows.
Anyway I like how low-memory-on-the-disk and low RAM usage VScode is, so I probably wouldn't enjoy intelliJ and webstorm for those reasons. I felt like even sublime was too bulky for me. Maybe they're good for other people and that's fine, but vscode just ticks all the right boxes.
Well, then it's kind of a far stretch to claim vscode debugging is better than ANY other solution if you haven't tried them all. Not even the most popular once like webstorm.
Out of curiosity, what is the reason, you don't want to pay?
Is it your financial restriction or that there is something philosophical about sticking with free stuff whenever possible?
Once you figure that if anything makes your days better by spending $10 or so a month, not choosing the best tool for the job sounds simply dumb.
I have a friend who sticks with plain vim uncustomized because he doesn't want to deviate from the default in fear of not being able to seamlessly use other environment sounds utterly stupid wasting productivity for 99% of the time being on his own machine.
I'm all about paying for things that add value - I haven't been convinced webstorm will add value.
I am very fortunate in my means right now, but I come from a poor family, and spending money is emotionally trying for me. I gain pleasure from pushing my monthly expenses down as tight as I can. It seems melodramatic but paying for webstorm might just stress me out - I'd constantly feel a need to justify it, like when I tried subbing to World of Warcraft - I'd catch myself calculating fun per dollar. Euck.
Anyway I'm a simple front end dev so I don't think it's necessary for now. As I branch out into Python perhaps Webstorm's tools will add tremendous value, I have seen some cool stuff but I just don't need it for now.
I find them to be very complimentary. I switch between VSCode (for writing, code editing) and PHPStorm (refactoring, debugging). Beyond webdev, VSCode offers excellent Markdown support. With auto-previews, custom styles, and many great extensions, it's worth installing just for the Markdown support alone. https://code.visualstudio.com/docs/languages/markdown
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.
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.
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.
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?
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.
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.
I wasn't aware it was possible to debug a running node server in the chrome browser until the addition of the 'inspect' flag in node 6. Maybe it was possible, I'm not superleet or anything.
