6 ms·

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 profil

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.

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.