18 ms·

I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pre

I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server. Eventually all the little inconveniences wore on me and I switched back to VSCode. I will probably try it again after a few more releases to see if it feels better.

dijit 2y ago
Yeah, I agree about VSCode being sort of fast enough. Computers are getting faster and I’m on a M-series mac which makes web rendering much faster but still I feel like as far as electron apps go: VScode is basically the golden child. Slack & Teams on the other hand, ouch.
yoyohello13 2y ago
My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit. My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.
- whalesalad 2y ago
  but vscode is open source: https://github.com/microsoft/vscode https://github.com/microsoft/vscode and there are third-party builds from the community that disable things like telemetry: https://vscodium.com/ https://vscodium.com/
  - yoyohello13 2y ago
    Sorry, I should have been more specific and said FOSS. VSCode is still encumbered by the weight of a mega corp. It's like saying Chrome is open source. Sure it is, but it still exists to serve the corporation that owns it.
    - TiredOfLife 2y ago
      It's MIT licensed. So it's more FOSS than FOSS
      - correct-horse 2y ago
        It's free software in letter, but not in spirit. True free software doesn't lock out non-official builds for zero technical reasons.
        fragmede 2y ago
        what about vscodium? for that reason, what was iceweasel?
        nicce 2y ago
        There is some sort of vendor lock-in VSCode. It at least used to be extremely difficult to make GitHub Copilot to work with codium. There is something closed source in VSCode that makes the difference. It was so difficult to maintain, that I ended up switching to VSCode. So the ”lock-in” worked.
        janice1999 2y ago
        vscodium and VSCode forks are legally prevented from using the normal VSCode extension site. They have their own: https://open-vsx.org/ https://open-vsx.org/ As far as I know Chrome forks are not blocked from using extensions from the Chrome Web Store.
        n_plus_1_acc 2y ago
  - screcth 2y ago
    The problem is that many parts of the ecosystem require that you use the official MS build. You can't connect to the Marketplace and some extensions outright can't be used with a custom build.
    - vorticalbox 2y ago
      You can however down the extension from the website and install it from the terminal. codium --install-extension {path to .vsix}
      - KETHERCORTEX 2y ago
        You are able to do so, but is it allowed by the website's terms of service? It may say that you are granted the license to extensions only with Microsoft builds of vscode. Microsoft isn't a stranger to distribution restrictions and software usage limitations. I remember uploading Visual C# Express 2010 (freely downloaded from Microsoft's website, without license keys) to a local file sharing website to ease the downloading for my local study group and got a letter from Microsoft's lawyer to take it down. After that our study group transitioned to Mono with Monodevelop.
        whalesalad 2y ago
        Terms of service? Who cares.
        Arnavion 2y ago
        An actual example is that the Python LSP extension on the offical marketplace has some "DRM" that makes it pop up a fatal "You can't use this extension except with the real VSCode" error message. People have been playing whack-a-mole with it by editing the obfuscated JS to remove that check, or by using an older version from before they added the check. https://github.com/VSCodium/vscodium/discussions/1641 https://github.com/VSCodium/vscodium/discussions/1641
        KETHERCORTEX 2y ago
  - 0cf8612b2e1e 2y ago
    You mean except for all of the good plugins. Or the ability to use a custom plugin store. Last I read, the open builds struggled with removing all of the MS telemetry and some may still be leaking.
  - chx 2y ago
    https://ghuntley.com/fracture/ https://ghuntley.com/fracture/
- deleted 2y ago
  [deleted]
- kiitos 2y ago
  I, too, prefer to cut off my nose to spite my face.
  - yoyohello13 2y ago
    Yes, living by principles is inconvenient sometimes.
