I’ve now been using Visual Studio Code for pretty much all my projects (work and personal) since sometime in 2016 when I switched from the ill-fated Atom. That’s nearly a decade in the same editor! Over the years, I’ve tried numerous alternatives from Goland, IntelliJ, and Fleet to Vim/Neovim and Helix, but I’ve always ended up back in VSCode for the work that really matters.

This is likely due the the vast extensibility of the editor and the size of its community. There is nearly always something that I can’t do as easily in another editor as I can in VSCode. Or if I can, then it takes a remarkable amount of configuration and maintenance for it to work as smoothly. That aside, change is hard and moving to another editor is a big commitment that often comes with a learning curve and a dip in productivity - something that is hard to justify. But with that said - I’m done with VSCode. It’s time to move on and this is why.

⚡ Electron

Electron is one of those things that I’m both glad exists and at the same time wish was never invented. There is a school of thought that says that Electron has made apps so much easier to build that we wouldn’t have a lot of the tools we love without it. There is probably an element of truth to this, but in reality I don’t love tools that are written in Electron. At best, I tolerate them and at worst, I despise them.

Felix Rieseberg (Co-maintainer at Electron) wrote an excellent blog post in 2025 on the things people get wrong about Electron which I’m linking here for balance. There are always tradeoffs to be made in software development and there is a place for tools that decrease cost and complexity. However, in my experience, these tradeoffs usually come at the cost of the user’s experience.

While it is possible to write performant Electron apps, its low barrier to entry made it a cheap, lazy shortcut to building a low effort, multi-platform applications that are often slow and memory hungry with a huge bundle size. Most Electron apps that I have used have bad platform cohesion (i.e. they don’t feel native) and rely heavily on the upstream project to fix years-old bugs or implement new features. I can (begrudgingly) deal with this when it comes to Discord or Slack, but not in my editor.

If you didn’t know or hadn’t already guessed, VSCode is an Electron app. There are actually many reasons why this was a great idea. It needed to be cross-platform, easy to extend and support a web-based editor and extensions. Things that are easily accomplished by using Electron.

It’s also worth noting that the Microsoft team has put a monumental effort into optimising the editor as well as contributing to the upstream project, but its still just slow. I often experience crashes or disconnects. Sometimes things just hang for 30 seconds for no reason. Occasionally the whole thing needs to be restarted to “fix” it. Panes don’t resize consistently when the window is moved around. Many issues are frozen-in-time and tagged with an “electron” label because they are tied to a bug or deficiency in the framework.

✨ AI

I have no fundamental objection to AI tooling or people who use it. Like it or not, it’s going to be a core part of the future of software development. However, if you take a look at the last years worth of releases from VSCode, you’ll struggle to find many genuinely useful, non-AI features that have been added. Perhaps the built-in source control graph or better worktrees support? Microsoft has AI on the mind and it’s ALL they care about right now as they struggle to keep up with their competitors. Even their website now refers to the editor as “The open source AI code editor”.

It’s a reminder that your money speaks louder than your words when it comes to companies like Microsoft. I’m all for new AI features, but let’s not forget that there are other ways to improve the editor. Very few of the top upvoted issues are related to AI and many of them have been open for years.

This is not enough to push me away from VSCode by itself. However, I do miss the days of being excited for a new release. More recently, I find myself not even bothering to look at the changelogs as every entry is just about improvements to the AI agents 👎 Boo.

🙏 Zed

I’ve been following the Zed project with great anticipation for about a year now, but I’ve been let down by the promise of a new native editor before (cough Fleet cough) and I’ve been tempering my expectations until it gets to a reasonable state. With their v1 release planned for Spring 2026, that time is getting closer and now that they have official Windows builds with full remote support, a Git integration and a debugger, I’ve finally decided to test the waters and have been using it for daily development for the last few weeks. Here are my thoughts so far.

SPEEEED

Wow. I can’t even begin to describe the feeling. I’ve been programming using VSCode’s remote development plugin for many years now, so I’m used to a bit of lag and the occasional hiccup or disconnect, but even compared a local instance of VSCode, Zed is on another level. Everything is faster. Typing is inexplicably snappier, the control panel is responsive, opening/saving files is instant and searching is lightning fast. When using the native remote support, nothing changes. It feels like you’re editing an offline file.

First-party support

Zed doesn’t have generic plugins or extensions in the same way that VSCode does. It has themes and language support extensions, but you can’t add new views or modify existing ones (yet). However, I don’t find myself missing them. Zed has first-party support for Git, LSP, MCP, debugging and remote editing (via SSH). When I look through my list of VSCode extensions, I find that they’re either not important or already bundled into the core Zed editor. There are a few that I genuinely miss, but more on that later.

It’s small things like the UUID generator, lines sorter or case changing extensions which are no longer needed as they are built into Zed’s command palette. Being built-in gives you that peace of mind that they are maintained and available out of the box without having to remember which extensions worked and which didn’t.

Multibuffers

Speaking of search, Zed’s multibuffer search is a thing of glory. This sort of thing is possible in VSCode, but its not the default and I often have issues with the fuzzy search not finding my files until I basically type the entire name in. In Zed, it just works out of the box. No configuration, no issues. Wonderful.

It’s not perfect

Sadly, nothing is perfect and neither is Zed. I did run into a few things ranging from slightly annoying or outright missing:

• As I was writing this, the side-by-side diff view PR was merged and later enabled for everyone. However, this view is still not available in a few places (like file history) and there is no 3-way merge editor.
  • Ironically, a good 3-way merge editor was one of VSCode’s most requested features for years and was only added in the last year or so. However, despite numerous adjustments from Microsoft, I still find it buggy and difficult to use. Hopefully the Zed team does a better job with theirs when they get to it.
• No Git graph or viz tools
  • A PR for this was also merged recently, but adjustments need to be made before its ready to be published.
• No GitHub Pull Requests extension
• No zed command in remote terminals (can’t open remote files from the terminal) #32214.
• No Buf LSP #28256
• No remote port forwarding support
• No plugin support outside of LSPs and Themes
  • Obviously this is a huge shortcoming of Zed. However, for the time-being I don’t find this to be a problem and one day, extension support will come. It will be interesting to see what form this takes when it does.

Conclusion

In my introduction, I said that I always end up back with VSCode. I don’t see that happening this time. There are definitely a few things I will miss, but all signs point to these features being added in future updates. While you should never judge a product on its future promises, I think the pros of Zed already outweigh the cons.

So while I will miss some features, I am happy to either reduce my dependency on these and work around the missing functionality temporarily in return for the numerous fundamental benefits that Zed brings to the table.

Zed is an open source project maintained by a core team of well respected, passionate developers instead of a multi-trillion dollar company. It’s written in Rust using native libraries for performance and stability. It has first-party support for all the things you would expect from a modern editor/IDE such as LSP/MCP, A Git integration, remote development and a plethora of AI agents. I find myself wanting this project to succeed more than I have for any editor that has come before. So until something better comes along or Zed is enshittified (please no), then I will be making my bed here.