I've used VS Code for my Rust development for several years, and I tried out Zed for a couple weeks earlier in the summer. The integration with `rust-analyzer` wasn't super smooth though, so I've switched back for now but would consider trying it again when it's more mature.
I've tried it a few times, and each time there's been something missing that was too irritating to live without - stuff like git integration, or extensions that I use a lot. It's nice, but I don't really notice the speed much once the application is open and running, and so I just ended up back at vscode every time.
I’ve also recently switched (largely) from Vim to Zed and I also think that Zed is in many ways great.
At the same time it’s been pretty frustrating to use an editor that is spending so much time building AI integrations, REPLs, and so fourth when basic things like cut and paste and common Vim motions still have so many bugs.
I’d love to see them prioritize getting the basics solid first.
Yeah I feel the same way. The fact that Zed uses the system clipboard as the default register in vim mode, for instance, made it impossible to use in practice for me -- having every yank replace my clipboard was a bit of a nightmare!
The `+` register is the system clipboard in vim already. What you're referring to is remapping the `+` register as the default register (in place of the 'unnamed' register, which is accessed explicitly as the `"` register) for some operations - typically yank and paste.
I don’t know. That feels perfectly reasonable for what I imagine is 99% of all developers, so while sad, I can imagine why that use case is not very high on their list of priorities.
> That feels perfectly reasonable for what I imagine is 99% of all developers, so while sad, I can imagine why that use case is not very high on their list of priorities.
I think you might be under the impression that what the GP is complaining about is having the default copy and paste go to the system clipboard.
This is not what is happening; in Vim all modifications are saved to the default register. Making the default register the system clipboard is annoying, because the following happens:
Insert a newline? Newline replaces whatever is in the clipboard.
Switch around two letters in a typo with `xp`? That text replaces the contents of the system clipboard.
Remove a word? Change a word? Add a new word? All replace the contents of the system clipboard.
Run a macro that changes things around? Nukes the system clipboard.
I don't think that 99% of developers want this behaviour. What they want is that when they explicitly copy something, it must be reflected in the system clipboard.
I assume all of these are some special combination of keys/modifiers? While I agree it’s less than ideal, at least you always know it’s going to happen if you are sort of familiar with Vim.
> I assume all of these are some special combination of keys/modifiers?
It's rare, in Vim, to not use commands. It is, after all, a command-oriented interface.
Any command that removes text or modifies text places the removed text into the default register.
> While I agree it’s less than ideal, at least you always know it’s going to happen if you are sort of familiar with Vim.
The problem with making the default register nuke the system clipboard is that almost all text editing commands are going to nuke the system clipboard.
To be frank I don’t the majority of us care about these collaboration features. We just want a way to write code that is performant but makes it easy to leverage existing language servers.
I want to pay for Zed for what it is. I want to sponsor a new code editor. I have zero interest in paying for a SaaS collaborative editor.
I'm wondering if the author ever tried one of the many neovim distributions, which solve a lot of the problem they're describing. All of the plugins and integrations necessary are already set up to create a nice fully featured IDE-style environment. E.g. LazyVim, AstroVim or NvChad
After years of using Vim as a keyboard assassin, then Neovim (with a custom config initially based on kickstart.nvim), about a month ago I started using LazyVim. After test-driving the default config for just a few hours, I found myself nodding my head and saying to myself, "Yes, this is the way."
I had seen some of the other "Neovim as IDE" projects but after looking at them carefully, I decided that LazyVim is generally the most polished one out there. Folke deserves a lot of credit.
The breakthrough for me was realising that it's a totally acceptable tradeoff to let other developers who know what they're doing, keep up with the bleeding edge plugin scene, and have generally good opinions make decisions about configuration so I can get real work done and not spend time getting bogged down in ricing and config files.
Agreed. I use to switch on and off between vim, neovim and VS Code vim-keybindings until I found AstroVim. When I use AstroVim, I can modify what little I need to knowing the base and foundation is taken care of and I can focus on what matters.
I tries LazyVim, but on every startup it nags me about version updates, and :x somehow takes 2-3 seconds extra as well. I don't live in the editor; vim is only useful to me if it starts up and quits instantly.
How much ricing have you done of the default config? Lazy loading of plugins is enabled by default— you shouldn't have to do anything. LazyVim handles lazy loading automatically; you don't need to manually configure anything. It should look like this:
-- lazy.nvim configuration example
require('lazy').setup({
defaults = {
lazy = true, -- default to lazy loading
-- other default options
},
plugins = {
{ 'neovim/nvim-lspconfig' },
{ 'hrsh7th/nvim-cmp' },
-- ... other plugins
}
})
You can disable the update checker with a very simple config change.[0]
As for :x being slow, I'm not sure what that might be, it certainly isn't the case for me, it quits instantly. Try asking around in their support channels?
The article specifically mentions following chris@machine, so I would assume that LunarVim was on their radar. But I agree, it seems odd that it wasn't mentioned in the article.
I die inside whenever I use `\<` and `\>` for word boundary regex. Neovim has no plans to change this either. I'll likely switch eventually so I don't have to know two flavors of regex. One is hard enough.
I just add `\v` (very magic) to make it interpret regex more strictly. I’ve just tested it and you don’t need to escape these anymore to match word boundaries.
To add to what sibling commenters have said, you can also configure this extension to use a specific Neovim binary on your system, and you can also configure it to use/load the same Neovim config you use when you use Neovim in the terminal. That's what I do.
It's really the better (Neo)?vim extension in my opinion, but it has a lot less installs than the other popular extension, called just "Vim" (6.656M installs vs. 400K installs) that extension AFAIK actually emulates Vim in JavaScript, I used it for about a year in 2018, before the other extension "VSCode Neovim" was released in 2019 and remember not having a good experience using it then (to compare, the extension "Vim" was released in Nov. 2015).
Yes, vscode-neovim makes VSCode's editor be Neovim. It works very well with other VSCode extensions. For example, you can type `gd` to go to the definition of a C++ identifier.
I feel like using this extension is a little
buggy. Especially around undo / redo actions being captured in “format on save” type actions that happen thanks to jslint or other tools.
Yes I've tried to use the neovim plugin many times - but always run into some annoying bug, usually due to an interaction with another extension or VSCode feature. It has >400k installs though so it must be working for some people.
Maybe you can clear up a little confusion on my part. I looked at that link and realised that for some weird reason there are two different versions of the extension by the same developer, and the one I had installed is the other one with 93K installs (not the one you linked above with 400K). What's up with that and why doesn't he just go with the better version of the extension; what are the differences?
But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me.
I still have a lot of hope for Zed.
But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.
Except, as I understand it, the collaboration features were one of the primary things they wanted to do with Zed. So this isn't a case of bloat. The first blog post on the site is "How CRDTs make multiplayer text editing part of Zed's DNA".
I always wondered are people really doing this collaboration stuff. I tried it at the start of the lock downs era. But i quickly found it annoying, but maybe its because the implementation was just bad back then.
I'm still happy with vim/nvim as daily work tools (also currently exploring kakoune and helix... because why not).
Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.
Since many here are complaining about this, I’ll jump in here to say the contrary.
I love the AI integration in Zed, it’s really smooth, pleasant to use, and well-integrated. I have a good experience pairing it with Sonnet 3.5.
The REPL feature is great as well and I totally see myself using that.
I agree on the collaboration bit though. I understand it’s one of the original premises and goals of Zed, however in order for it to really work well, I think you’d need to get everybody in your company to use Zed… which is honestly a “pretty tough” sell. I could imagine it making more sense if they had IntelliJ and VSCode plugins integrated with it, so the adoption could be more incremental.
That said, I agree that I definitely miss e.g. debugging support.
Zed also hastily went to v1. Simple things are missing such as labels to identify where a conpletion It's coming from when there are multiple completions with the same name. Also typescript types which are updated by an external process do not reflect unlike vscode.
They are now trying to do collaboration with ai to return money to investors but again nobody wants this.
That's why most editing tools should be open source and done by people passionate about it. The only company that managed to do paid editoes well is Jetbrains because their IDEs are actually much much better than the competition and much better than Zed.
I don’t follow. The collaboration features have been part of Zed from day one. The recent addition of chat feels more like something the team wanted to use itself, so they never have to leave the editor any more, not a core focus of development.
Really my own issue with Zed is the crummy TS language server integration. Everything else is fantastic.
I would like some form of built in diffing, but for simple conflicts this is fine.
Seconded. I'm loving the Zed experience, but having Javascript features provided by the TS language server gives a really bad experience; if I fat-finger a bracket then I get a bunch of TS errors about missing TS stuff littering the code, even though I'm not writing TS.
It's not a deal-breaker, but it is really annoying - I have to find the problem myself with no assistance from the language server. In fact, with hindrance from the language server because it's littering the code with completely spurious warnings of irrelevant "errors" that aren't.
I haven't tried coding in TS on Zed, so I can't comment on how the actual TS experience is.
I think the trick of text editors/note apps has become such that every few years you have to look for something else. Especially the note apps - either it dies, or bloats up, or these days more often goes subscription route ALONG WITH other negatives.
Doesn't highlight Perl so I'll pass until it does. Looks snappy otherwise. Back to VSCodium, I guess.
Collaboration, AI, chat, couldn't care less. Hopefully they can be disabled. I used Atom for a few years before they discontinued it. Yes, it was quite sluggish but otherwise it was usable, it had multiline editing and other sublime-isms, so I didn't have learn how to use an entirely new editor. If Zed can replace Sublime, Atom or VSCode for me that's great, otherwise I'll pass. I'm only using the basic code editor features, no git, no collaboration, no integrated terminal, no nonsense. Multiple cursors, PCRE matching and dark theme (preferably molokay) are a must.
There are many great editors out there, some free some not. If a newcomer wants to break into the market, they need to add something new to the table. Understandably, in this day and age, it might be AI. Plus, they need to find a way to make money, offering collaboration and AI related feature might enable that.
I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.
I explored Zed on macOS when it was posted here previously, and my impression was that it was a fast and fully-featured editor.
However, it's not as ubiquitous on *nix systems as editors such as vi/vim. And for those of us who work with various infrastructures and deployment constraints, it's much easier to focus our efforts on an editor that is also ubiquitous. And vi/vim fits that mould.
In other words, while Zed is a vi-able alternative, I doubt most vi/vim users will switch to it exclusively.
Just another +1 that if you’re going to give vscode a fair shot, it’s much better to go with vscode-neovim than the standard vim extension. You can even map most of your config right over.
I started using Zed in the last month and I had a feeling it would end up taking a lot of Neovim users. Neovim gets a lot of users who need better performance than VSCode, like me, but the config is such a pain and there was a gap in the market for a blazingly fast GUI editor which Zed looks like filling.
Supermaven still has some issues on Zed, but apart from that its been rock solid and ive fully switched from Neovim.
If you ever go back to Neovim, I’ve had a lot of fun with NVChad. I still had to configure a little bit for LSP but that’s part of the ethos - sane defaults and most stuff off by default for performance and to reduce clutter.
I have my Neovim setup the way I like it, the problem is every so often something breaks, and I have to dig back into the config and ive completely forgot how everything works. Theres just a complexity with neovim config that id rather not deal with, its a bad DX in this day and age.
I tried leaving vim for Helix but turns out it's not curated at my employer's site so I'm back to using vim. Zed would be even worse considering it's a desktop app.
There is the option of using vscode but I'm one of those aliens who absolutely dislike that program.
If your employer allows for you to build rust projects, Helix build and installation process from source is pretty straightforward, so that might be an option.
I’m with you on VSCode, I just can’t get into it. 20+ years of vim does mean there’s a lot of muscle memory I’m not willing to put aside, and last I checked (admittedly years ago), the vim plugin for VSCode was meh
Maybe you can give the neovim plugin for vscode a try. As a long time vim/neovim user who occasionally do some C# modding stuffs in vscode I find it one of the best "vim" mode plugin out there. The fact that it spawns a real neovim instance makes it working great with your existing neovim config, no need to learn how to add your custom other-than-default vim keymaps using some json config files, it just works, even for navigation plugin like leap.nvim (if my memory is correct).
Zed seems to be using its own vim emulation and config syntax is a huge caveat to me.
Over the summer I got an interest in Kakoune and Helix and discovered a number of extensions for VSCode that enable modal editing(1), but not VIM-style per default. I got excited about this and ended up writing my own extension instead.
At this point, it supports most of the VIM subset that I care about, and I have added a number of new motions and modes that do clever things based on the AST. I am kicking myself for not doing this sooner and I think I need to write up a blog post about it. It's surprisingly easy.
That's very interesting. Very cool to look at the source and see how simple it is. I may have just answered my own question, but I'm curious why you prefer this over the popular vim or neovim extensions, which have quite good coverage of vim features, and the neovim one even lets you use real neovim plugins because it is powered by a real neovim instance.
I was using the other vim extension for years. I had tried the neovim one as well a few years ago and I ran into so many bugs that I switched back after 1/2 day. I am sure it's better today, but I can see that there is still an open issue with folding, for instance.
The thing is that I used to consider headless Neovim to be the ultimate solution to "vim but with IDE conveniences" but I am no longer so sure. Keeping everything in sync between the two editors just seems like a task that's doomed to fail in many small paper-cut like ways. What I am doing now is much more like adding a few things on top but leaving VSCode in charge, letting it do its thing the way it was designed to.
Neovim has felt frustrating. I still sort of manage a Neovim configuration, but have been gradually moving to Zed as well. (Similar reasons overall.)
I think everyone has their own personal list of gripes and wants for a text editor. Here's some issues that I think many people will immediately be struck by:
- The core editing experience is still less polished than Monaco. Example: Selecting a block of spaces and striking "delete" may lead to an uneven number of characters being deleted. It seems to interact poorly with indentation.
- No settings UI (yet?).
As a Linux (and specifically NixOS) user, there's also a few other problems that I would love to have solved:
- Zed can't be configured to not auto-update, which can simply never work on immutable distros or e.g. inside of Flatpak. It just tries and fails, wasting bandwidth. https://github.com/zed-industries/zed/issues/9224
- Zed can't re-use all already-installed language servers yet, so some language servers can't be used on platforms where the auto-download feature can not work. https://github.com/zed-industries/zed/issues/4978
Overall Zed has been very nice. It definitely feels like it's still pre 1.0, but it is a very strong pre 1.0 to me. I am a bit weary on the focus on collaboration and AI features so soon, but I do realize that people actually like these features, so hopefully it's not a sign that the core editing experience is going to be neglected.
On indentation, most files are going to be autoformatted by the LSP, and there are tab_size settings in the languages section, needing specific file settings seems like an edge case.
As for collaboration and AI features, I have no use for them personally, but I think that's their avenue for future monetization, so I can't really complain that they are focussing on that when I get an amazing piece of software for free.
> On indentation, most files are going to be autoformatted by the LSP, and there are tab_size settings in the languages section, needing specific file settings seems like an edge case.
Wow, absolutely not!
Just so we're clear, when I say "per-file" settings, I don't mean in the configuration. I mean at runtime overriding the indentation settings for an open file.
This is needed for many, many cases that I definitely don't consider edge cases.
- Configuration files: Loose configuration files might be in a bespoke format with no language server to begin with. JSON and YAML files can have pretty much any indentation style, and in many cases when editing configuration files there will be no "project-specific" configuration files to read from. I use my editor of choice to edit configuration files in various places including just in my home directory.
- You are not necessarily allowed to fully reformat files in a given project, even if the project has inconsistently-formatted files. Some LSPs are cooperative with this and won't change the indentation, since not all languages have a canonical format. Auto-detection is very important here.
- Even when an LSP is being used, that doesn't mean Zed is synced up with it. The Nix LSP will use whatever nixfmt binary you are using. I'm using nixfmt-rfc-style, which uses 2-space indentation, but the default in Zed seems to be 4-space indentation for Nix files, which means that without configuration it will be out-of-sync. (Generally this would be better to just configure globally but I'm just trying to say that having an LSP in and of itself doing formatting is not a panacea.)
In almost any editor I can think of, from Vim, to Visual Studio Code, to IntelliJ, to Notepad++, to kwrite, to gedit... I can at least override the indentation style if it is wrong for some reason. In Neovim I use vim-sleuth, and my indentation settings in Vim are very rarely incorrect no matter what file I'm editing where.
Modern text editors can and should do better than this, and almost always do; being able to change the current indentation settings is something most editors support before supporting most other basic functions. It's not a weird edge case, it's just flat-out a missing basic feature.
They probably should have the option to change the tab size on an open file, but my point is, why wouldn't you have autoformatting on for YAML and JSON? You have a preference for indent size, and you want the same for every file, barring an edge case.
Edit: Yeah I see your point when you are not in control of the project and have to stick to someone elses style, I guess that only seems like an edge case to me, but could be normal for other people. In that case you would want a convenient way to override your formatting settings, like an auto detect indent button that only applies to the current open file.
To me it basically seems backwards. Of course I am not arguing against having a robust configuration for setting indentation settings, it's usually the ideal way to handle this sort of thing. However, it's ultimately still just a convenience feature; all you really need is the ability to set the indentation settings for the current buffer.
As far as editors that have automatic indentation features, Zed is definitely the first one I can think of where it had configuration for indentation settings per project/per language, but no ability to change it for the current buffer.
I'm sure in due time, it will probably gain most of these features as more people jump in and run into these problems.
Echoing similar sentiments that I'm optimistic for Zed to become more polished and stable.
Till then, Sublime Text 4 is still the best non-terminal text editor I've ever used and I continue to daily drive it. Sure its paid and non-FOSS, but its incredibly performant on Linux and Windows and its LSP extension + Sublime Merge fill the gap left by VSCode for me. Well worth the price tag IMO.
My only gripe with Sublime Text is that they've changed to a "semi subscription" license model, where licenses expire after 2-3 years, and you essentially need to buy it again after that time.
It's essentially the same model used by other editors like the Jetbrains suite, but unlike Jetbrains, updates to Sublime Text (and Merge) are few and usually don't contain much other than bugfixes.
I've faithfully purchased Sublime Text licenses since the initial versions (switched over from Textmate), but as my ST4 license recently expired, it has forced me to review just what i get for the money i pay.
ST was excellent when it first arrived, and it's still one of the fastest loading editors out there, but pretty much every other editor has more or less caught up, including free ones like Zed and VSCode, making a recurring cost harder to justify.
I'm in the same situation. The upgrade price for Sublime Text and Sublime Merge is $152 whereas the full license is $168. As you say, it feels more like a subscription model. I'd renew if the discount was bigger. I can of course continue to use the versions released while my license was valid, but it would be nice to get bug fixes and new feature while still supporting the developers.
I wouldn't mind the license fee as much if there was actually any development going on, but for the past 3-4 years, there has basically been 4-10 months between releases, and each release has been more or less bugfixes and rewrites [1]. There has been 4 updates in 3 years.
The issue tracker for ST has 1863 open issues, or 41% open vs closed issues [2], and the issue tracker for SM has 1055 open issues [3].
I have no problem paying for software, and i understand that most developers don't work for free, but with this software it doesn't even appear i'm paying for "work", and instead it appears to be more or less a passive source of income for the developer.
As i wrote earlier, i'm not entirely sure what i'm gonna do, but given the slow pace of improvements to ST, i guess i can easily wait a couple of years before updating, if ever.
I'm actually using an expired ST4 license, but as another user already mentioned, you can continue using the versions available to you while your license was active. This is fine for me because I find Sublime Text to be a better experience than VSCode and Zed.
I love ST4 but I need to do a lot of remote editing - that is, editing a project on a Linux server. VSC is the only tool I’ve used where the remote edit “works” and it also seems to constantly have problems. I’ve tried things like rmate or SSHFS but they don’t work well. Do you have any advice on a ST4 solution for this? Thanks in advance!
Does Zed support remote/containers development now? It was the major blocker for me when i tried it, so i had to retreat back to VSCode.
I’m not sure if programming is a social activity so their focus on collaboration is a little odd to me.
I’m going to somehow misuse this discussion to ask for the readership help about something: I don’t understand the appeal of VSCode or more exactly I don’t understand the appeal of the text editor propped with plugins to be a semi-IDE so I guess that would also include Neovim with plugins.
In my career, I have used text editors including vim which I still very much enjoy and both Eclipse and IntelliJ when I used to code in Java which I also enjoyed.
VSCode seems to me to be as slow than a full IDE - too slow to be a nice editor - while having less features and an inferior UI to a full IDE. I don’t get it. Is it because so many languages don’t have a good IDE so people have come to accept the subpar editor+plugin experience?
People using VS Code are writing JavaScript/TypeScript/Python that doesn't need full IDE features. And VS Code is much faster than Eclipse / IDEA kinds.
I have written Ocaml, Java, C, C++, Ada and Python professionally in my career. I either used an editor or an IDE. I had a plugin for eMacs when doing Ocaml but the experience was really subpar (that was before Merlin - yes, I’m that old).
I’m sorry but having used both. VSCode is not faster than Eclipse. It’s far less good at writing Java however.
You are not really answering my question by the way. So people are indeed using VsCode because there are no proper IDE for JS and TypeScript?
> You are not really answering my question by the way. So people are indeed using VsCode because there are no proper IDE for JS and TypeScript?
Yes, that's it. There are plugins for everything and mostly works. Not the biggest fan of it anymore tho so looking for my next IDE or develop one for my liking using AI.
It's strange that you assumed I don't work on large front-end projects rather than either asking me or sharing your own experience.
I've worked on large front-end codebases. VS Code has much better TypeScript support than IntelliJ. I'd rather this not be the case because I much prefer IntelliJ.
It's a fair question, my guess is that it's a great beginners IDE for multiple languages. You can quickly get up and running with all major languages, and it was one of the first products Microsoft made multiplatform and free. I'm neutral about it, it works fine for getting the job done. I'm a bit disappointed that it's ssh plugin craps out over 200MB of detritus on each remote machine it connects to. But the ability to edit remotely is a neat feature.
One answer may be that it’s not that slow for everyone. It could vary with the kind of computer you’re running it on, or what languages you’re using it for, or the size of the codebases.
I’ve seen people complain all the time about how slow VS Code is, and I haven’t really had that issue on an M1 Mac, at least not since some major perf work in VS Code a few years ago. And I know what a fast editor is — I’ve used Helix and minimally-configured Neovim for years.
Most discussions I've seen, including that one, say that VS Code is slower than most lightweight text editors but faster than most IDEs (including WebStorm which is IntelliJ). I don't personally have experience with IntelliJ, but in my experience VS Code is very noticeably faster than Eclipse.
That linked thread also mentions that compared to IntelliJ, VS Code has better remote development, a less cluttered UI, better support for multiple languages in one project. And _many_ people mention the better performance.
Personally, running an open-source project with a lot of contributors who are young or from third-world countries, it also matters a lot that VS Code is free.
For me, VSCode is not a great editor. It feels cobbled together and often provides a worse development experience compared to language specific IDE
HOWEVER..
It has a killer feature if you are doing remote development.
It (mostly seamlessly) presents the remote (ssh, docker, wsl) as if it was local, and I've yet to see another editor do it as well and as cleanly.
So much so that when doing remote development I'm prepared to put aside VSCode's other shortcomings for the superior remote development experience.
For local development I still use vim+terminal, but if I'm in a situation where development needs to be done on a remote machine, the VSCode vim bindings are good enough that I'll probably be using VSCode.
For remote development there is Fleet from JetBrains which is still in preview but mostly works (year ago it had a lot of issues). Nonetheless, it still needs a lot of improvements (rendering performance IME is poor, some functionality is missing in comparison to full-fledged IDEs like IntelliJ)
There is also JetBrains Gateway which allows you to run IntelliJ/PyCharm/etc. remotely. I'm using it and it is very usable, however, there are occasional bugs which could be explained by synchronization issues
Btw. Vim should be very usable over ssh (especially with tmux and maybe iTerm2/other terminal integration with tmux' control mode - tmux panes are native windows, new terminal window/tab creates new tmux window/pane etc.). Why are you using VSCode over Vim for remote development?
I kinda lost hope for fleet when it just started loading the intellij core to do all relevant stuff. I wanted that new editor so it would be faster, not so that I can have slightly different chrome.
Why don’t you have shell access? That is the minimum for doing any kind of development. And I think the vscode plugin relies on shell access to install itself (either ssh or whatever protocol for docker)
I’ve used VSCode extensively because of its flexibility, remote extension, and (decent) speed. I enjoyed IntelliJ in the past, but I encountered countless performance issues on larger projects. This could be partially due to a subpar configuration, but over time I just gave up on IntelliJ and just used VSCode because it _just worked_.
As opposed to vim it has a gui, as opposed to eclipse and intellij its language agnostic, as opposed to you they obviously dont find it too slow to be a nice editor, having an inferior ui or miss any of the features.
Contrary to that they may find the ability to shape the editor using extension pretty nice, and doesn't care for having an IDE for every language they use. Its nice being in the same environment no matter what. Also the ability to ssh to another machine to edit and run code with the same experience as it was locally (in a gui) is pretty good.
Every shoe is sub par the wellington/rubber boot experience when it is raining, but you will see that most people do not wear rubber boots. People don't generally like to maximize their choices along one axis, so what can be seen as "sub par" is actually the overall best experience.
Probably a mismatch between what I expect from an IDE and what VSCode offers then, I understand that. Every time I fire it I am always deeply disappointed by the lacklustre debugger and the lack of good refactoring tools.
I never really tried the git integration as I use git purely through the CLI and didn’t try to work on a remote code base so I might have missed the killer features.
Takes very little time to configure, new languages work with LSP in a few seconds, support for headless neovim, nice gui with good font rendering in macos, decent git integration, window management is good and can be customised to use vim bindings.
Pretty much does everything you would want whereas I have a bunch of problems with emacs and neovim that stop me using them full time. Ideally I'd use emacs but it has performance issues with my giant typescript codebase I work onfor my job.
Most of the negatives mentioned (fragility, bugs, plugins breaking often) are specific to neovim.
It's one of the reasons why I am and will always keep using vim instead of neovim.
Vim is a much more mature ecosystem, less chasing the newest "plugin du jour", my vimrc is stable, based on a few dozen plugins which are feature complete and rock solid stable.
Do you mind sharing that list of plugins you use? I have never used plugins with vim/neovim and only used them vanilla up to this point but interested in checking out the plugin ecosystem.
neovim is what happens when the javascript kids decide to "improve" one of the best editors ever created. The entire Lua ecosystem standing on 50 unstable plugins that provide the entire kitchen sink, yet do not even have a 1.0 version is nightmarish.
Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are completely antithetical to the slim, minimal philosophy of vim.
At least the original vim is still around, and the js kids are allergic to parens so there's an alternative.
I am not a JS dev, and still prefer nvim. If you’re careful with plugin choices, you can get nice QoL features and still be stable. I can’t think of a time when I’ve had nvim crash.
You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.
When I was looking for an editor that supported true color themes, neovim supported them, vim didn't. That decided what I was going to use. Stability is good, but if you need a feature that's not there - stability isn't helping.
There are no Lua kids, i.e newbie programmers that start their career from Lua. The neovim Lua kids were JS kids all along, and brought their philosophy of churn over.
I was about to make a very similar comment. I won't say I'll never switch to neovim, for a lot depends on future vim/neovim development, and unexpected things happen.
But I do agree that vim's stability is priceless. It's been years without any need for major changes in my vimrc, and without any trouble with the plugins I use.
I'm sympathetic with the author, though. Whenever you need to change, finding an alternative that "just works" always makes things easier and you can quickly get back to being productive. I'm not so sure that I wouldn't go down a similar path if the vim ecosystem collapsed.
Echoing the other replies here that idk what breakages this refers to. I switched since I liked lua better than vimscript (after writing a ton of vimscript). I don't use many plugins; the few I use haven't broken. Only encountered a single (non-serious) nvim bug that wasn't also a vim bug in many years of use.
I’m actually in the opposite camp, I had left VSCode for Zed about 6 months ago and used it exclusively at work/personal projects. I’ve customized it extensively, and loved its approach to Vim integration. But in the last two weeks I’ve made the switch to Neovim (using a customized LazyVim [0] setup). I really like Zed but as others have pointed out they are not prioritizing features around REPL’s, AI, and collaboration while many core features are lacking. Vim Cut/Copy and paste being bugged, and html tags not closing drove me crazy over time.
I think Zed is wonderful, and would perhaps go back to it after it matures a bit. For what’s its worth the friction going from Zed -> Neo vim was quite seamless, and I’d expect going the other way would as well.
A couple years ago I got really tired of maintaining my own vim configs, like the author of this piece mentions (plugins and updates causing problems). I just wanted to get out of the business of maintaining my own configs, so I decided to try a bundle, and eventually ended up on LunarVim, with a small handful of "dealbreaker" config changes. As opposed to a basic vim and then a bunch of plugins and custom configs.
I've been pretty happy with it, but other options are worth checking out (SpaceVim, NvChad, LazyVim, AstroVim).
LunarVim has finally deivered a working LSP/TreeSitter which I always only got half working or would break once I had it working, in my self-managed configs.
I kinda had the same journey as the author except that I clinged to the terminal workflow he had leave behind. Choosing a Neovim distro was the solution for me.
I had tried and failed multiple times to start using Vim (after using Vim binds for a while), and actually failed the transition right before my 6 month stint with Zed. It was actually this post[0] from the creator of Gleam [1] that brought LazyVim to my attention. I made a handle full of modifications, removing certain plugins and adding others. I'm very happy with the result. Its been two weeks of using it at both work and home productively.
330 comments
[ 2.9 ms ] story [ 300 ms ] threadAt the same time it’s been pretty frustrating to use an editor that is spending so much time building AI integrations, REPLs, and so fourth when basic things like cut and paste and common Vim motions still have so many bugs.
I’d love to see them prioritize getting the basics solid first.
I think you might be under the impression that what the GP is complaining about is having the default copy and paste go to the system clipboard.
This is not what is happening; in Vim all modifications are saved to the default register. Making the default register the system clipboard is annoying, because the following happens:
Insert a newline? Newline replaces whatever is in the clipboard.
Switch around two letters in a typo with `xp`? That text replaces the contents of the system clipboard.
Remove a word? Change a word? Add a new word? All replace the contents of the system clipboard.
Run a macro that changes things around? Nukes the system clipboard.
I don't think that 99% of developers want this behaviour. What they want is that when they explicitly copy something, it must be reflected in the system clipboard.
It's rare, in Vim, to not use commands. It is, after all, a command-oriented interface.
Any command that removes text or modifies text places the removed text into the default register.
> While I agree it’s less than ideal, at least you always know it’s going to happen if you are sort of familiar with Vim.
The problem with making the default register nuke the system clipboard is that almost all text editing commands are going to nuke the system clipboard.
I want to pay for Zed for what it is. I want to sponsor a new code editor. I have zero interest in paying for a SaaS collaborative editor.
I had seen some of the other "Neovim as IDE" projects but after looking at them carefully, I decided that LazyVim is generally the most polished one out there. Folke deserves a lot of credit.
The breakthrough for me was realising that it's a totally acceptable tradeoff to let other developers who know what they're doing, keep up with the bleeding edge plugin scene, and have generally good opinions make decisions about configuration so I can get real work done and not spend time getting bogged down in ricing and config files.
As for :x being slow, I'm not sure what that might be, it certainly isn't the case for me, it quits instantly. Try asking around in their support channels?
[0]: https://www.lazyvim.org/configuration/lazy.nvim (look for "checker" field)
Profanity.
> This extension uses a fully embedded Neovim instance, no more half-complete Vim emulation!
It's really the better (Neo)?vim extension in my opinion, but it has a lot less installs than the other popular extension, called just "Vim" (6.656M installs vs. 400K installs) that extension AFAIK actually emulates Vim in JavaScript, I used it for about a year in 2018, before the other extension "VSCode Neovim" was released in 2019 and remember not having a good experience using it then (to compare, the extension "Vim" was released in Nov. 2015).
That has generally been my experience using VSCode, unfortunately.
But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me.
I still have a lot of hope for Zed.
But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.
Thank god we still have vim and Emacs.
[1] Eight Megabytes and Constantly Swapping
(To explain and thus ruin the joke, https://www.gnu.org/fun/jokes/ed-msg.html)
Emacs has had AI since before it was cool again.
M-x doctor
Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.
I love the AI integration in Zed, it’s really smooth, pleasant to use, and well-integrated. I have a good experience pairing it with Sonnet 3.5.
The REPL feature is great as well and I totally see myself using that.
I agree on the collaboration bit though. I understand it’s one of the original premises and goals of Zed, however in order for it to really work well, I think you’d need to get everybody in your company to use Zed… which is honestly a “pretty tough” sell. I could imagine it making more sense if they had IntelliJ and VSCode plugins integrated with it, so the adoption could be more incremental.
That said, I agree that I definitely miss e.g. debugging support.
They are now trying to do collaboration with ai to return money to investors but again nobody wants this.
That's why most editing tools should be open source and done by people passionate about it. The only company that managed to do paid editoes well is Jetbrains because their IDEs are actually much much better than the competition and much better than Zed.
Really my own issue with Zed is the crummy TS language server integration. Everything else is fantastic.
I would like some form of built in diffing, but for simple conflicts this is fine.
It's not a deal-breaker, but it is really annoying - I have to find the problem myself with no assistance from the language server. In fact, with hindrance from the language server because it's littering the code with completely spurious warnings of irrelevant "errors" that aren't.
I haven't tried coding in TS on Zed, so I can't comment on how the actual TS experience is.
Collaboration, AI, chat, couldn't care less. Hopefully they can be disabled. I used Atom for a few years before they discontinued it. Yes, it was quite sluggish but otherwise it was usable, it had multiline editing and other sublime-isms, so I didn't have learn how to use an entirely new editor. If Zed can replace Sublime, Atom or VSCode for me that's great, otherwise I'll pass. I'm only using the basic code editor features, no git, no collaboration, no integrated terminal, no nonsense. Multiple cursors, PCRE matching and dark theme (preferably molokay) are a must.
I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.
However, it's not as ubiquitous on *nix systems as editors such as vi/vim. And for those of us who work with various infrastructures and deployment constraints, it's much easier to focus our efforts on an editor that is also ubiquitous. And vi/vim fits that mould.
In other words, while Zed is a vi-able alternative, I doubt most vi/vim users will switch to it exclusively.
E.g. (mine) https://github.com/tom-pollak/dotfiles/tree/master/nvim
Supermaven still has some issues on Zed, but apart from that its been rock solid and ive fully switched from Neovim.
There is the option of using vscode but I'm one of those aliens who absolutely dislike that program.
Zed seems to be using its own vim emulation and config syntax is a huge caveat to me.
At this point, it supports most of the VIM subset that I care about, and I have added a number of new motions and modes that do clever things based on the AST. I am kicking myself for not doing this sooner and I think I need to write up a blog post about it. It's surprisingly easy.
1. e.g. https://marketplace.visualstudio.com/items?itemName=DCsunset...
The thing is that I used to consider headless Neovim to be the ultimate solution to "vim but with IDE conveniences" but I am no longer so sure. Keeping everything in sync between the two editors just seems like a task that's doomed to fail in many small paper-cut like ways. What I am doing now is much more like adding a few things on top but leaving VSCode in charge, letting it do its thing the way it was designed to.
I think everyone has their own personal list of gripes and wants for a text editor. Here's some issues that I think many people will immediately be struck by:
- Zed does not yet support EditorConfig. https://github.com/zed-industries/zed/issues/8534
- Zed does not yet support auto-detecting indentation in the current file. https://github.com/zed-industries/zed/issues/4681
- Zed does not yet support configuring indentation in the current file. (edit: clarified wording) https://github.com/zed-industries/zed/issues/4867
- The core editing experience is still less polished than Monaco. Example: Selecting a block of spaces and striking "delete" may lead to an uneven number of characters being deleted. It seems to interact poorly with indentation.
- No settings UI (yet?).
As a Linux (and specifically NixOS) user, there's also a few other problems that I would love to have solved:
- Zed can't be configured to not auto-update, which can simply never work on immutable distros or e.g. inside of Flatpak. It just tries and fails, wasting bandwidth. https://github.com/zed-industries/zed/issues/9224
- Zed can't re-use all already-installed language servers yet, so some language servers can't be used on platforms where the auto-download feature can not work. https://github.com/zed-industries/zed/issues/4978
- Zed doesn't really integrate well with direnv. VSCode is in the same boat, but Vim is not. https://github.com/zed-industries/zed/issues/4977
Overall Zed has been very nice. It definitely feels like it's still pre 1.0, but it is a very strong pre 1.0 to me. I am a bit weary on the focus on collaboration and AI features so soon, but I do realize that people actually like these features, so hopefully it's not a sign that the core editing experience is going to be neglected.
As for collaboration and AI features, I have no use for them personally, but I think that's their avenue for future monetization, so I can't really complain that they are focussing on that when I get an amazing piece of software for free.
Wow, absolutely not!
Just so we're clear, when I say "per-file" settings, I don't mean in the configuration. I mean at runtime overriding the indentation settings for an open file.
This is needed for many, many cases that I definitely don't consider edge cases.
- Configuration files: Loose configuration files might be in a bespoke format with no language server to begin with. JSON and YAML files can have pretty much any indentation style, and in many cases when editing configuration files there will be no "project-specific" configuration files to read from. I use my editor of choice to edit configuration files in various places including just in my home directory.
- You are not necessarily allowed to fully reformat files in a given project, even if the project has inconsistently-formatted files. Some LSPs are cooperative with this and won't change the indentation, since not all languages have a canonical format. Auto-detection is very important here.
- Even when an LSP is being used, that doesn't mean Zed is synced up with it. The Nix LSP will use whatever nixfmt binary you are using. I'm using nixfmt-rfc-style, which uses 2-space indentation, but the default in Zed seems to be 4-space indentation for Nix files, which means that without configuration it will be out-of-sync. (Generally this would be better to just configure globally but I'm just trying to say that having an LSP in and of itself doing formatting is not a panacea.)
In almost any editor I can think of, from Vim, to Visual Studio Code, to IntelliJ, to Notepad++, to kwrite, to gedit... I can at least override the indentation style if it is wrong for some reason. In Neovim I use vim-sleuth, and my indentation settings in Vim are very rarely incorrect no matter what file I'm editing where.
Modern text editors can and should do better than this, and almost always do; being able to change the current indentation settings is something most editors support before supporting most other basic functions. It's not a weird edge case, it's just flat-out a missing basic feature.
"languages": { "JSON": { "tab_size": 4 }, "JSONC": { "tab_size": 4 }, "YAML": { "tab_size": 4 } }
Edit: Yeah I see your point when you are not in control of the project and have to stick to someone elses style, I guess that only seems like an edge case to me, but could be normal for other people. In that case you would want a convenient way to override your formatting settings, like an auto detect indent button that only applies to the current open file.
As far as editors that have automatic indentation features, Zed is definitely the first one I can think of where it had configuration for indentation settings per project/per language, but no ability to change it for the current buffer.
I'm sure in due time, it will probably gain most of these features as more people jump in and run into these problems.
Till then, Sublime Text 4 is still the best non-terminal text editor I've ever used and I continue to daily drive it. Sure its paid and non-FOSS, but its incredibly performant on Linux and Windows and its LSP extension + Sublime Merge fill the gap left by VSCode for me. Well worth the price tag IMO.
It's essentially the same model used by other editors like the Jetbrains suite, but unlike Jetbrains, updates to Sublime Text (and Merge) are few and usually don't contain much other than bugfixes.
I've faithfully purchased Sublime Text licenses since the initial versions (switched over from Textmate), but as my ST4 license recently expired, it has forced me to review just what i get for the money i pay.
ST was excellent when it first arrived, and it's still one of the fastest loading editors out there, but pretty much every other editor has more or less caught up, including free ones like Zed and VSCode, making a recurring cost harder to justify.
The issue tracker for ST has 1863 open issues, or 41% open vs closed issues [2], and the issue tracker for SM has 1055 open issues [3].
I have no problem paying for software, and i understand that most developers don't work for free, but with this software it doesn't even appear i'm paying for "work", and instead it appears to be more or less a passive source of income for the developer.
As i wrote earlier, i'm not entirely sure what i'm gonna do, but given the slow pace of improvements to ST, i guess i can easily wait a couple of years before updating, if ever.
[1]: https://www.sublimetext.com/blog/
[2]: https://github.com/sublimehq/sublime_text/issues
[3]: https://github.com/sublimehq/sublime_merge/issues
https://github.com/zed-industries/zed/issues/5394
In my career, I have used text editors including vim which I still very much enjoy and both Eclipse and IntelliJ when I used to code in Java which I also enjoyed.
VSCode seems to me to be as slow than a full IDE - too slow to be a nice editor - while having less features and an inferior UI to a full IDE. I don’t get it. Is it because so many languages don’t have a good IDE so people have come to accept the subpar editor+plugin experience?
People using VS Code are writing JavaScript/TypeScript/Python that doesn't need full IDE features. And VS Code is much faster than Eclipse / IDEA kinds.
I’m sorry but having used both. VSCode is not faster than Eclipse. It’s far less good at writing Java however.
You are not really answering my question by the way. So people are indeed using VsCode because there are no proper IDE for JS and TypeScript?
Yes, that's it. There are plugins for everything and mostly works. Not the biggest fan of it anymore tho so looking for my next IDE or develop one for my liking using AI.
When you project your own experience over everyone else's it doesn't seem like you genuinely want to understand.
I've worked on large front-end codebases. VS Code has much better TypeScript support than IntelliJ. I'd rather this not be the case because I much prefer IntelliJ.
I’ve seen people complain all the time about how slow VS Code is, and I haven’t really had that issue on an M1 Mac, at least not since some major perf work in VS Code a few years ago. And I know what a fast editor is — I’ve used Helix and minimally-configured Neovim for years.
https://www.reddit.com/r/webdev/comments/1euwht3/webstorm_is...
Most discussions I've seen, including that one, say that VS Code is slower than most lightweight text editors but faster than most IDEs (including WebStorm which is IntelliJ). I don't personally have experience with IntelliJ, but in my experience VS Code is very noticeably faster than Eclipse.
That linked thread also mentions that compared to IntelliJ, VS Code has better remote development, a less cluttered UI, better support for multiple languages in one project. And _many_ people mention the better performance.
Personally, running an open-source project with a lot of contributors who are young or from third-world countries, it also matters a lot that VS Code is free.
Even IntelliJ is noticably faster than Eclipse. This is a heavy indictment of Eclipse, not any other editors.
HOWEVER..
It has a killer feature if you are doing remote development.
It (mostly seamlessly) presents the remote (ssh, docker, wsl) as if it was local, and I've yet to see another editor do it as well and as cleanly.
So much so that when doing remote development I'm prepared to put aside VSCode's other shortcomings for the superior remote development experience.
For local development I still use vim+terminal, but if I'm in a situation where development needs to be done on a remote machine, the VSCode vim bindings are good enough that I'll probably be using VSCode.
There is also JetBrains Gateway which allows you to run IntelliJ/PyCharm/etc. remotely. I'm using it and it is very usable, however, there are occasional bugs which could be explained by synchronization issues
Btw. Vim should be very usable over ssh (especially with tmux and maybe iTerm2/other terminal integration with tmux' control mode - tmux panes are native windows, new terminal window/tab creates new tmux window/pane etc.). Why are you using VSCode over Vim for remote development?
Who's to say you have shell access to the remote instance?
Contrary to that they may find the ability to shape the editor using extension pretty nice, and doesn't care for having an IDE for every language they use. Its nice being in the same environment no matter what. Also the ability to ssh to another machine to edit and run code with the same experience as it was locally (in a gui) is pretty good.
Every shoe is sub par the wellington/rubber boot experience when it is raining, but you will see that most people do not wear rubber boots. People don't generally like to maximize their choices along one axis, so what can be seen as "sub par" is actually the overall best experience.
I never really tried the git integration as I use git purely through the CLI and didn’t try to work on a remote code base so I might have missed the killer features.
Pretty much does everything you would want whereas I have a bunch of problems with emacs and neovim that stop me using them full time. Ideally I'd use emacs but it has performance issues with my giant typescript codebase I work onfor my job.
Plug 'alvan/vim-closetag' Plug 'ap/vim-buftabline' Plug 'davidhalter/jedi-vim' Plug 'dense-analysis/ale' Plug 'dstein64/vim-startuptime' Plug 'itchyny/lightline.vim' Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': { -> fzf#install() } } Plug 'junegunn/fzf.vim' Plug 'junegunn/vim-peekaboo' Plug 'machakann/vim-swap' Plug 'markonm/traces.vim' Plug 'mhinz/vim-signify' Plug 'preservim/nerdtree' Plug 'preservim/tagbar' Plug 'romainl/vim-cool' Plug 'simnalamburt/vim-mundo' Plug 'tpope/vim-characterize' Plug 'tpope/vim-commentary' Plug 'tpope/vim-fugitive' Plug 'tpope/vim-repeat' Plug 'tpope/vim-rhubarb' Plug 'tpope/vim-sensible' Plug 'tpope/vim-speeddating' Plug 'tpope/vim-surround' Plug 'vimwiki/vimwiki'
Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are completely antithetical to the slim, minimal philosophy of vim.
At least the original vim is still around, and the js kids are allergic to parens so there's an alternative.
You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.
I don't think that's accurate. Now, if OTOH you said "the Lua kids" then I'd probably agree.
But I do agree that vim's stability is priceless. It's been years without any need for major changes in my vimrc, and without any trouble with the plugins I use.
I'm sympathetic with the author, though. Whenever you need to change, finding an alternative that "just works" always makes things easier and you can quickly get back to being productive. I'm not so sure that I wouldn't go down a similar path if the vim ecosystem collapsed.
Granted I have a 10+ year old vimrc and rarely add new plugins, but saying Neovim is fragile is nonsense. Don’t install every new plugin perhaps?
In my experience Neovim is very reliable, even when building off `master`, which I did for a couple of years.
It's true that Neovim leans more towards more changes and thus more risk of bugs, but claiming that Neovim is unstable is unfounded.
I think Zed is wonderful, and would perhaps go back to it after it matures a bit. For what’s its worth the friction going from Zed -> Neo vim was quite seamless, and I’d expect going the other way would as well.
0: http://www.lazyvim.org/
I've been pretty happy with it, but other options are worth checking out (SpaceVim, NvChad, LazyVim, AstroVim).
LunarVim has finally deivered a working LSP/TreeSitter which I always only got half working or would break once I had it working, in my self-managed configs.
I kinda had the same journey as the author except that I clinged to the terminal workflow he had leave behind. Choosing a Neovim distro was the solution for me.
Then I have some sad news for you. :(
https://github.com/LunarVim/LunarVim/discussions/4518#discus...
I guess concentration of efforts in this espace is a good idea.
0: https://lpil.uk/blog/what-i-use-2023/#software
1: https://gleam.run/