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