I am forced to use VSCode for extension-based reasons, but have Sublime Text installed as well that I can very occasionally use. The difference each time is staggering, like a slap in the face. Scrolling smoothness, input latency, snappyiness to jump between files, or search workspaces. Each time it's so obvious. It's just so much more pleasant. Like going from being hunched over a tiny laptop screen to sitting in front of an all encompassing ultrawide, or going from an old laptop to a new desktop.
It doesn't mean that VSCode is an unusable pile of garbage, just as a tiny laptop screen isn't unusable. But the difference, at least to me, is undeniable.
Take my example with an ounce of saltt as I've never coded a VSCode extension. It is very well possible that the extension API prevents this particular example. I guess normally things like parsing source files have to follow guardrails that prevent this kind of bug, or at least discourage coding this way. And ASTs are exposed by VSCode's core for the natively supported languages.
Still, it's probably safe to assume that there is a lot of badly written code out there that does not pay attention to performance, or follows an "optimize-later" mindset.
Features surely often seem tempting to implement in a slow and unoptimized way, and anyone can contribute to VSCode extensions.
It’s not VSCode’s fault ;)
JS-based apps happen to interact terribly with nannyware for some reason. I see it every time I run one of our node services, everything just grinds to a halt while the antivirus freaks out about how dare I run a piece of uncompiled code.
Slack and friends have the same problem. Discord actually runs better in a browser than as a standalone app.
A half-wild guess here is that because viruses uses various ways to hide themselves the anti-virus software probably scans W^X codepages on changes, so anything JIT compiled (all modern JS engines) will trigger a lot of spurious scans (kinda like how compiling and writing .exe files can grind turnaround times to a halt).
I mean, yeah.. because they're slow and resource intensive. Your comment directly contradicts itself: It IS VSCodes fault.
And BTW, it doesn't have anything to do with "nannyware". They slow down on any computer that is under the tiniest load.
I think a lot of people don’t notice the difference but I can’t un-notice it.
Huge generated files and whatnot, VSCode just spins but Sublime opens them instantly.
Not to knock VSCode: it’s amazing what they’ve done especially comparing it to other web-stack apps (like what is Slack doing that it’s slower than VSCode with 6 extensions running?!).
Even when things are running smoothly, the just-perceptible delay in switching files or a slight stutter scrolling feels like the digital equivalent of working with a cheap tool.
The cheap ratchet is a little sloppy and occasionally the pawl doesn’t catch but it still does all the same stuff. Yet Snap-On still has customers.
I'm working on a large Dart project and a long time ago someone thought that having the project split up into 100 packages would be a great idea (it's not).
My previous editor was IntelliJ as I am used to its keyboard shortcuts, but it struggled with our setup: constant freezes and even if it didn't freeze, it would take seconds until the suggestions came up (or when I wanted to rename a local variable, smh).
I was so frustrated by it, that I installed helix, it was fast so I'm now learning to use it as my daily driver.
I have now both open, doing my editing on helix, and if I feel like I can go something faster in IntelliJ (which now happens less and less often), I do that little thing in IntelliJ and come back to helix.
Why helix: it's "great by default" and I didn't have much success with setting up and customizing NeoVim (it didn't feel good, the plugin were annoying to learn, and it started to slow down). I'm sure it a skill issue, but helix just works for me, and I can live without plugins for now.
Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition between panes and such. Even just scrolling with nvim keybinds feels a bit off. My key repeat rate is fairly high, and I’ll hold down ^D to skim through a source file. VSCode’s renderer struggles to keep up smoothly sometimes.
This is all nitpicky stuff, not enough for me to swear off VSCode or anything. But it’s just annoying enough that every once in a while I end up in some rabbit hole of VSCode internals and css tweaks, instead of doing actual work. Most coding does not require a ton of bouncing around, but it does feel very liberating to have confidence in my inputs as I navigate around.
For avoidance of any doubt, I care deeply about my editor latency and agree that those terminals who claim to be "fast" and yet only care about average--not even common--throughout instead of latency misunderstand the problem space... and yet, I still can't say that it is reasonable to lose "confidence in your inputs" if a system is merely slow to process without losing any of your events. If an editor drops any of my inputs at all ever I 100% lose all confidence in what I'm doing; but if it always works then I can close my eyes and still use it without issue!
Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)
With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.
With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.
(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)
Unfortunately, for this use-case, neither Zed or Laplace will likely to fill the gap, as they rely only on LSP as Neovim. That's also my issue with both: They should focus more on providing features to support coding, not just speed.
(Though I like the attempt at an analogy and I see how it works for you at least)
I am a high-action player —- I know I know, a monster! (but also a brass and heavy glass slide player)
Better showcase on how ridiculous the tech stack is would be to open a 500 line file with a code and scroll. Startup isn't great either, though it isn't comically bad as it used to be.
So yeah, I want to see the authors of any desktop software to address this modern problem of writing slow UI. Otherwise I might assume they don't care.
Last time I've tried Idea/etc was quite a few years ago. It didn't feel great. But maybe I should force myself into it. Might be better on M1.
I also open regular Visual Studio every few months for C# on Windows, and while it's slow to start, the editor feels really solid, quick, and responsive.
I get mad at this attitude from some companies. It’s like telling a carpenter that they have to build a house, but are not allowed power tools. It makes no sense.
Edit: typo
This in turn puts departments at odds, as their argument for speed is turned into an argument against security, which is a very hard position to be in if your department is a few layers down the corp stack.
Ideally, most programmers should be in IT or have some kind of alignment with IT and able to give some pushback about this during CAB for instance, and/or get some exceptions but that is increasingly difficult the more 'agile' an organization becomes and the more it seeks to silo infrastructure people from application people. A good IT department imo is one that doesn't do this and retains a more traditional culture where programmers are part of IT and able to actually influence the technical direction of the company, not just be treated like a product factory for business units.
Just from personal experience working as a programmer on the infrastructure side...complaining about windows sysadmins was the favorite past time of probably the majority of higher tier IT employees. It makes our jobs incredibly difficult for the same reason it makes application developers jobs difficult.
On the other hand, you'd be surprised by just how many career programmers are completely inept at sysadmin work and have no sense for security (nothing like CI pipelines using personal credentials and committing keys into public repos), so just letting all programmers do whatever isn't a great policy either...
I'm not saying it isn't valid criticism but I guess the way I work with an editor just isn't the same as others who experience this.
Would you consider something like emacsclient's approach - a daemon running in the background that a window connects to?
I navigate with the trackpad on a Mac and seem not to ever feel it, but I know others do not like this way of working, which is fair enough.
Lapce is interesting to me for other reasons: it is one of the few[0] GUI text editors with a remote dev option that matches what VSCode can do. And it might have a smaller footprint on the remote machine/in the container while doing it.
VSC’s remote dev support is very nearly non-negotiable for me now, so I say more power to them; I intend to try it again properly soon.
[0] there is another editor that was mentioned here recently that can achieve this with a plugin, but I forget the name
Update: Zed is that editor.
Absolutely. How new/fast is your developer machine? A lot of developers are working on computers that are several years old and may not have been that high-spec to begin with. It's generally not basic editing that's slow on it's own. It's trying to run several editor windows at once (say a frontend and several backend services) along with all the other things required for work: the project itself, compilers, video calls, etc.
As a reference point my 2015 MacBook Pro struggled with VS Code + Google Meet at the same time.
If programming in Rust on a medium-to-large project, you might be waiting minutes for your editor to finish checks to highlight compilation errors every time you save. That was me on a Rust project last year when I was trying to program on a 2019 macbook air with 16GB of RAM and 1.1 GHZ quad-core intel processor. Typical wait times to check what I'd written would be 30 seconds to just over a minute. It was excruciating.
I finally demanded the employer set me up with a cloud VM that I could use when working with that codebase, as the network lag with VS code opening the project remotely was so much more tolerable
A bunch of my friends tried it, and it was really interesting to see that many of them were not bothered in the slightest by even quite high latency numbers.
Personally, I was mildly bothered by the "single frame of latency" example and _intensely_ bothered by all the higher numbers. It just felt really yuck to use; I would hate to be doing that all day.
I can't tell you what exactly it is, but yes: the world contains many developers going crazy with frustration - not because of a 30 second wait, but because of a 30ms render delay.
You don't know you need it but once you have it it's hard to go back.
This extensibility is probably what made VSCode popular though, especially for web devs since the extension mechanism is JavaScript-based.
Makes me wonder if those Rust-based tools (Lapce, Zed) will have as much success with Rust-based extensions authoring.
a good example is magit on emacs, magit seems great, and i really want to learn it and use it, but its very slow (at least on windows its slow enough to make you unable to practically use it)
in short, speed changes everything
"Speed" is probably the wrong word, it's latency that matters.
So yes. These two are THE editors for me.
I only deviate from these when I need to do Delphi / Freepascal development.
Notepad++ / Notepadqq are being used as in place hotkey invoked text editors.
I still try new ones out of curiosity but I have hard time understanding why any would succeed. How they're going to get the same amount of extensions / plugins in order to match functionality?
Several times I have been on the brink of trying out spacevim for java development , out of pure frustration but the amount of config and tweaking needed scares me. I don't need much, lightning fast auto complete, auto import and Google code formatter integration. One of these weekends I'll bite the bullet I think and set it all up.
Yes, it breaks workflow and is incredibly slow.
Just like refreshing elements in UI shouldn't take multiple seconds, or a webpage shouldn't take multiple seconds to load on a good connection.
But also 10k line file should be nothing for a modern PC.
there is no convenient way for me to 'plug-in' the responsiveness of something like vim or emacs into vs code.
to be clear : responsiveness is things like opening a context menu of any kind, switching contexts, text drawing and blanking ; just things that add up to create a quick feeling piece of software. vs code/atom/whatever and other 'larger' graphic-heavy text editors feel slow.
A few ms of noticeable latency here and there, a few hundred ms freeze every once in a while, it's maybe an extra minute per day in clock time. If it was just a 1 minute startup penalty, that would be different. But this 60,000 ms is split up throughout the working day into hundreds of small pauses, making the system feel laggy and unpredictable. If you're lucky, it's merely a subconscious drag on your attention. If you're unlucky it will, have you constantly breaking concentration to wonder "is my editor frozen? Oh wait, never mind." Hundreds of times a day.
Now contrast that to a text editor with literally zero instances of noticeable lag. It's not that it has zero latency, it's that the I/O latency on modern hardware is faster than our fingers and eyes can work. So we don't experience it.
Hundreds of noticeable pauses versus zero pauses. Once you cross the threshold below which our fingers type and brain can read, you're lag free. Getting a faster text editor doesn't just slightly improve the lagginess, it completely solves it.
I'm a Rust fanboy, so not dunking on Rust. Just an observation.