site banner

Small-Scale Question Sunday for June 15, 2025

Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?

This is your opportunity to ask questions. No question too simple or too silly.

Culture war topics are accepted, and proposals for a better intro post are appreciated.

1
Jump in the discussion.

No email address required.

Anyone have particularly strong feelings about best (or worst) UI libraries? I spent a good part of the weekend trying to take a more serious attempt at familiarizing myself with Avalonia, but I'll admit user interface work is always something I've dabbled with rather than gotten a great understanding of, and at the dabbler's level a lot of great or terrible code gets completely buried by the strength (Visual Studio) or weakness (oh boy, QT!) of IDE-focused tooling, or the difficulty of entry (ia ia OpenGL fhtagn).

I’ll just note that anything Electron based is a crime against humanity and should be grounds for immediate execution without a trial.

VSCode is just the spiritual successor to emacs: it's an operating system in search of a good text editor.

I dunno, am I the only person who hasn’t noticed performance issues with VSCode? I keep myself to a pretty tidy set of plugins, and the thing lets me edit files just fine. I’m not running an overpowered rig or anything.

This is an open request for horror stories if anyone has them; they’re always good fun.

Most of the common complaints are about minimum memory and CPU footprint; VSCode takes comparable resources to run as far more fully-featured IDEs. But if you've got the specs these are unlikely to actually feel bad, it's just kinda goofy.

The biggest problems are pretty hardware-specific, but they've been pretty bad when they pop up. I've had VSCode pull 16+GB memory (especially bad on an 8GB-RAM system) or peg multiple threads at 100% core utilization just idling, all with the default configuration, no extensions. A lot of it seems very dependent on renderer, especially since it started defaulting to a hardware renderer even on Intel integrated GPUs, but sometimes 'normal' developer workstations with multimonitor configurations have gone really wonky. While a less common use case, I've seen bigger problems with massive files in VSCode than in VisualStudio, Intellij, Android Studio (which isn't great itself!), or NotePad++, sometimes to the point where I had to shutdown the computer because VSCode was capping out CPU utilization so high that I couldn't use the mouse or keyboard.

((I've also had problems with deployments of VSCode, rather than VSCode itself. Which, tbf, usually aren't even the Electron developers faults, but since it includes things like a 40+ GB electron update, it's still worth keeping in mind before committing to VSCode as a day-to-day dev environment.))

VSCode defends itself in many cases by pointing to issues with extensions, and to some extent that's fair: just as it's not the Electron devs fault that a distro screwed up once, it's not VSCoders fault that a random html/css extension can peg a cpu. You can't build a framework that can contain every sufficiently dedicated forkbomb without making it useless. But you're almost certainly going to need some extensions just handle basic compiling and debug functionality. And some of them are pretty bad! My worst experience have been with the Java variants, with high idle CPU utilization across the board, but that's mostly because VSCode is the 'officially supported' tool for FIRST FRC so I see it on a lot of different non-optimized hardware. I don't do much webdev, but the few times I've run into ESLint, even with a minimal ruleset and properly configured (why is apply-rules-on-typing even an option?!) it's been pretty painful.