4 ms·

WebStorm and VSCode both have OK debuggers, but in my experience they are even more finicky than the Chrome one, which as you noted does have issues. Firefox an

WebStorm and VSCode both have OK debuggers, but in my experience they are even more finicky than the Chrome one, which as you noted does have issues. Firefox and Safari are likewise fine, but not as good as Chrome. More importantly though, if you are that distrustful of Chrome, you probably should not be using Node because it is based on v8, the Chrome Javascript runtime.

qazxcvbnm 3y ago
There are basic things to be desired with the current state of affairs, beyond the trust of Google, such as: 1) ability to debug locally, without an Internet connection. 2) ability to debug reliably, without fear of debugger features becoming 'updated' when one needs it most. The fact that no independent debugger, without the Leviathan that is Chrome, exists, only hides this aspect even more, hardly doing justice to the importance of debugging in the practice of software. Regards to the Firefox and Safari debuggers, they do not seem to be viable in practice with the alternative Javascript runtimes mentioned, both very popular and widely used, which is the reason that I claim Chrome DevTools to be the de facto 'Javascript debugger'. Neither do the two tools offer a debugger independent of the browser, as far as I am aware.
- ntonozzi 3y ago
  Have you tried VS Code or WebStorm? They are both independent debuggers. They are quite good for debugging in my experience. I don't know that they offer profiling capabilities.
  - qazxcvbnm 3y ago
    I confess that such IDEs and their plugins are not my cup of tea and have not given them a fair chance. Though I am skeptical, with the many inconsistencies that runtimes present even for Chrome, perhaps they do work and I may give them a fair try. Still, unwilling tight coupling with an IDE is still quite unsatisfactory.
    - overgard 3y ago
      It's not really a tight coupling at all in VSCode's case. Open your folder, let it generate a small launch.json in a hidden dot directory, and that's basically all there is to it. It's not like some heavy Java/C++ kind of thing where you need some massively complicated build system and project file.
  - sequoia 3y ago
    @qazxcvbnm I don't understand: you don't want to use the chrome debugger but also don't want to use an IDE debugger... it's not clear what would meet your needs and wants, you're rejecting all the main options. Here's an overview of some of the tools in case that's useful: https://sequoia.makes.software/debugging-nodejs-talk/#55 https://sequoia.makes.software/debugging-nodejs-talk/#55
    - qazxcvbnm 3y ago
      I reject the main options for the reason that the main options are unsatisfactory. Your link lists the Chrome debugger, IDE debuggers, and the node inspector. The node inspector is essentially deprecated. IDE debuggers more or less piggyback on the Chrome DevTools protocol, and although I mentioned I have not given them a fair try, but they definitely seem less official, featureful, and well-supported compared to the Chrome debugger. The fact is, this aspect of Javascript seems to have, unceremoniously, already fallen into Google's sole leadership, direction, and discretion, by force or by will. The Chrome debugger, as mentioned, exists and is probably the most well supported of all debuggers, and is what I use in practice. However, as I mentioned, even 'the best', which is Chrome, does not work very well, exhibits usability regressions per the cadence of Google (e.g. blackboxing used to work, but is very broken today), and moreover compromises basic functionality and freedoms, which comprises my dissatisfaction. In a better world, we would have something that is native to the language (not a browser), versionable, free, featureful (e.g. profiling and memory debugging), and accessible from the shell (e.g. other languages have gdb, pdb). It would be a good thing for a protocol to actually have multiple implementations. Something that may at least recover basic functionality from the Chrome DevTools would be to degoogle it for hermetic usage, and separate it from the browser proper. As I mentioned, I am looking forward to make that happen.

qazxcvbnm 3y ago

There are basic things to be desired with the current state of affairs, beyond the trust of Google, such as: 1) ability to debug locally, without an Internet connection. 2) ability to debug reliably, without fear of debugger features becoming 'updated' when one needs it most. The fact that no independent debugger, without the Leviathan that is Chrome, exists, only hides this aspect even more, hardly doing justice to the importance of debugging in the practice of software. Regards to the Firefox and Safari debuggers, they do not seem to be viable in practice with the alternative Javascript runtimes mentioned, both very popular and widely used, which is the reason that I claim Chrome DevTools to be the de facto 'Javascript debugger'. Neither do the two tools offer a debugger independent of the browser, as far as I am aware.

ntonozzi 3y ago
Have you tried VS Code or WebStorm? They are both independent debuggers. They are quite good for debugging in my experience. I don't know that they offer profiling capabilities.
- qazxcvbnm 3y ago
  I confess that such IDEs and their plugins are not my cup of tea and have not given them a fair chance. Though I am skeptical, with the many inconsistencies that runtimes present even for Chrome, perhaps they do work and I may give them a fair try. Still, unwilling tight coupling with an IDE is still quite unsatisfactory.
  - overgard 3y ago
    It's not really a tight coupling at all in VSCode's case. Open your folder, let it generate a small launch.json in a hidden dot directory, and that's basically all there is to it. It's not like some heavy Java/C++ kind of thing where you need some massively complicated build system and project file.
- sequoia 3y ago
  @qazxcvbnm I don't understand: you don't want to use the chrome debugger but also don't want to use an IDE debugger... it's not clear what would meet your needs and wants, you're rejecting all the main options. Here's an overview of some of the tools in case that's useful: https://sequoia.makes.software/debugging-nodejs-talk/#55 https://sequoia.makes.software/debugging-nodejs-talk/#55
  - qazxcvbnm 3y ago
    I reject the main options for the reason that the main options are unsatisfactory. Your link lists the Chrome debugger, IDE debuggers, and the node inspector. The node inspector is essentially deprecated. IDE debuggers more or less piggyback on the Chrome DevTools protocol, and although I mentioned I have not given them a fair try, but they definitely seem less official, featureful, and well-supported compared to the Chrome debugger. The fact is, this aspect of Javascript seems to have, unceremoniously, already fallen into Google's sole leadership, direction, and discretion, by force or by will. The Chrome debugger, as mentioned, exists and is probably the most well supported of all debuggers, and is what I use in practice. However, as I mentioned, even 'the best', which is Chrome, does not work very well, exhibits usability regressions per the cadence of Google (e.g. blackboxing used to work, but is very broken today), and moreover compromises basic functionality and freedoms, which comprises my dissatisfaction. In a better world, we would have something that is native to the language (not a browser), versionable, free, featureful (e.g. profiling and memory debugging), and accessible from the shell (e.g. other languages have gdb, pdb). It would be a good thing for a protocol to actually have multiple implementations. Something that may at least recover basic functionality from the Chrome DevTools would be to degoogle it for hermetic usage, and separate it from the browser proper. As I mentioned, I am looking forward to make that happen.