the_duke 2y ago
I think people just have very different tolerances for latency and slowness. I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it. I tried out Zed and it actually feels fast enough for me to consider switching.
- whalesalad 2y ago
  Sublime Text 3 is still one of my favorite editors. I use VSCode lately because of its excellent "Remote SSH" integration - but when it comes to latency sublime has it beat. Zed does not feel fast on my machine, which is a 13900K/128gb ram. It is running in xwayland though, so that could be part of the problem. It feels identical to vscode.
  - correct-horse 2y ago
    | It is running in xwayland though It definitely isn't on my system, and I did not touch the configs at all; are you sure about that?
    - whalesalad 2y ago
      Fairly positive due to blurry cursors, but I have no way to verify.
      - ndiddy 2y ago
        If you run xeyes and the eyes follow your cursor when it's above the application you want to test, it's running under xwayland. If they don't follow your cursor, the application is running under native Wayland.
        369548684892826 2y ago
        finally a use for xeyes?
MrJohz 2y ago
Yeah, this was mostly my experience. The Zed editor was fast, but it just felt like it wasn't as good as other editors. For me, the version control integration was particularly poor - it shows some line information, but diffing, blame, committing, staging hunks, reviewing staged changes etc are all missing. There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For example, ctrl-click (or jump to usages) on a definition that is used in multiple places opens up a new tab with a list of the results. In most other editors I've used, it's instead opened up a popover menu where I can quickly select which really I want to jump to. Opening those results in a new tab (and having that tab remain open after navigating to a result) feels like it clutters up my tabs with no benefit over a simple popover. Like you, I'll probably try again in a few releases' time, but right now the editor has so much friction that I'm not sure I actually save any time from the speed side of things.
- Aeolun 2y ago
  Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.
  - worthless-trash 2y ago
    As I don't use either, can't you just open the file and look for >>>> and <<<< and resolve them in whatever editor you need ? or do these editors do something else that helps with merge conflicts ?
    - interactivecode 2y ago
      yes, jetbrains editors are particually good at resolving merge conflicts. They also have a magic button to do all the obvious conflicts automatically.
    - MrJohz 2y ago
      A lot of IDEs these days offer a three-way-merge interface that massively improves on the conflict resolution process. Different tools have different interfaces, but generally you have three panes visible: one showing the diff original->A, one showing the diff original->B, and third showing the current state of the merged file, without conflicts. You can typically add chunks from either of the two diffs, or free edit your resolution based on a combination of the different options. I find resolving conflicts through this sort of system tends to be a lot more intuitive than trying to mess around with conflict markers - it also helps with protecting against mistakes like forgetting conflicts or wanting to undo changes. If you're not used to it, I really recommend finding a good three-way merge plugin for your editor/IDE of choice.
danielvaughn 2y ago
Yeah my experience has been that you aren't going to suffer performance problems with VSCode unless you have an incredibly large codebase. Past a certain point I'm sure Vim/NeoVim/Zed are probably much more performant, but the differences in smaller codebases is barely noticeable IME.
sensanaty 2y ago
I don't use it as my main editor (I'm far too used to the Jetbrains editors to make the switch, they're just too smart), but it's the best one for CLI apps that use EDITOR, like git. It boots up basically instantly even when it hasn't been launched in a while and I can make my commit messages and immediately close stuff up at the speed of my thought.
- theoperagoer 2y ago
  +1 for the Jetbrains gang.
  - Aeolun 2y ago
    The plus side for using Jetbrains is you can switch to literally anything else and it’ll feel lightning fast.
silisili 2y ago
A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me. VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.
- nicce 2y ago
  Did you have some plugins in vim? It is very odd if it was slower in this scenario.
  - silisili 2y ago
    Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters. Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slower than I expected.
    - iso8859-1 2y ago
      Might want to try https://github.com/LunarVim/bigfile.nvim https://github.com/LunarVim/bigfile.nvim
    - nicce 2y ago
      Just curious, what of you do the same with bare neovim, for science?
      - silisili 2y ago
        Sure, just tried it. This is time to open, show the initial contents, then exit. nvim is much faster to cursor around, except when you hit the opening or closing of a json block it hangs a bit, so I'm guessing it has some kind of json plugin built in. $ time vim tt.json real 0m5.910s user 0m4.120s sys 0m0.343s $ time nvim tt.json real 0m2.894s user 0m1.372s sys 0m0.292s
