Zed is so great, I do wish they would focus just a little bit more on bringing the UI just a bit more up to parity with VS Code, I would switch full time.
replies(3):
For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.
- Git UI is extremely barebones with no support for other VCS
- No merge tool or side-by-side diffs
- Configuration is all JSON
- Would be nice having a full file tree for the search editor instead of just the list; having the functionality split between a tab and the outline panel is quite clunky.
- Ability to move panels (files/git/console/debugger/etc) into standalone windows or other configurations (multiple docks per side, multiple copies of the same panel linked to a specific tab).
Zed is basically a slightly more featured text editor, so it does a good job when I just want to open something quickly and do small edits. So it's really replacing Sublime Text.
But I find myself hopping out to other tools when I'm using Zed which wasn't really common with IntelliJ. So I still want to use a proper IDE for proper development work.
If they'd used Skia (which is what Electron and Chromium use), they would've got this for free. Instead they tried to reinvent the world and didn't realise how big the world was.
Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?
> Ability to move panels (files/git/console/debugger/etc) into standalone windows
Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
Here you go: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
> I found Copilot tab completion completion to be VERY slow in Zed, for some reason.
> Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow
> I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code.
> I mean, good AI tab completion feels like a super power. Zed’s is not that good. It’s slow and normally not at all what I want.
> Zed tab is a lot worse in comparison (partly because it’s slow)
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).
> All I'm saying is that contrary to what someone else said about the software being "fast" I tried it and at startup, it was unusably slow.
> Tried using zed on Linux (pop os, Nvidia) several months ago, was terribly slow, ~1s to open right click context window.
> Zed is as close as it gets, I also use it, but it is still slow and cumbersome sometimes.
I'll stop here. There are other 4 pages of comments to pick anecdotes from, in this simple search alone.
I don't care about the configuration language so much personally (though JSON is of course pretty lame in a lot of ways for that task.)
Really just a GUI for editing, the storage format can still be JSON and synced/backed up however you handle text files.
It just really nice having settings grouped by categories, with dropdowns for possible values, indicators for changes from default values or values overridden by project settings, search/hide/filters, and tooltips for what it does.
Right now the experience with Zed is: open the settings file, open the default settings file for documentation, and basically use search and copy-paste magic value strings/int/float/nulls into the right nested object/key.
> Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)
Really the separate window experience (including the file browser/git pane). Really nice having the git panel just open on a window so you can quickly glance at changed files and quickly jump back to them for more editing. Or having search results able to spawn tabs in another pane/window so you don't have to keep switching back to search or rearranging the tab after opening the file from it.
Or even just expanding the workspace across monitors. Right now you can't even move tabs into its own window or across windows.
Have Claude Code resolve merge conflicts, problem solved.
Tests:. Zed is bare bones compared to IntelliJ (rerun failed tests, export list of failures, go to failed lines easily etc
The AI stuff is cool but it won’t get me to switch from PyCharm.
MacOS native apps have had great sub-pixel rendering all along, but I guess since we have to develop everything in Electron now it's time to reimplement all the exiting functionality.
Apple removed subpixel anti-aliasing in Mojave, seven years ago, because it's not necessary on the HiDPI/Retina displays they ship as standard. They still do greyscale anti-aliasing but that's not the same thing as subpixel.
Discussion from the time: https://news.ycombinator.com/item?id=17476873
I disagree. Subpixel anti-aliasing triples the available horizontal resolution, and makes text crisper. The algorithms are known and regardless of the density it should always be applied to text and vector graphics elements.
The RGB stripe layout is so useful that OLED manufacturers are moving to it in 2026, away from the long-derided PenTile where magenta/green fringing is seen even on the densest displays.
In fact rendering on macOS is completely broken, and I don't know how people stand by it. At any scaling factor selected that is not a perfect factor of the actual hardware resolution (the 'looks like' value in Settings), the final framebuffer is scaled and interpolated to the display resolution, and everything is noticeably more blurry.
Windows has had some form of hardware-independent rendering since Windows 7, and proper pixel density control arrived in Windows 8.
Meanwhile on Linux and Windows, they still implement subpixel rendering so fonts look great on 1440p.
That said, for something like a text editor where fonts are central the entire application and the worst subpixel edge cases like animation are unlikely to come up, it's maybe not unreasonable to ask them to go the extra mile. It's going to be a sticking point on Windows and Linux for a long time if they don't.
- Zed is not an electron app
- In the linked issue you can see that this issue does not exist in Electron.
1) How much font hinting to apply. More hinting changes the shape to make glyphs line up better with pixels so that less antialiasing is required. macOS prefers very light hinting to preserve shapes at the cost of blurriness. This is what you are talking about.
2) Subpixel rendering. This effectively triples the horizontal resolution when rendering fonts, and does not affect the shape at all. Fonts look dramatically better on normal dpi displays when using it. macOS removed support for this many years ago. This is what I'm talking about.
I know some people have bad experiences with 1440p and macos for some reason, but I haven't had any such experience that I could not fix. So all these are not universal. Some people act as if any monitor below 200dpi will look terrible on macsos. This is definitely not the case.
Do you think messages like this are talking about VSCode performance?
> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).