5 ms·

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

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!

RaycatRakittra 8y ago
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é.
- skrebbel 8y ago
  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.
  - alangpierce 8y ago
    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.
- sk_hazratali 8y ago
  http://www.sherekhudahazratali.com/2018/07/ye-kya-suna-maine-akhtar-raza-chal-diye.html http://www.sherekhudahazratali.com/2018/07/ye-kya-suna-maine...
verletx64 8y ago
There is IMO a lot of value in decoupling the editor from the debugger.
- alangpierce 8y ago
  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.
- seanmcdirmid 8y ago
  How are breakpoints re synced after a line adding/deleting edit occurs?
alangpierce 8y ago
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.
- dzhiurgis 8y ago
  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)...
  - sus_007 8y ago
    IntelliJ & Webstorm are two different IDEs manufactured for two different purposes.
    - alangpierce 8y ago
      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.
  - 8y ago
bogdanu 8y ago
Every time I tried xdebug with PHP I had an awful experience. Besides making the damn thing working, it was slow as fudge. In comparison, recently I switched to JS/node ecosystem - everything was just working.
- dvlsg 8y ago
  I agree. xdebug was one of the worst debugging experiences I've ever had. Node with vscode was incredibly easy. I'm not sure I see the comparison at all.
  - k__ 8y ago
    I used xdebug somewhere before 2011 and found it really good. Never got my JS debugging up to that quality.
thanatos_dem 8y ago
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.

RaycatRakittra 8y ago

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é.

skrebbel 8y ago
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.
- alangpierce 8y ago
  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.
sk_hazratali 8y ago
http://www.sherekhudahazratali.com/2018/07/ye-kya-suna-maine-akhtar-raza-chal-diye.html http://www.sherekhudahazratali.com/2018/07/ye-kya-suna-maine...

verletx64 8y ago

There is IMO a lot of value in decoupling the editor from the debugger.

alangpierce 8y ago
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.
seanmcdirmid 8y ago
How are breakpoints re synced after a line adding/deleting edit occurs?

alangpierce 8y ago

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.

dzhiurgis 8y ago
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)...
- sus_007 8y ago
  IntelliJ & Webstorm are two different IDEs manufactured for two different purposes.
  - alangpierce 8y ago
    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.
- 8y ago

bogdanu 8y ago

Every time I tried xdebug with PHP I had an awful experience. Besides making the damn thing working, it was slow as fudge. In comparison, recently I switched to JS/node ecosystem - everything was just working.

dvlsg 8y ago
I agree. xdebug was one of the worst debugging experiences I've ever had. Node with vscode was incredibly easy. I'm not sure I see the comparison at all.
- k__ 8y ago
  I used xdebug somewhere before 2011 and found it really good. Never got my JS debugging up to that quality.

thanatos_dem 8y ago

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.