j1elo 2y ago
I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test. VSCode is very fast for me, when I open it in the morning and just starting my day. But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce scenario while changing code on the fly, then the test conditions are really set up where differences between slow/heavy and fast/lightweight software can be noticed. Things like slowness in syntax highlighting, or jankyness when opening different files. Not to mention what happened when I wanted to show the step-by-step debugging of the software to my colleagues. In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.
- veidr 2y ago
  Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature. When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM). I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.) I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day. I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months. But VS Code has a very, very large lead in features, especially if you are working with TypeScript. The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off. The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config. And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors. So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things. But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others. So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking.
hamandcheese 2y ago
> I don't know what's on zed/VSCode and what's on the TS language server. Microsoft's latest embrace-extend-extinguish strategy is keeping just enough special sauce in (frequently closed-source) vscode extensions and out of the language servers. They do the same thing with Pyright/Pylance.
- IshKebab 2y ago
  And the remote SSH and C++ extensions, though that actually has a good alternative in the Clangd extension. I'm kind of ok with it tbh. As a monetisation strategy it's not the worst, and I have no expectation that they just do all this for free.
  - cqqxo4zV46cp 2y ago
    Bandwagoners are keen to class everything Microsoft does to be competitive as EEE. This is just…them building a product. Throwing their weight around, building something really good, releasing it for free, something that only a handful of other companies could do? Hell yeah! It’s shady. But it’s not EEE.
- tannhaeuser 2y ago
  TS itself is lock-in. I mean, the entire point of JS is that it's portable, and there's certainly no lack of compile-to-JS languages that are already finished and have much more powerful type systems and existing libs/ecosystems. Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well. But the infanterists in our profession manage to get it wrong, every single time.
  - cqqxo4zV46cp 2y ago
    Could you perhaps consider a worldview that doesn’t place you as being better than everyone else that doesn’t share your preferences? I bet you don’t think that LLMs are going to replace you, rather you’re suspending disbelief to paint the most bleak picture of the future you can come up with, and, again, maximise the blame you place on everyone that isn’t as GOOD as you!
anonzzzies 2y ago
In the morning vscode is ok, come noon, it’s the primary thing eating my battery and it’s getting slower and slower; day end it’s unusable. Sure, restart it, I know, but it’s fairly terrible though.
- jcparkyn 2y ago
  I've never experienced this. Have you tried disabling all your extensions to see if one of them is causing it?
varispeed 2y ago
Okay, call me weird, but why our standards have fallen so low? VSCode may appear fast, but still has massive latency. The Zed website claims 97ms. I can feel it is laggy. Why can't we have response time under 1ms? Even 5ms would be a massive improvement. For me latency is a massive productivity killer as it feels like walking in a swamp and it always puts me off.
- whalesalad 2y ago
  I agree with you -- but aiming for 1ms performance is pretty hard. That is 1/1000th of a second. Your keyboard probably has higher latency than that. Physics cannot be defeated in this regard.
  - garblegarble 2y ago
    Expanding on this, there's a detailed analysis of the various contributors to editor latency (from keyboard electronics to scanout) by one of the jetbrains devs at[1]. They show average keypress-to-USB latency for a typical keyboard of 14ms! 1: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
  - varispeed 2y ago
    There are keyboards with 1kHz polling.
    - wholinator2 2y ago
      Yes but it takes longer than that for the signal to reach the usb port. And i doubt if many of us are typing at 1000 keystrokes/second. Apparently that's around 12,000 words/minute assuming average word length of 5 characters.
      - varispeed 2y ago
        1ms latency is about what can be achieved with USB.
