Because competition is good, I want to quickly name-drop VS Code here, which has had _excellent_ integrated node debugging for quite a while now. It integrates seamlessly with the entire tool ecosystem (eg I use ts-node-dev for autoreloading + typescript support, and the VS Code debugger Just Works). And because it's inside the editor, ndb features like the ability to put breakpoints in a file before it is required are irrelevant. It's all at your fingertips, just put a breakpoint right where you're coding, hit F5 to attach the debugger to your devserver and step through the code.
It's a pretty amazing experience, finally putting Node at the same level as, say, PHP with XDebug and NetBeans in 2006. Of course reloads are still slower, but that's all. JS is getting there!
WebStorm (and everything in the IntelliJ family) also has a really nice debugging experience. Very similar benefits to what you described: it mostly Just Works, at least for my use cases, and you just add breakpoints to where you're already coding rather than needing to do things in a separate window.
That said, with both VSCode and WebStorm, I've seen finicky issues from time to time, like source maps not working right or trouble getting it to work with non-trivial test suites. For example, my company's test suite uses a wrapper CLI that pre-loads certain files and sets environment variables in a specific way, and I need to replicate that configuration manually in order to run tests from WebStorm. I'm certainly excited to see ndb as a "baseline" great experience that everyone can use, regardless of editor.
Sadly I find IntelliJ to be the worst editor I've ever seen. Slow, weird shortcuts, graphics problems, focus stealing. The downsides are so bad that it almost negates it's benefits.
Unfortunately, for Salesforce development the alternative is VSCode with subpar plugin (and tons of features blatantly stolen from independent IJ plugin developer)...
Performance can be improved by disabling plugins you don't use, disabling features like code folding, etc. and finally by excluding non-essential files from indexing.
I don't know about the graphics problems but you can disable focus stealing in your window manager. During the first time setup you are given the option of using other keys. For a vim-like experience you can use IdeaVim.
For node, IntelliJ gives you: code completion across files, debugging (local, remote, including Docker), testing (e.g.: automatically recognizes test cases and creates a run configuration from them), code coverage, type inference from JSDoc documentation or flow, linting, version control integration with excellent blame integration, etc.
Wow that was a lot of plug-ins to disable. Took me a while. It's shocking how they left enabled by default.
> disable focus stealing in your window manager
Can you expand more on this. Two issues I have is:
- Launching IntelliJ and another app simultaneously would pop IJ on top. Very indicative of how Windows platform works. Basically not an issue as I launch it like once a month.
- Saving/building something would switch focus to Messages panel. Clicking on item in project view opens a file, but typing still happens on project view panel...
I've actually run into different focus issues, stuff involving WebStorm multiple project windows on Mac and the wrong one getting focus.
For focus within the editor, I've been pretty happy, but it does take a little learning to get a feel for the keyboard shortcuts. Quick rundown on focus, at least on Mac (other platforms/keymaps are mostly similar, I think):
• Cmd+1, Cmd+2, Cmd+3 etc focus and toggle the different panels.
• Wherever you are, Escape gets you back to the code. Shift+Escape closes the focused panel and moves back to the code.
• Option+Tab switches between code panes.
• Whenever you open code from any panel, Enter will open the code and leave focus on the panel, and Cmd+Down will open the code and move focus to the code.
I find it easy enough to switch focus that even if an action ends up in a focus state I don't expect, it's just a little muscle memory to move focus to what I want.
wow i have never heard anyone say anything that bad about intellij! their support is actually fantastic. if you find a bug, report it. you'll probably see it fixed asap
I did not have that experience with IntelliJ. Bugs were everywhere, and during one of their product Beta cycles, they moved from Beta to release without fixing many of the problematic bugs I had reported!
I'm not a fan. Webstorm (along with its Intellij cousins) is slow, occasionally buggy, and has a horrid UX. Their subscription-based ransomware was long ago eclipsed by VS Code.
It's the same core editor with different pre-installed plugins, so I think criticisms of any of the JetBrains IDEs often apply to all of them. I have indeed seen slowness (depending on context), graphics issues, and focus issues in WebStorm, PyCharm, and others, but I still like them better than any other editor I've used.
Every language has its own implementation of code intelligence, though, so for different languages you might see significant differences in things like indexing time and the performance and quality of autocomplete.
That was always the core issue with Java for me. No matter how hard they tried to sell me that they finally fixed UI with Swing and whatnot, it always felt like Java apps lived in their own bubble, consumed massive resources and we're slow in general.
The best approach so far is Android and even then, I would say that the big difference between iOS and Android is precisely when the garbage collector kicks in and you get to see a phone with hiccups.
But of course, the Java language itself is loved by the academia as it conforms nicely to everything that is taught in proper architecture (even if it is verbose like no one)
It was for a while (and still is to a lesser extent) very common in pedagogy, though this was more a result of industrial popularity than any love from academia.
Ok I should have said was loved, because that was certainly the case for me. They loved explaining entity objects, factories and others in Java. But I think you are right as far as Python taking over.
I don't understand the downvotes for the comment though, jesus, it's like I insulted somebody's kid by giving my opinion.
Man, my experience with VS Code has been the polar opposite, especially WRT the "Just Works" description of the debugger. Some folks on my team rave about it, so I gave it a real shot, but it's just not workable for me.
Errors left and right from core JS functions. Unable to create temp directories, complaining that they already exist, and deleting those directories leads to complaints that they're missing. Running the exact same start command from the command line works smoothly, so I have to think it's some "magic" that VS Code is trying to do. I gave up and went back to IntelliJ.
I would say that decoupling the editor from the debugger makes debugging more accessible, since people can choose whatever editor they feel like using and still have a nice way to debug. That's a great thing, since I think a lot of people are intimidated by the amount of up-front setup and learning you need to get a really great debugging experience, and it's easier to maintain one debugging system than one for every editor.
On the other hand, integrating the editor and debugger certainly has more potential than keeping them separate. Switching back and forth between the ndb editor and your main editor is obviously not an ideal experience compared with having everything work in one editor, and IDE features like "click the play button next to the test (or equivalent keyboard shortcut) to run that specific test" or TypeScript-assisted navigation/autocomplete are things that I don't expect ndb to implement any time soon. Of course, ndb could implement these things, but then it's just becoming another editor rather than decoupling the two.
Using the disclaimer of 'because competition is good' then going on to point out how features are 'irrelevant' in comparison seems pretty biased and blasé.
I'm not a native English speaker. I forgot that "irrelevant" has a second snarky meaning until I read your comment.
I meant it literally. Ndb solves a problem that an integrated debugger doesn't need to solve because it already knows which files may be relevant, because the developer has them open. This holds for any integrated debugger and is not specific to either VS Code or Ndb. It's a fundamental integrated vs separate thing. I pointed it out because in my opinion, integrated is better exactly for these kinds of reasons (but you're free to disagree, to each their own).
All that said, I think you're quick to take offense, especially given that these are two projects by enormous tech giants. It is good that there's competition here. There's no poor nighttime voluntary open source dev that needs defending here.
FWIW, I'm a native English speaker and I didn't read "irrelevant" as snarky or negative. It just means that in VSCode, it's not a problem that needs solving, which is objectively true and not anything negative about ndb.
It somewhat blew my mind the other day that you can add an '--inspect' flag to a locally-run node instance and inspect it via Chrome (chrome://inspect).
After building a server for many months now, and relying on far too many console.log()s, this trick has enlightened me to the point where I feel as though I was a fool for not finding it out before!
Ndb looks like a promising improvement over this functionality and I'm excited to check it out.
Recently I discovered that you can flip to debug mode even on already running process without debug mode by doing 'process._debugProcess(<pid_of_process>)' on any other node process. This has made my life incredibly simpler by not having to remember whether I had run my app in debug mode with '--inspect' flag.
That sounds pretty cool actually... I have my --inspect flag baked into an npm command already, but I think I might just play around with that for fun haha
Had you any experience with breakpoint based debugging in the past in any environment? I'm always surprised when I run into someone who has never tried getting it going and has always relied on print statements.
To be clear, this was a genuine question. I have colleagues who generally develop software using log statements exclusively and I was curious about whether or not this was the parent's experience.
This looks really, really impressive. I'd love to connect this to Electron apps, too.
As someone who wants Windows users to have a decent time using and developing with Node.js, it warms my heart to see developers of modules to at least consider them. As the maintainer of `windows-build-tools`, it makes me so happy that more and more modules are including it as an installation instruction.
As a secondary language, I find the repl and debugging pieces far lacking for Node.js. To be fair, I just use Node.js for developing SPA using frameworks like VueJS and React.
Ndb looks like a step in a good direction. However, I don’t understand if you’re really expected to have a Chrome browser open when you’re already in the context of editing code.
That might sound strange, but my preferred setup is using tmux and splitting vim on the left and a couple terminal panes on the right (at about 80 chars). Is terminal debugging possible with ndb? Am I thinking about this wrong?
Agreed. I've been scratching my head over whether the rough debugging has been a lack of tools available, or me not knowing where to look. (From other comments, it looks like there are a few promising tools out there)
It's interesting to see Google build open-source tooling in this direction; catering to the developers ensures that Chrome keeps enjoying a large market share.
Google has made serious efforts here and as a web developer, Chrome's tools are by far some of the best I've seen (with an honorable mention to FX's tools for Flexbox & Grid).
You're right, you shouldn't let that overshadow the Chrome team's commitment to open source. You should maybe let the fact that Chrome is closed source overshadow the Chrome team's commitment to open source.
Yes, it's true that Chrome has closed-source components. Meanwhile, Chromium is still available. Node and Electron wouldn't exist without having Google's work to start off with, as a base for the work of many others. (Though of course Google was building on the early work at Netscape, and some features of web standards were invented at Microsoft, despite IE not being open source at all).
This way of building on the work of other people (hopefully giving due credit) is how open source is supposed to work. It doesn't mean Google can or should do everything for the community; if we don't like the direction Google is going we need to do some of the work ourselves.
I actually given that I have to deal with apps that should have been web based, but are not, 'cause dev convenience.
And having to untangle npm based builds to what used to be a simple set of scripts and HTML includes, because many JavaScript libraries assume a node based deployment and nothing else.
With those outcomes I do not consider it a good result.
Dart and NaCL (at least) are open source. People at Google do often try to change (they would say improve) web standards. This isn't inconsistent with supporting standardization, since the idea is that other browsers should implement the new features too.
Support for web standards doesn't mean always being a follower.
I don't know what the situation is now, but back when they were trying to push it toward standardization, NaCl was tightly integrated into the Chromium codebase with spotty public documentation. It would have been quite burdensome for other browsers to integrate and maintain, let alone for non-Google engineers to significantly contribute to and influence the direction of development.
Does this let me inspect network activity like I can with web apps? I currently use Charles Proxy for this because I haven’t found a better way to do this (also for Electron apps and network activity on the main process).
you know that's something i think i've always wanted but never realized until you just brought it up - something like the network tab from chrome dev tools would be super useful in any ide that caters to a language that people write web apps in (node/python/etc.).
to answer your question:
from the screenshot it looks like the answer is no
For those comfortable with python's pdb, this provides a similar interface for debugging node applications. I was hoping this was an improvement on that as I prefer to stay within the commandline.
This looks fantastic! My project has a build process that transpiles the source directory using Babel to a build dir, and then runs from that. Is it possible to use a sourcemap to debug based on the pre-transpiled source?
edit: i've built the sourcemaps, and like devtools, it is recognising them, but even though the source directory is in the working tree, it doesn't pick them up...
This might be a dumb question, but does anyone know how to "blackbox" the files that are not in working dir while debugging Node with VSC? I have a backend server that handle requests and often have to set a debugger, but find myself having to click through multiple "events_hooks.js" type of functions.
I never really understood how people are using a debugger these days, especially in a heavy I/O bound app such as Node.js services. I mean, once it hits the DB, there is no way of “stepping back”.
I used to use debuggers back when I was developing desktop apps on Java using Eclipse. It made sense to use a debugger back then cause the whole app was running locally inside the same execution stack, including its state and its business logic. You were in control of how the data flow and in which direction.
But nowadays, you have an API request with a short lifecycle which 90% includes handing the execution to other processes through the network. What is the purpose of using a debugger? You can just write an automated test that would automatically run on every file change.
We do something like this already but because we have three processes that interact we scripted puppeteer to hook into all three in different tabs and automatically refresh the tabs when the processes restart.
It also clicks into the console to start and turns off screencasting, etc.
We are dependent a lot on childprocesses (I know it sucks, but it's a legacy system) in our app. This is just amazing letting the debugger attach to the child process. Finally no more console logs to figure what's wrong.
It is indeed similar to Webstorm but it's free. For all the users out there who need an enterprise debugging experience for free without any annual fees, Ndb does the job really great imho.
Previously, you had to add a `debugger;`, visit "chrome://inspect/" in the browser, click "Open dedicated DevTools for Node", and leave it open while running node (mocha tests, in my team's case) from the CLI with --inspect. None of that is hard, and certainly it's much easier than previous alternatives, but it's still enough that it needs instructions. I got it set up for my team and made our test script print out those instructions, but even so, I think most developers viewed it as more of an "advanced" mode for when a test issue is really hard to track down.
With this new way, you run the test in debug mode and it pops up a window with everything set up already, no need for instructions. I'm hoping it'll make debugging easy/welcoming enough that more people will use a debugger as their default way to work on code.
At least in my situation, with no additional configuration, --inspect-brk works, but when it's paused at the start, I can't navigate to any of my files to set breakpoints, so the most straightforward way to set a breakpoint is a `debugger;` statement in the code. I guess that's one of the things that works better in ndb: "You can place breakpoints before the modules are required".
It's a pretty amazing experience, finally putting Node at the same level as, say, PHP with XDebug and NetBeans in 2006. Of course reloads are still slower, but that's all. JS is getting there!
That said, with both VSCode and WebStorm, I've seen finicky issues from time to time, like source maps not working right or trouble getting it to work with non-trivial test suites. For example, my company's test suite uses a wrapper CLI that pre-loads certain files and sets environment variables in a specific way, and I need to replicate that configuration manually in order to run tests from WebStorm. I'm certainly excited to see ndb as a "baseline" great experience that everyone can use, regardless of editor.
I’m not sure why you’d need to make the huge download of chromium via puppeteer just to use ndb. Sounds over engineered.
Node with —inspect can be directly connected to normal chrome browser. It’s very simple jsonrpc protocol over websockets.
Unfortunately, for Salesforce development the alternative is VSCode with subpar plugin (and tons of features blatantly stolen from independent IJ plugin developer)...
I don't know about the graphics problems but you can disable focus stealing in your window manager. During the first time setup you are given the option of using other keys. For a vim-like experience you can use IdeaVim.
For node, IntelliJ gives you: code completion across files, debugging (local, remote, including Docker), testing (e.g.: automatically recognizes test cases and creates a run configuration from them), code coverage, type inference from JSDoc documentation or flow, linting, version control integration with excellent blame integration, etc.
> disable focus stealing in your window manager
Can you expand more on this. Two issues I have is:
- Launching IntelliJ and another app simultaneously would pop IJ on top. Very indicative of how Windows platform works. Basically not an issue as I launch it like once a month.
- Saving/building something would switch focus to Messages panel. Clicking on item in project view opens a file, but typing still happens on project view panel...
For focus within the editor, I've been pretty happy, but it does take a little learning to get a feel for the keyboard shortcuts. Quick rundown on focus, at least on Mac (other platforms/keymaps are mostly similar, I think):
• Cmd+1, Cmd+2, Cmd+3 etc focus and toggle the different panels.
• Wherever you are, Escape gets you back to the code. Shift+Escape closes the focused panel and moves back to the code.
• Option+Tab switches between code panes.
• Whenever you open code from any panel, Enter will open the code and leave focus on the panel, and Cmd+Down will open the code and move focus to the code.
I find it easy enough to switch focus that even if an action ends up in a focus state I don't expect, it's just a little muscle memory to move focus to what I want.
Every language has its own implementation of code intelligence, though, so for different languages you might see significant differences in things like indexing time and the performance and quality of autocomplete.
The best approach so far is Android and even then, I would say that the big difference between iOS and Android is precisely when the garbage collector kicks in and you get to see a phone with hiccups.
But of course, the Java language itself is loved by the academia as it conforms nicely to everything that is taught in proper architecture (even if it is verbose like no one)
I don't understand the downvotes for the comment though, jesus, it's like I insulted somebody's kid by giving my opinion.
Errors left and right from core JS functions. Unable to create temp directories, complaining that they already exist, and deleting those directories leads to complaints that they're missing. Running the exact same start command from the command line works smoothly, so I have to think it's some "magic" that VS Code is trying to do. I gave up and went back to IntelliJ.
On the other hand, integrating the editor and debugger certainly has more potential than keeping them separate. Switching back and forth between the ndb editor and your main editor is obviously not an ideal experience compared with having everything work in one editor, and IDE features like "click the play button next to the test (or equivalent keyboard shortcut) to run that specific test" or TypeScript-assisted navigation/autocomplete are things that I don't expect ndb to implement any time soon. Of course, ndb could implement these things, but then it's just becoming another editor rather than decoupling the two.
Besides making the damn thing working, it was slow as fudge.
In comparison, recently I switched to JS/node ecosystem - everything was just working.
Node with vscode was incredibly easy. I'm not sure I see the comparison at all.
Never got my JS debugging up to that quality.
I meant it literally. Ndb solves a problem that an integrated debugger doesn't need to solve because it already knows which files may be relevant, because the developer has them open. This holds for any integrated debugger and is not specific to either VS Code or Ndb. It's a fundamental integrated vs separate thing. I pointed it out because in my opinion, integrated is better exactly for these kinds of reasons (but you're free to disagree, to each their own).
All that said, I think you're quick to take offense, especially given that these are two projects by enormous tech giants. It is good that there's competition here. There's no poor nighttime voluntary open source dev that needs defending here.
After building a server for many months now, and relying on far too many console.log()s, this trick has enlightened me to the point where I feel as though I was a fool for not finding it out before!
Ndb looks like a promising improvement over this functionality and I'm excited to check it out.
As someone who wants Windows users to have a decent time using and developing with Node.js, it warms my heart to see developers of modules to at least consider them. As the maintainer of `windows-build-tools`, it makes me so happy that more and more modules are including it as an installation instruction.
Ndb looks like a step in a good direction. However, I don’t understand if you’re really expected to have a Chrome browser open when you’re already in the context of editing code.
That might sound strange, but my preferred setup is using tmux and splitting vim on the left and a couple terminal panes on the right (at about 80 chars). Is terminal debugging possible with ndb? Am I thinking about this wrong?
Google has made serious efforts here and as a web developer, Chrome's tools are by far some of the best I've seen (with an honorable mention to FX's tools for Flexbox & Grid).
This way of building on the work of other people (hopefully giving due credit) is how open source is supposed to work. It doesn't mean Google can or should do everything for the community; if we don't like the direction Google is going we need to do some of the work ourselves.
And having to untangle npm based builds to what used to be a simple set of scripts and HTML includes, because many JavaScript libraries assume a node based deployment and nothing else.
With those outcomes I do not consider it a good result.
It is not for lack of trying.
They just happen to have more dev love than MS, with the whole do no evil mantra.
Support for web standards doesn't mean always being a follower.
to answer your question:
from the screenshot it looks like the answer is no
https://user-images.githubusercontent.com/39191/43023843-14a...
[1] https://github.com/kdzwinel/betwixt
For those comfortable with python's pdb, this provides a similar interface for debugging node applications. I was hoping this was an improvement on that as I prefer to stay within the commandline.
edit: i've built the sourcemaps, and like devtools, it is recognising them, but even though the source directory is in the working tree, it doesn't pick them up...
In NDB I am on sources tab and I see dist folder highlighted (src also appears in the tree).
How does one "map the workspace under sources" (I tried right clicking - and I don't see a menu)
TIA
Try that (I haven’t yet) - let me know if it works out for you! I was just wanting something similar the other day and this is on my to-try list
I used to use debuggers back when I was developing desktop apps on Java using Eclipse. It made sense to use a debugger back then cause the whole app was running locally inside the same execution stack, including its state and its business logic. You were in control of how the data flow and in which direction.
But nowadays, you have an API request with a short lifecycle which 90% includes handing the execution to other processes through the network. What is the purpose of using a debugger? You can just write an automated test that would automatically run on every file change.
It also clicks into the console to start and turns off screencasting, etc.
Here's a gist of the main part: https://gist.github.com/natew/66515fb49d895315e139059302cd47...
Anyone that wants to invest their career doing tooling needs to target enterprise customers.
Previously, you had to add a `debugger;`, visit "chrome://inspect/" in the browser, click "Open dedicated DevTools for Node", and leave it open while running node (mocha tests, in my team's case) from the CLI with --inspect. None of that is hard, and certainly it's much easier than previous alternatives, but it's still enough that it needs instructions. I got it set up for my team and made our test script print out those instructions, but even so, I think most developers viewed it as more of an "advanced" mode for when a test issue is really hard to track down.
With this new way, you run the test in debug mode and it pops up a window with everything set up already, no need for instructions. I'm hoping it'll make debugging easy/welcoming enough that more people will use a debugger as their default way to work on code.