Hacker News Reader

Comment by nxc18 | Hacker News Reader

If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it.

It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).

People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.

View on HN

using a js engine is anything other then a selling point IMO. I don't hate javascript but sure hate the ecosystem and the tendencies of js or ts developers today. I would not want that approach in my editor at all. elisp and js actually share some things in common and their is no reason a developer would struggle to learn elisp and once they do they will probably like it and the very light weight emacs rendering system, everything is text is a fantastic paradigm for a text editor or an IDE. web technologies like Html/js are actually too complex and can do things you don't actually want your editor to do when rendering bits of interface. I want text and nothing else and I want to hook into text renders easily and without having to worry about timings asyncs and other features of the modern web interface. It's that emacs is simpler and understands that one does not want everything a modern browser can do.

> But I don’t think it is meaningfully slower in practice

It's all relative and perceptional, no? It really irks me that when you grab a freshly installed VSCode and install just a single extension for vim-support, there comes a palpable typing latency. Just like that. I currently use about 300 packages in Emacs. I can't ever imagine even attempting half of this number of extensions in VSCode. Would it even start?

VSCode's problem isn't that it's slow, it's that it's bloated. It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.

I just tried opening a 730 MB file in both and VSCode's usage was just around 2 GB while Sublime's usage (fresh install) was over 3 GB. This is even with my normal VSCode extensions enabled (91 currently).

VSCode at least has the excuse of being a full web browser, explaining (but not justifying!) its bloat.

What's Sublime's excuse for needing 300MB to open a text file?

I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.

I do miss the configurablity though

What counts as large? There can be some perf issues if you don’t exclude node_modules and build outputs from search, but I’ve never seen it crash.

It was a mono repo with 30+ projects Most were react apps. I’m going to guess at least 5000 files in the repo.

And yes, node_modules was excluded.

I’m sorry you had a bad experience.

The monorepo I work in has 2-5x as large (depending on how you count) and I don’t see crashes or major performance issues. Even when bloated with plugins (testing, GitHub PRs, formatters, copilot, vim emulation, codelens turned on, etc). And I have an older presumably slower Mac.

I wonder what the difference is.

Reply on news.ycombinator.com