> running all sorts of processes in the background (at least one terminal, language servers, type checkers, linters and formatters, possibly extensions, etc.)
That's a terrible excuse.
Your terminal is a separate process and should not affect how the editor itself feels. The language server exists out of process. The linters / type checkers exist out of process. (Or at least shouldn't block the main interaction/GUI thread) If those things make editing slow, either the design or the implementation is bad.
Sublime text runs the same stuff for me and works much faster than vscode. No excuses.
This is an example for context. We've got 3 cases: Obsidian (non-ide/electron/fast), vscode (ide/electron/slow-ish), sublime (ide/non-electron/fast). My point was that neither the electron not the ide part is an excuse for vscode not being responsive, because we've got counterexamples for each.
That's a terrible excuse.
Your terminal is a separate process and should not affect how the editor itself feels. The language server exists out of process. The linters / type checkers exist out of process. (Or at least shouldn't block the main interaction/GUI thread) If those things make editing slow, either the design or the implementation is bad.
Sublime text runs the same stuff for me and works much faster than vscode. No excuses.