Sadly, I came back to using VS Code recently. There's a lot to like in Zed but imo that decision to write their own rendering framework is unfortunate, because of ridiculous problems in Linux still not resolved like poor font rendering, especially on low-DPI screens, or visible lags of UI which is being developed to be blazingly fast. So far, VS Code is faster for me.
Remember that Zed hasn't reached 1.0.
On other platform, it is much faster and consume much less battery. Just like ghostty, to me the most attracting feature is knowing my editor/term is not backed by a browser engine.
> the most attracting feature is knowing my editor/term is not backed by a browser engine
How and why is this important? At any time I have two browsers with dozens of tabs and on top of it a slack client active, how another instance of a browser engine could hurt in this mad world?
try it and found out; it's not about memory overhead (maybe it is to someone), it's that it works so much better than web backed things. it's just an absurdly fast/responsive/delightful thing to experience after years of everything going the other way [while hardware actually gets faster]
and i say this as a proud career long web developer. i just really like zed.
Zed was my daily driver for almost a year. When it's working fine and not drawing the mouse cursor at 3 FPS it feels pretty much as anything else in terms of perceived speed. I saw mentions that you need to be younger to notice the difference. Like you don't hear frequencies above 18 KHz if you're more than 20 years old. I get the idea, I just don't see where it is connected to my real world experience
As a quick anecdatum, I'm on macos and I'm definitely more than 20 years old, and there is a quite perceptible difference in responsiveness between Zed and a VSCode-based IDE for me. (Though then again I did play fast-twitched games a lot when I was younger.)
I listened to a podcast interview with one of the cofounders of zed. One of the revealing things is that he went on and on about how important latency was and how they had to do their own rendering because of the problems they ran into with electron. He also admits that he never used vim, which already has imperceptible latency relative to the terminal emulator, which has already largely solved the text rendering problem.
I understand that there are advantages to being a native app from their perspective, but for me, it is even better for my editor to be integrated into my terminal editor. And because they built it the opposite way though, they have to also build a terminal emulator into their editor.
There is a real cost to building zed this way. If they were an embedded terminal app, they would get full terminal support for free and would not have to implement 2d text rendering. They could even have made a bundled package with an oss terminal emulator like kitty. Then they could have focused strictly on their editing features and value adds. Every engineer hour spent fixing bugs/adding features to the rendering framework is an hour that could have been spent on value adds.
Personally, there is no way that latency itself can be that value add for me because I use neovim and don't use any language plugins so every keystroke already renders instantly. Clearly then you can do everything zed does in a terminal app within at worst tens of milliseconds of latency.
Of course their target market uses vscode and not vim and either doesn't know or care that you do not need to write your own rendering engine to make a low latency, featureful text editor. I am admittedly very much not the target consumer for zed though.
Just to clarify, for vim I'm talking about the scp:// thing, for emacs there is of course TRAMP. In both cases you're running a local editor and fetching the remote file, then sending it back when making changes. So your plugins and such should work just fine. I am not talking about sshing into the machine and running vim or emacs as a TUI on that remote machine, which is also possible with both editors.
Learning and wanting to use as a daily driver are very different things.
I use vim on my servers and for writing git commit messages. For everything else, I use another editor (used to be Sublime Text, then Vs code, now Zed).
Nailed it. I'm fine with using vim to do remote work. I'm not an expert, but I have enough muscle memory to zip through the things I need to do. I don't want to use it exclusively, though. Turns out I'm capable of learning my way around multiple tools and using different ones in different contexts. Who knew?
I don’t say I don’t know how to use one. I was a longtime vim and then neovim user. But I don’t want to use one.
I still use vim for quick terminal edits, git commit messages, and doing stuff over ssh. But for my day to day heavy text editing, I do not want to sit in a terminal and be limited by what a terminal can display.
I seem to hear this a lot, but there's probably like 10 commands (maybe a few more if you want to be fancy with copy-paste). Note: great if you like nano however!
For those that are interested, this will get you 90% there:
+1 I've explored Atom when it was the hot thing, and more recently, an IDE called Lapce, which is built in Rust and doesn't use Electron.
They've been great, but the lack of an ecosystem stares glaringly right at your face. I don't like Electron apps but VSCode gets the job done.
I have my entire set of plugins and things installed here and now the productivity that I get off this setup even exceeded my long-loved Jetbrains IDEs. I hope that will be temporary though, seriously.
The only thing that I strictly dislike about VSCode is the number of high quality themes available - and there are not that many.
Recently stumbled upon VSCodium which is a clean VSCode fork that can work with any VSCode plugin, but I am yet to try it out.
I miss Atom. I loved it. I loved all the crazy plugins people would make to do all sorts of things. It was a fun time.
These days I'm stuck on QTCreator most of the time. It's OK for core editing functionality but there's a lot that I miss, and some things like the generic Language Server support just aren't fleshed out much.
I'm tempted to use another editor whenever I'm not working on UI files but it adds some friction.
> VSCode fork that can work with any VSCode plugin
Technically yes, but if you care about legally, you can't use extensions from Microsoft's marketplace, which excludes Microsoft's own closed extensions such as WSL/SSH/devcontainer remoting and Pylance. It ships with Open VSX instead.
I use it on Linux and think it's great. My laptop has a screen with some crazy-high DPI and a monitor which doesn't. Changing the font sizes in settings to suit has never left me with a poorly rendered view.
Same experience here on Linux, where bast majority of potential users seems to be in Linux who loves vim mode, Zed's focus on Linux is pretty bad. I would say alpha quality at this point.