- 2y ago
microflash 2y ago
> 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server. I had similar experience with JavaScript where it kept showing me errors (usually for ESM imports) even though things were fine. In VSCode, things worked without fuss. I've been testing out JetBrains Fleet [1] as well and its language support is far superior compared to Zed. [1]: https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/
giamma 2y ago
You should give Theia Ide [1] a try. It's plugin-compatible with VSCode, same user experience. It's slower to start and takes more memory but on my 3 y.o. intel Mac it is definitely snappier than VScode. [1] https://theia-ide.org/ https://theia-ide.org/
elAhmo 2y ago
Hah, similar here. I keep trying it out after seeing posts here and there, but I can't seem to switch from VSCode. For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.
avianlyric 2y ago
> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server. VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.
- vintagedave 2y ago
  Any idea how this works? It seems crazy that a generic engine can outdo a language-specific LSP server.
  - avianlyric 2y ago
    Mostly by being more flexible in its inputs and outputs than an LSP. An LSP is generally trying to perform deep static analysis on your code to provide suggestions. The upside is extremely accurate suggestions, with a pretty much 0 false positive rate (I.e. it never suggests anything uncompilable), the down side is that they tend to be much picker about their inputs. If the code is currently in an un-parsable state, and a valid AST can’t be produced, then the LSP is forced to work with whatever parsed version of the code it was last able to build a valid AST for. Making the autocomplete results, incomplete. VSCode on the other hand is basically performing tokenisation and fuzzy search on those tokens. It doesn’t really care about the validity of the code, that means more false positive suggestions (I.e. suggesting stuff that can’t compile), but very robust handling of un-compileable code. That plus prioritising LSP suggests over fuzzy suggestions, results in VScode providing a very nice graceful fallback for LSP failures, that people probably use more often than they expect.
wg0 2y ago
I have a mono repo. There's lot in it. And lot many files. Typescript. Go. Python. I have a lower end mac book Air. Not having any issues with VS code.
major505 2y ago
I came from Visual Studio to vscode. VsCode looks super lightweight to me.
dimgl 2y ago
Zed looked pretty cool but the amount of extensions VSCode has makes it difficult to justify a switch. I do think that the SQL extensions for VSCode are pretty terrible, so maybe that's something where Zed can capitalize. Interestingly the biggest issues we're having with VSCode have nothing to do with the IDE itself and are instead related to the TypeScript language server. There are so many bugs that require the TypeScript language server to be restarted, and there's little the VSCode team can do about that. Made a new file? Restart. Rename a file? Restart. Delete a directory? Restart. Refactor a couple of classes? Might need a restart. We're also having some serious language server slowdowns because of some packages we're using. And there's not much Zed can do here for us either. It's really unfortunate because the convenience of having a full-stack TypeScript application is brought down by all of these inconveniences. Makes me miss Go's language server.
api 2y ago
Zed is amazing for Rust and pretty good for C++. I feel like it's better for more systems-y languages than JS/TS etc.
deleted 2y ago
[deleted]

dijit 2y ago

Yeah, I agree about VSCode being sort of fast enough. Computers are getting faster and I’m on a M-series mac which makes web rendering much faster but still I feel like as far as electron apps go: VScode is basically the golden child. Slack & Teams on the other hand, ouch.

yoyohello13 2y ago

My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit. My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.

whalesalad 2y ago
but vscode is open source: https://github.com/microsoft/vscode https://github.com/microsoft/vscode and there are third-party builds from the community that disable things like telemetry: https://vscodium.com/ https://vscodium.com/
- yoyohello13 2y ago
  Sorry, I should have been more specific and said FOSS. VSCode is still encumbered by the weight of a mega corp. It's like saying Chrome is open source. Sure it is, but it still exists to serve the corporation that owns it.
  - TiredOfLife 2y ago
    It's MIT licensed. So it's more FOSS than FOSS
    - correct-horse 2y ago
      It's free software in letter, but not in spirit. True free software doesn't lock out non-official builds for zero technical reasons.
      - fragmede 2y ago
        what about vscodium? for that reason, what was iceweasel?
        nicce 2y ago
        There is some sort of vendor lock-in VSCode. It at least used to be extremely difficult to make GitHub Copilot to work with codium. There is something closed source in VSCode that makes the difference. It was so difficult to maintain, that I ended up switching to VSCode. So the ”lock-in” worked.
        janice1999 2y ago
        vscodium and VSCode forks are legally prevented from using the normal VSCode extension site. They have their own: https://open-vsx.org/ https://open-vsx.org/ As far as I know Chrome forks are not blocked from using extensions from the Chrome Web Store.
        n_plus_1_acc 2y ago
