Zed is our office
113 comments
·November 13, 2025verdverm
I really really don't want comms or multiplayer tools in my IDE.
Don't bring the attention economy to my cave of solitude, it's where I go to escape all that noise
Octoth0rpe
I _really really_ want to try this feature, but only if I can selfhost the collaboration server. If there is any way to do this, it's not obvious. Given that as I understand it, lots of project details will pass through Zed's servers, I can't imagine any enterprises would knowingly allow this without some kind of SLA with Zed.
nixpulvis
It could be easier, but it is supported AFAIK: https://github.com/zed-industries/zed/issues/8260#issuecomme...
mikaylamaki
Unfortunately, we no longer support self hosting. We're planning on reintroducing it once we've polished the single player experience a bit more :)
nixpulvis
Oh, that's unfortunate. Why not support it at all, even if just for people who are kinda hacking it in?
Octoth0rpe
Thanks for the update. Can't wait to hear more!
sunnyps
> Despite attempts to make Atom—an Electron application—more responsive, it never reached the performance standards the team yearned for.
This feels like an attempt at deflecting blame. VSCode is another Electron application that ended up having better performance than Atom. There's another Electron adjacent application that has good performance, the one you're probably using right now to read this page.
Depending on page content of course
kriops
What are you saying here? It is true that VS Code is less bad in terms of responsiveness in comparison to Atom. Zed, however, is written in Rust (i.e., not Electron), and I would guess it is at least an order of magnitude more responsive than VS Code across every possible scenario.
Web technologies are an unrivaled technological marvel for what they are, but it is disingenuous to imply they represent anything near the peak of what we are capable of in the context of performance.
IshKebab
It depends. It definitely opens faster and the general UI seems a bit faster, but open a largish file (a few MB) and VSCode will easily out-perform Zed because it doesn't have that fancy CDRT thing.
In my experience VSCode is plenty fast. Use it with no extensions and you will have zero problems with performance (though memory use isn't great). The real problems come when you have extensions, especially because it's often impossible to attribute performance issues to them because they can often do a lot of work all in the same "extension host" process.
travisgriggs
I like Zed. I pay for pro. I like the integrated agent stuff (though my usage model has changed a bit after 5 months of use).
I'm happy that others can type in each others' space, but this post reveals a tension here. They are building a tool for building the tool, and their own team. I think that's cool, but at a 2-3 person shop heavy polyglotted across 4 OSes and 5+ programming languages, this is not what I really need.
What I'm looking for is a snappy tool (check) that lets me explore, understand, modify code at a next level (marginal). And I want it to not only be snappy by virtue of execution efficiency, but cognitive load. I want the less-is-more experience. I don't need it to do Swift, Kotlin, or Python, because there are bespoke IDEs for each of those that focus on the environments where I deploy them best. What I mostly want from Zed is the ability to see the outline panel at the same time as the directory panel, and to separate the search outline from the file structure outline. I spent too much time toggling views in Zed.
olejorgenb
> What I mostly want from Zed is the ability to see the outline panel at the same time as the directory panel
You can do this now by moving one of them to the right dock (right-click the toggle-button)
bitbasher
Maybe I'm old, jaded, stubborn and paranoid, but something about a coding editor that is controlled by a company is off-putting to me. It's even more off-putting when you add Zoom, Slack and everything else into said editor.
tracker1
These are definitely some interesting features, though not sure I'm in any position to take advantage of them at all.
The multi-user editing is kind of cool... there's an ANSI art tool (PabloDraw) that you can run a host session so multiple artists can create text art, and I thought back when I first saw it, that it might be cool to be able for multiple editors to work on a project. I've used some of the collab stuff with VS Code, but haven't done enough to even begin to compare.
Not to mention that in a lot of workplaces, self-hosting or otherwise layers of bureaucracy stand in the way.
nixpulvis
I would love to see collab servers take the same path as LSPs in being standarized and integrated across various editors and IDEs. I would love to work more closely with my VSCode peers, for example. Of course some features may be outside the standard and only supported with likewise editors, e.g. voice chat perhaps, but having shared cursors and a text chat would be a good start.
bluehatbrit
This is what I'd like to see as well. These collaboration tools are really good, but I barely use them because they always assume that you and your team are using the same editor. Most of the time that's just not the case, so I've used them a handful of times but beyond that there's little opportunity.
It's probably not an issue the Zed team will experience as they're all naturally using their own editor. Hopefully it's on their radar though.
wateralien
Zed is lovely and I hope it becomes super successful but this kind of mass collaboration might be ok for meeting minutes... maybe. But thinking of it for coding it gives me shingles. Code by mass live committee. Yikes.
meowface
I think it's a fun and interesting idea for training junior engineers and possibly for other use cases. Suggesting alternatives to (perceived) bad practices the instant you see them could be helpful for many people, and also save a lot of future time for reviewers.
I could also see it as a potential productivity aid. Person 1 sees Person 2 is writing something and they don't want to be seen as idle, so they start working as well. This might sound oppressive but a lot of people who struggle with ADHD/procrastination/akrasia actually receive great benefit from that structure. Similar to that startup that forces you to code while screensharing with a stranger in order to push you to work, or people who code in cafes/libraries to be more productive.
As long as it's not an organization requiring it for senior engineers, I could see promise to it as an eventual common new paradigm.
nixpulvis
Pair programming can be really great. Or horrible. Depends entirely on the people.
This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.
davnicwil
> code-walks
it's probably subjective, but I find these collaboration features can be overused for this kind of thing.
If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.
I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.
nixpulvis
Problem is video is expensive and compression can get bad.
I agree being able to see the pointer is important, since not everyone is good about moving the cursor around.
xpe
> Code by mass live committee. Yikes.
Let's lean into the chaos and see what it might give us. Imagine a production application deployed directly from a non-version-controlled directory. Anyone on the team can edit the files, at any time. Insane? Probably. The disadvantages are easy to see.
But the positives are really compelling: 1. make small, granular testable changes; 2. use feature toggles; 3. refactor intensely and concurrently; 4. always work on the latest code; 5. use in-code documentation instead of GitHub/etc workflows; 6. explore continuous, incremental, hot-swappable code deployment.
Doesn't thought of ditching all the wasted motion and ceremony around logging async work and just coding sound glorious? I'm actually not a "move fast and break things person" usually. But the idea of moving so fast that broken things will only stay broken for a tiny fraction of the time is pretty compelling. There is also an intensity that comes from real-time interactions where a team needs to reach consensus quickly.
Feature Toggles: https://martinfowler.com/articles/feature-toggles.html
BEAM (Erlang, Elixir) provides hot-swappable code and lots more
drcongo
It's just pair programming when you're doing it on code so if you can bear pair programming you'll be fine. Personally, I hate it.
electroly
Pair programming usually has a single "driver" on the keyboard to keep things controllable. Here, everybody is driving: "dozens of cursors are concurrently editing the same file in real-time."
vablings
The concept of sharing and taking turns has been lost on the software engineer here....
a-dub
my understanding is that this is the dynamic in modern college classrooms. everyone opens a big shared google doc for notes and they all collaboratively edit a set of notes in real-time.
or at least that's what i've heard, no idea if they actually do it.
it is nice to see a crdt backed editor tool for markdown and code though. gdocs markdown support has been lacking for years.
riffraff
a few years ago our company used Screenhero which allowed editing with multiple cursors while screensharing.
The experience was actually quite nice for two-three people but we always had the "ok let me type now" flow. Multiple changes happening at once sounds hyper distracting.
drcongo
That's not how they, or anyone else, uses it on code though - that's on their notes. This is just a feature, it's up to you how you use it.
sph
The metaphorical infinite monkeys on typewriters.
wateralien
Actively programming in pairs (or more) is also not for me. Reviewing work async is great IMO though.
xpe
Yeah, people are different, but a lot of this difference results from various constraints, such as cultural practices around collaboration or technological options. Many of these limitations probably shouldn't be locked in by our tools or norms.
When learning a new way of thinking or moving (i.e. martial arts) people often really benefit from high-bandwidth, low-latency, shared-viewport-onto-reality interactions. Watching someone's cursor move while they talk is one way to get a window into their problem-solving toolkit.
Redster
It would have been good to include a link to the collaboration docs https://zed.dev/docs/collaboration in the article. There were a lot of links in that article and a lot of assumptions that I knew how things worked. And I daily drive and like Zed, but I had so many questions.
conradev
If you've been a developer long enough, you might recall the teletype package for Atom—both built by Zed's founders.
Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for Hydra 1.0.1, a Rendezvous-based text editor that enables multiple people to contribute to a shared document. (Adam and about ten other attendees at MacHack used Hydra to take notes during this year’s Hack Contest.)
https://en.wikipedia.org/wiki/SubEthaEdit
https://tidbits.com/2003/06/30/apple-announces-design-awards...
mikaylamaki
People have been doing collaborative text editing since the 60s actually! See, The Mother Of All Demos[0], referenced in our first blog post[1] :D
I'd say CRDTs are also a big change. CRDTs make live collaboration much more robust for all parties involved, and they only started to reach maturity in the mid-late 2010s
Aurornis
SubEthaEdit was a very inspiring software project for me. The fact that a small team could, in a few months, produce an amazing app that solved real problems and gained notoriety was amazing.
As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster. I'm also a fan of Zed and everything they're doing, but it's notable that shipping next-gen editor software takes a lot more developer effort now than it did in the 2000s.
leetrout
> it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.
Yes I agree but so many things that might seem "done" (and in someways I think software/SaaS as an ecosystem is "done" compared to where we came from).
BUT - so many companies just bloat themselves and their products. I think the end of ZIRP is going to have an effect on that (more enshitification / rent seeking for sure) and I think there will be an opportunity to iterate and make copyware that doesn't take the higher development efforts.
We really need a winning electron alternative that is more resource friendly. That, IMO, will be a big game changer and I know there are lots of promising alternatives already.
xpe
> but it's notable that shipping next-gen editor software takes a lot more developer effort now than it did in the 2000s.
Yes, the scope increase is vast, due to more languages, more tooling, more features, higher expectations, and more competition.
sandbags
I'd forgotten all about it but SubEthaEdit was such an amazing tech when we were using to collaborate internationally back in about '04. It went off my radar but I am glad to see its still available as a free app.
animeshjain
I tried the collaborative features to pair program with a colleague a few months ago, but it was bad. It was very flaky in establishing a connection. In the cases we were able to establish a connection, the voice chat would not work. We tried to make it work for a couple of days, and then we gave up. Has there been lots of work in the past few months on the collaborative features?
I generally like what Zed is trying to become. However, all of these features and blog posts are frustraing when they struggle to keep basic editor features stable. Edit a file outside of the editor? It's not going to show up in the project pane or the git diff. Need to work inside a container because it's 2025 and we don't need to clutter our local machine with 100s of dependencies and env managers... well now all the AI stuff is broken. ACP sounds cool until you realize every single CLI in existence works better.
My wish is that Zed gets the core working correctly 100% of the time before moving on to expanding feature sets. For now I'm back in NeoVIM because it always works the first time....
https://github.com/zed-industries/zed/issues/38109
Hopefully soon I can give it another shot at full time usage.