Ndb – An improved debugging experience for Node.js
github.com
github.com
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!
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.
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.
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.
Unfortunately, for Salesforce development the alternative is VSCode with subpar plugin (and tons of features blatantly stolen from independent IJ plugin developer)...
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.
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.
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.
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.
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.
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...
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.