- screcth 2y ago
  The problem is that many parts of the ecosystem require that you use the official MS build. You can't connect to the Marketplace and some extensions outright can't be used with a custom build.
  - vorticalbox 2y ago
    You can however down the extension from the website and install it from the terminal. codium --install-extension {path to .vsix}
    - KETHERCORTEX 2y ago
      You are able to do so, but is it allowed by the website's terms of service? It may say that you are granted the license to extensions only with Microsoft builds of vscode. Microsoft isn't a stranger to distribution restrictions and software usage limitations. I remember uploading Visual C# Express 2010 (freely downloaded from Microsoft's website, without license keys) to a local file sharing website to ease the downloading for my local study group and got a letter from Microsoft's lawyer to take it down. After that our study group transitioned to Mono with Monodevelop.
      - whalesalad 2y ago
        Terms of service? Who cares.
      - Arnavion 2y ago
        An actual example is that the Python LSP extension on the offical marketplace has some "DRM" that makes it pop up a fatal "You can't use this extension except with the real VSCode" error message. People have been playing whack-a-mole with it by editing the obfuscated JS to remove that check, or by using an older version from before they added the check. https://github.com/VSCodium/vscodium/discussions/1641 https://github.com/VSCodium/vscodium/discussions/1641
        KETHERCORTEX 2y ago
- 0cf8612b2e1e 2y ago
  You mean except for all of the good plugins. Or the ability to use a custom plugin store. Last I read, the open builds struggled with removing all of the MS telemetry and some may still be leaking.
- chx 2y ago
  https://ghuntley.com/fracture/ https://ghuntley.com/fracture/
deleted 2y ago
[deleted]
kiitos 2y ago
I, too, prefer to cut off my nose to spite my face.
- yoyohello13 2y ago
  Yes, living by principles is inconvenient sometimes.

the_duke 2y ago

I think people just have very different tolerances for latency and slowness. I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it. I tried out Zed and it actually feels fast enough for me to consider switching.

whalesalad 2y ago
Sublime Text 3 is still one of my favorite editors. I use VSCode lately because of its excellent "Remote SSH" integration - but when it comes to latency sublime has it beat. Zed does not feel fast on my machine, which is a 13900K/128gb ram. It is running in xwayland though, so that could be part of the problem. It feels identical to vscode.
- correct-horse 2y ago
  | It is running in xwayland though It definitely isn't on my system, and I did not touch the configs at all; are you sure about that?
  - whalesalad 2y ago
    Fairly positive due to blurry cursors, but I have no way to verify.
    - ndiddy 2y ago
      If you run xeyes and the eyes follow your cursor when it's above the application you want to test, it's running under xwayland. If they don't follow your cursor, the application is running under native Wayland.
      - 369548684892826 2y ago
        finally a use for xeyes?

MrJohz 2y ago

Yeah, this was mostly my experience. The Zed editor was fast, but it just felt like it wasn't as good as other editors. For me, the version control integration was particularly poor - it shows some line information, but diffing, blame, committing, staging hunks, reviewing staged changes etc are all missing. There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For example, ctrl-click (or jump to usages) on a definition that is used in multiple places opens up a new tab with a list of the results. In most other editors I've used, it's instead opened up a popover menu where I can quickly select which really I want to jump to. Opening those results in a new tab (and having that tab remain open after navigating to a result) feels like it clutters up my tabs with no benefit over a simple popover. Like you, I'll probably try again in a few releases' time, but right now the editor has so much friction that I'm not sure I actually save any time from the speed side of things.

Aeolun 2y ago
Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.
- worthless-trash 2y ago
  As I don't use either, can't you just open the file and look for >>>> and <<<< and resolve them in whatever editor you need ? or do these editors do something else that helps with merge conflicts ?
  - interactivecode 2y ago
    yes, jetbrains editors are particually good at resolving merge conflicts. They also have a magic button to do all the obvious conflicts automatically.
  - MrJohz 2y ago
    A lot of IDEs these days offer a three-way-merge interface that massively improves on the conflict resolution process. Different tools have different interfaces, but generally you have three panes visible: one showing the diff original->A, one showing the diff original->B, and third showing the current state of the merged file, without conflicts. You can typically add chunks from either of the two diffs, or free edit your resolution based on a combination of the different options. I find resolving conflicts through this sort of system tends to be a lot more intuitive than trying to mess around with conflict markers - it also helps with protecting against mistakes like forgetting conflicts or wanting to undo changes. If you're not used to it, I really recommend finding a good three-way merge plugin for your editor/IDE of choice.

danielvaughn 2y ago

Yeah my experience has been that you aren't going to suffer performance problems with VSCode unless you have an incredibly large codebase. Past a certain point I'm sure Vim/NeoVim/Zed are probably much more performant, but the differences in smaller codebases is barely noticeable IME.

sensanaty 2y ago

I don't use it as my main editor (I'm far too used to the Jetbrains editors to make the switch, they're just too smart), but it's the best one for CLI apps that use EDITOR, like git. It boots up basically instantly even when it hasn't been launched in a while and I can make my commit messages and immediately close stuff up at the speed of my thought.

theoperagoer 2y ago
+1 for the Jetbrains gang.
- Aeolun 2y ago
  The plus side for using Jetbrains is you can switch to literally anything else and it’ll feel lightning fast.

silisili 2y ago

A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me. VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.

nicce 2y ago
Did you have some plugins in vim? It is very odd if it was slower in this scenario.
- silisili 2y ago
  Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters. Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slower than I expected.
  - iso8859-1 2y ago
    Might want to try https://github.com/LunarVim/bigfile.nvim https://github.com/LunarVim/bigfile.nvim
  - nicce 2y ago
    Just curious, what of you do the same with bare neovim, for science?
    - silisili 2y ago
      Sure, just tried it. This is time to open, show the initial contents, then exit. nvim is much faster to cursor around, except when you hit the opening or closing of a json block it hangs a bit, so I'm guessing it has some kind of json plugin built in. $ time vim tt.json real 0m5.910s user 0m4.120s sys 0m0.343s $ time nvim tt.json real 0m2.894s user 0m1.372s sys 0m0.292s

j1elo 2y ago

I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test. VSCode is very fast for me, when I open it in the morning and just starting my day. But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce scenario while changing code on the fly, then the test conditions are really set up where differences between slow/heavy and fast/lightweight software can be noticed. Things like slowness in syntax highlighting, or jankyness when opening different files. Not to mention what happened when I wanted to show the step-by-step debugging of the software to my colleagues. In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.

veidr 2y ago
Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature. When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM). I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.) I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day. I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months. But VS Code has a very, very large lead in features, especially if you are working with TypeScript. The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off. The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config. And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors. So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things. But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others. So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking.

hamandcheese 2y ago

> I don't know what's on zed/VSCode and what's on the TS language server. Microsoft's latest embrace-extend-extinguish strategy is keeping just enough special sauce in (frequently closed-source) vscode extensions and out of the language servers. They do the same thing with Pyright/Pylance.

IshKebab 2y ago
And the remote SSH and C++ extensions, though that actually has a good alternative in the Clangd extension. I'm kind of ok with it tbh. As a monetisation strategy it's not the worst, and I have no expectation that they just do all this for free.
- cqqxo4zV46cp 2y ago
  Bandwagoners are keen to class everything Microsoft does to be competitive as EEE. This is just…them building a product. Throwing their weight around, building something really good, releasing it for free, something that only a handful of other companies could do? Hell yeah! It’s shady. But it’s not EEE.
tannhaeuser 2y ago
TS itself is lock-in. I mean, the entire point of JS is that it's portable, and there's certainly no lack of compile-to-JS languages that are already finished and have much more powerful type systems and existing libs/ecosystems. Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well. But the infanterists in our profession manage to get it wrong, every single time.
- cqqxo4zV46cp 2y ago
  Could you perhaps consider a worldview that doesn’t place you as being better than everyone else that doesn’t share your preferences? I bet you don’t think that LLMs are going to replace you, rather you’re suspending disbelief to paint the most bleak picture of the future you can come up with, and, again, maximise the blame you place on everyone that isn’t as GOOD as you!

anonzzzies 2y ago

In the morning vscode is ok, come noon, it’s the primary thing eating my battery and it’s getting slower and slower; day end it’s unusable. Sure, restart it, I know, but it’s fairly terrible though.

jcparkyn 2y ago
I've never experienced this. Have you tried disabling all your extensions to see if one of them is causing it?

varispeed 2y ago

Okay, call me weird, but why our standards have fallen so low? VSCode may appear fast, but still has massive latency. The Zed website claims 97ms. I can feel it is laggy. Why can't we have response time under 1ms? Even 5ms would be a massive improvement. For me latency is a massive productivity killer as it feels like walking in a swamp and it always puts me off.

whalesalad 2y ago
I agree with you -- but aiming for 1ms performance is pretty hard. That is 1/1000th of a second. Your keyboard probably has higher latency than that. Physics cannot be defeated in this regard.
- garblegarble 2y ago
  Expanding on this, there's a detailed analysis of the various contributors to editor latency (from keyboard electronics to scanout) by one of the jetbrains devs at[1]. They show average keypress-to-USB latency for a typical keyboard of 14ms! 1: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/
- varispeed 2y ago
  There are keyboards with 1kHz polling.
  - wholinator2 2y ago
    Yes but it takes longer than that for the signal to reach the usb port. And i doubt if many of us are typing at 1000 keystrokes/second. Apparently that's around 12,000 words/minute assuming average word length of 5 characters.
    - varispeed 2y ago
      1ms latency is about what can be achieved with USB.
2y ago

microflash 2y ago

> 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server. I had similar experience with JavaScript where it kept showing me errors (usually for ESM imports) even though things were fine. In VSCode, things worked without fuss. I've been testing out JetBrains Fleet [1] as well and its language support is far superior compared to Zed. [1]: https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/

giamma 2y ago

You should give Theia Ide [1] a try. It's plugin-compatible with VSCode, same user experience. It's slower to start and takes more memory but on my 3 y.o. intel Mac it is definitely snappier than VScode. [1] https://theia-ide.org/ https://theia-ide.org/

elAhmo 2y ago

Hah, similar here. I keep trying it out after seeing posts here and there, but I can't seem to switch from VSCode. For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.

avianlyric 2y ago

> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server. VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.

vintagedave 2y ago
Any idea how this works? It seems crazy that a generic engine can outdo a language-specific LSP server.
- avianlyric 2y ago
  Mostly by being more flexible in its inputs and outputs than an LSP. An LSP is generally trying to perform deep static analysis on your code to provide suggestions. The upside is extremely accurate suggestions, with a pretty much 0 false positive rate (I.e. it never suggests anything uncompilable), the down side is that they tend to be much picker about their inputs. If the code is currently in an un-parsable state, and a valid AST can’t be produced, then the LSP is forced to work with whatever parsed version of the code it was last able to build a valid AST for. Making the autocomplete results, incomplete. VSCode on the other hand is basically performing tokenisation and fuzzy search on those tokens. It doesn’t really care about the validity of the code, that means more false positive suggestions (I.e. suggesting stuff that can’t compile), but very robust handling of un-compileable code. That plus prioritising LSP suggests over fuzzy suggestions, results in VScode providing a very nice graceful fallback for LSP failures, that people probably use more often than they expect.

wg0 2y ago

I have a mono repo. There's lot in it. And lot many files. Typescript. Go. Python. I have a lower end mac book Air. Not having any issues with VS code.

major505 2y ago

I came from Visual Studio to vscode. VsCode looks super lightweight to me.

dimgl 2y ago

Zed looked pretty cool but the amount of extensions VSCode has makes it difficult to justify a switch. I do think that the SQL extensions for VSCode are pretty terrible, so maybe that's something where Zed can capitalize. Interestingly the biggest issues we're having with VSCode have nothing to do with the IDE itself and are instead related to the TypeScript language server. There are so many bugs that require the TypeScript language server to be restarted, and there's little the VSCode team can do about that. Made a new file? Restart. Rename a file? Restart. Delete a directory? Restart. Refactor a couple of classes? Might need a restart. We're also having some serious language server slowdowns because of some packages we're using. And there's not much Zed can do here for us either. It's really unfortunate because the convenience of having a full-stack TypeScript application is brought down by all of these inconveniences. Makes me miss Go's language server.

api 2y ago

Zed is amazing for Rust and pretty good for C++. I feel like it's better for more systems-y languages than JS/TS etc.

deleted 2y ago

[deleted]