Between Editors and IDEs, Where Zed Falls
March 13th, 2024
This is my fourth conversation with Zed's three co-founders Nathan, Max, and Antonio. Read the previous one here.
This time we talked about the product philosophy behind Zed, where it falls between editor and IDE, whether it's leaning more towards Emacs or Vim, what the founders would never add to Zed, how they decide what's a Zed thing and what isn't, how they think about extensions and scriptability. We also got an answer to whether coffee machine support will land in Zed.
What follows is an editorialized transcript of an hour long conversation. I tried to preserve intent and meaning as much as possible, while getting rid of the uhms, the likes, the you-knows, and the pauses and course-corrections that make up an in-depth conversation.
(You can watch the full conversation on our YouTube channel.)
Thorsten: Where do you think Zed falls on a spectrum between IDE and editor, between, say, Visual Studio and Nano? And where should it land?
Nathan: I mean, IDEs have always had a certain connotation for me that comes from IDEs I've used in the past, which is they have a lot of features, but you always seem to have to pay for those features in the form of either sluggish UI or a cluttered UI or both.
Seems like maybe JetBrains has done a better job streamlining the look of their UI, but it still doesn't feel quite as fast as the vibe I would get in what traditionally I would call an editor. So something like Vim or, back in the day, TextMate. I just remember, early in my career, the contrast between writing Ruby in TextMate where, you know, there wasn't a lot of help, but it was at least fast. And then eventually adopting RubyMine or whatever and getting all that power, but just being so frustrated with the latency.
So it's always been this trade-off. And my dream has always been to have both, to have a tool that was incredibly powerful, but also had a sleek minimal vibe and was super fast. Super fast and this power are tough to combine.
I mean I sort of spent like most of my career trying to get to the point where we could combine them. But that's the goal.
But I always want to err on the side of minimalism in the UX and the analogy I use was the Model S Teslas. You walk up to them and the door handle like pops out of the side. It's tucked away when it's not needed or when it would create drag, but available at just the right moment. That's the dream.
Thorsten: Performance and as many features as possible, but not at the cost of performance or minimalism, or bloat.
Nathan: Yes, not at the cost of slowness and noise. Keep my code front and center and don't introduce latency between the fundamental act that I'm trying to achieve, which is editing that code. That fundamental experience needs to be fast, no matter what.
Antonio: My first programming language that I picked up was C#. I used to be a windows user. So I remember opening Visual Studio, not Visual Studio Code, but OG Visual Studio and they had this loading screen because the startup time was so slow. That was probably Visual Studio 2005, loading, you know, DLL one, two, three, blah, blah.
And same as Nathan, the contrast from that to using, I think it was TextMate that I used after that, that was insane.
I think the distinction between IDE and Editor, I don't know, I haven't really thought about why it exists. I would love to have all the features of an IDE and I think it is possible for an editor to have all those features. The theory I have, and I just formulated this theory so it's not very well thought through, is that it is possible to combine them all. My sense is that those slow IDEs are just the result of tacking things on, adding things on top, bolting them on. "Oh, we could have this feature. Okay, let's add it. We could have this other feature, okay let's add it."
Then you end up with a list of check boxes and things that are not really integrated with one another. So you have all these features, but they're not thought through vertically.
I don't know if that's true or not, but that's always the impression I had. "Oh, let's add another check box." But that's not really the vibe we're going for with Zed.
Thorsten: Maybe this was a trick question because this line between IDE and editor — it's not that clear cut anymore, is it? 10 years, 15 years ago, you had Nano: no language-aware features, not even syntax highlighting. Then Visual Studio on the other side. But now with language servers, tree-sitter, and all of this stuff that you can plug into editors things have changed and I guess the interesting bit is: where do we want to land? Like you said Nathan, which trade-offs do we wanna make and what things will we not adopt that an IDE has or what things do we wanna adopt?
Max: The situation has improved a lot since the time when there was a really big distinction between editors and IDEs. I think the language server protocol helped a lot. tree-sitter helped some of the editors to be smarter than and have a basic awareness of syntax.
I think the architecture we have, where the editor has syntax awareness and for semantic understanding calls out to a language server that is not coupled to any one editor, that's a pretty good architecture.
When people say "editor vs. IDE" and, usually in the editor camp, they're talking about Vim and Emacs as the quintessential editor, but even those tools now have LSP support and tree-sitter inside so I kind of think we're converging on a better design where editors have syntax awareness. Not just Zed, but editors in general.
But I still think there's improvements to be made. One UX thing that I still enjoy in IDEs, even though it wouldn't make me use them, is the act of renaming a variable. In IntelliJ it highlights all the occurrences and it's like you're live editing the names in the other places. I remember that being the thing in my mind when we implemented renaming-functionality in Zed. That's a pretty cool thing that they do with all their built-in language analysis and we explored doing it.
We do have this combination of syntax-awareness with tree-sitter and a rename call that we can send to a language server. And for the most part, that's a pretty good, gives you what you want. It doesn't quite let us do all the fancy stuff that IDEs do, but maybe there's room for expanding what tree-sitter can do and what the language server could do to let us do things like that. Nicer.
Thorsten: Say performance wasn't an issue and, to use Nathan's analogy, everything could be tucked away. Is there anything that comes to mind from the IDE world that you would never add to Zed because you think it does not fit in here? As in: "This is not a Zed thing, this is an IDE type of thing."
Nathan: Not that I can think of. The term IDE just always seemed weird to me. I get the distinction, but I don't know, it's a code editor. You're just trying to get work done as, yeah, I guess. So what does it mean to integrate the development environment?
I guess, one thing we're adding and that a lot of IDEs don't do a good job integrating into the development experience is the fact that other people exist and that we're collaborating. So I think we're kind of continuing that IDE vision by integrating yet more concerns.
Cause that's the idea of an IDE, right? It's not like I edit over here and then I got my terminal and I'm switching back and forth and I'm using this like hodgepodge of tools. It's all combined into one experience. And so I think collaboration could be included in that. But no, the only thing I want to ditch from IDEs is the slowness and the buttons everywhere. Yeah.
Max: All the buttons. Buttons everywhere.
Thorsten: There's another spectrum of editors: on one end there's Emacs and on the other end there's Vim. There's multiple in between of course, but Emacs on one end, to me, means: the editor as the operating system. You have this one thing and you do everything in there. That's the force multiplier. Because you are always in Emacs and your shell is in Emacs, your compiler runs in Emacs, your emails, your coffee machine, everything's in Emacs. That means you never have to leave it and you're much more productive, right? Writing emails, cooking coffee. Vim on the other hand... There was this article, I think it was by now, 10 years ago, and in it they were saying, Unix is the IDE and Vim is one tool in this environment of other tools. That's where its power comes from. It's just one of many tools. So when you're saying that you want to integrate more, does that mean you're tending more towards the Emacs side of things and say the power comes from us putting more stuff into Zed, for example, collaboration?
Nathan: Yeah, I mean, I don't want to... I want to surface the fact that a command line exists and I like that world. I hate the world in which there's some esoteric project file that has all of the details. That's very Xcode, right? Where there's an Xcode proj or whatever, and everything is done via point and click. That I don't want.
I don't want to replace the command line experience with buttons. Like that I don't think is a big deal. I like being close to the machine and communicating with the machine linguistically. I want the IDE to be aware of and integrated cleanly with the fact that there is a terminal and there is a command line and avoid the state where we try to define everything in this visual paradigm. Being a natural outgrowth of Unix, the Unix philosophy and complements, I think that's more my speed.
But if I can hit a single key binding instead of switching to the terminal, hitting up and hitting enter to run a test (which is what Kirill and Piotr are working on)? I'll take it, but I don't want it hidden from me, the fact that that's just running a command.
Thorsten: That's a good distinction. That might also be one thing that I associated with IDEs: you just boot it up and then you hit that green play button and you don't know what happens, but somebody told you this is how you run it. And then when something goes wrong, you don't know what exactly happened there.
Nathan: I like that bare bones vibe, but just being productive in it. I don't want magic.
Max: I don't want to abstract away, like Nathan said, I don't think we want to abstract away things like Git and cargo test, but I also think there's times when the most efficient way to use a tool is not through the command line, I think. I'm a little skeptical of the Unix as the IDE vision, where the fastest possible user experience for anyone, no matter how good their muscle memory is, is to shell out to. If they want to look up something, shell out to do a command line search for it. I think that often we're gonna, by integrating into the tool, you can kind of have a faster keyboard driven workflow than anything you can do with like a terminal editor running in a terminal.
Nathan: But I don't think we're gonna be building an email client into Zed. I could see building an email client in GPUI because they all drive me crazy. I mean, it's definitely not at the top of the list and...
Max: I can see a coffee machine.
Antonio: Hahaha
Nathan: ...I would be very careful before adding things because I would worry they would dilute our focus. So if Zed would become extensible enough such that someone could build an email client, like cool. But that seems like a ways out and not our priority at all. Our priority is writing software.
Thorsten: How do extensions fit in? Because I think there might be the danger of extensions ruining this concept where you add so many extensions and people say, this is now slow, there's like 15,000 buttons in the UI and then every company has a Zed default plugin configuration and we end up with, you know, 50,000 buttons and it takes 30 seconds to boot up. How do you see extensions coming into this?
Max: I don't wanna say there's anything that we won't let extensions do, but our first several milestones with extensions are more about plugging into existing Zed features and, obviously the first one, adding languages.
But we're also adding this task system and extensions that help you discover tasks to run and expose them to you. That's an existing workflow all users of Zed have and the extension enriches. There's a lot of mileage we can get out of that. Or, you know, extensions letting you script workflows that are unique to you, like opening files, looking for certain types of code in certain files, doing things with your cursor in certain files, making edits that personally make you more productive. That's my priority with extensions right now, and less adding any new UI or building an email client.
Building a concept that doesn't even exist in Zed using extensions, I think that's something we may do, but it's not gonna be like with Atom, where, from the start, everything was an extension. Everything we did had to be doable as an extension, it's a different approach than that.
Nathan: I don't think that having a lot of extensions has to be slow, but that is going to involve carefully engineering the APIs and how we run extensions. They're going to be running isolated in their own WebAssembly runtime on their own thread. I do think if we ever put an extension, and I don't know that we ever will, but if we ever did, say we would put an extension on the critical path of typing, so that maybe it could inspect every character you were inserting and do something. I would always want to, if we ever did that, put a deadline around it. I think I've talked about this in other scenarios, that there are explicit performance bounds that the extension author has to hit or we just like disable the extension. So I think there are ways.
Now, when you're saying thousands of buttons, that's another matter. But again, when we add those extension points where we allow buttons to be surfaced, that's gonna require us thinking pretty carefully about how to tuck those things away and avoid chaos. But at least from performance, like the problem with Atom, we just ran people's extensions on the main thread. Goodbye, performance. We're not gonna make that mistake again.
Antonio: One could say a lot of things about macOS APIs and, you know, I certainly could say a lot of things about Mac OS APIs — interacting with them is a nightmare sometimes — but think about an iPhone and an application on an iPhone: there's no way you can go in the home screen and kind of clutter the base experience, right? I really like that. You have a lot of flexibility, right? But it's in places where don't degrade the overall experience.
So like Nathan was saying, it's gonna be not only an engineering effort, I think also a UX effort of understanding what those extension points are, what those seams are and where to plug them. But I like the idea of doing it the Apple way.
Thorsten: That's really hard, no? The easy way, which would still be hard, would be to just restrict a lot of things and say extensions can only do this and this and that. But Nathan, you mentioned it last time, that we do want something like scriptability, right? And we do have things like tree-sitter, which allow you to really, in a nice way, modify the code or script around it. So do we wanna expose some of that, but isn't that really hard, to find that exact spot where you give enough power without the whole thing falling over?
Nathan: Yeah. But I don't know, I'm feeling pretty bullish about our current design of using WebAssembly and eventually we could do the same thing in a V8 isolate or... presumably Python has their own equivalent if we ended up going that way. Our whole application's multi-threaded. We have a real clear distinction between the main thread and the rest. We have shared memory concurrency.
So yes, it's hard but we've put a lot of investment into the technical choice to make it doable, at least from a performance perspective. I don't take it lightly, but I also think that we are positioned to do it well if we think carefully as we proceed.
From a design perspective, it's hard. Building APIs... I mean, we really learned that with Atom. Having an extension API is really hard. Versioning it, evolving it, it's all challenging. But I think having done it once before and having made a lot of mistakes, we're pretty well positioned to avoid those mistakes. And the foundation that we have is pretty solid.
Thorsten: When you say scriptability, what do you have in mind? With the stuff that Zed already has and tree-sitter, there's a lot of powerful stuff you could build on top of it if it were exposed. What do you think would be the first big milestone for scriptability or extensions?
Nathan: I mean, Emmet being possible would be great because there's a lot of people that want that. So that's one thing.
Thorsten: So the ability to modify text with tree-sitter APIs or syntactic-aware APIs or something like that.
Nathan: Yeah, I don't even know how syntactically aware Emmet needs to be, but obviously it would be potentially helpful in making sure that we're doing these expansions in this particular example and in a context where it makes sense.
The hard part for me is that my imagination runs a little short on this because I don't need to write any extensions since I can just do whatever I want to do right in the editor.
Antonio: Hahaha.
Nathan: But maybe you guys have better ideas off the top of your head. For me, it's a valve. What I like about it is that I don't know what people are going to do with it. Although that is challenging, like you do need to build an API with something in mind for what people can do. So specific use cases, I haven't maybe spent enough time thinking about. Max, do you have any more, having dug in and started working on it?
Max: For scripting, I can imagine myself wanting to have simple commands that I might run: I'm in a pane editing some file and I run a command and it uses a combination of tree-sitter and grep to look for tests for the file that I'm in and open them up in another pane in a split or something and put my cursor in there, scroll the view to show the test.
Things like that, like moving, searching for things in the project, searching for things in a buffer, searching using regex, searching using syntax, positioning cursors, maybe doing edits.
I can think of a lot of things you could do with a pretty small number of APIs like that, where you can open a pane, you can find the open pane, you can do a search. I'm imagining in different code bases people would have certain things that they do a lot. Maybe if you're working on a Rails code base and you want to open the, I don't even remember now, controller tests for the controller. I had scripts in Vim that would do stuff like that. And it would be a lot of times with just grep.
I think that is important for people's productivity. And I think it's pretty low hanging in that you don't need to build custom UI for it. You just need the ability to manipulate editors and panes. And really a lot of the productivity and scripting is around core features like that. So I want to do a good job with those APIs.
Thorsten: A couple of weeks back, a user was saying they want that to be able to execute any function that they have their cursor on. The first reaction from a bunch of us was, "what, what does that mean?" But now that we've talked with the user, I think what they want is similar to what you have in Emacs where you could put your cursor on any S-expression and then say "evaluate this." I think we could do something like this with tree-sitter, right? You could say, "I'm in a Ruby file, so now when I hit this key binding, evaluate the expression or whatever it is that I have my cursor in." That stuff would be really cool, this interactive evaluation of code, syntax-aware.
Nathan: Right, like bringing in Kyle Kelly. He's been playing around with that, like a couple days, with what does it look like to get Jupiter runtime support? What would the extension API look like for that? It might not be like everything you need to build the Jupiter integration, but it might be like, oh, this exists and you can reach out and grab tree-sitter and call this other API to a valid and appropriate runtime. Yeah, that would be awesome. And for me, the thing I've always thought is that the ability for people to solve their own problems is gonna scale much better long-term, I think, than us trying to solve everybody's problems for them. That just doesn't scale. And we could build a version of Zed for Python and a version of Zed for... I think JetBrains takes that path. But I'd much rather build one tool that is flexible enough for people to make their own.
That was the same dream behind Atom, we just took it, you know, we turned the dial to 11. And I'd love to get the dial to 11, but maybe it gets to 11 in year four, instead of year one, and we sort of incrementally get there while holding our other values constant.
Thorsten: I don't know why I'm thinking in terms of these axes, but: batteries included vs. nothing at all. Right now Zed understands a lot of languages, understands a lot of language servers. People even call that out and they say: "Nice. I opened Zed for the first time in my TypeScript project and it immediately did auto-complete." Do you think there's a limit to that? That there is a core subset of batteries that can be included, but no more than eight batteries, 10 batteries is a little bit too much. The rest? You have to go with extensions. And also I think the hard part here might be that everybody needs a different battery, right, for whatever they're doing. What are your thoughts on this?
Antonio: For me, whenever we include something in the editor, I feel like we're making a promise that it's going to work a certain way. Basically, what classifies as core are things that we can uphold, where we can uphold that promise to our users. Everything else, I don't know. Like you said, everybody needs different types of batteries and yeah, I'm not sure where to draw the line.
Nathan: I think that is where you draw it though. It is not humanly possible and we wanna grow our team, but even if we do grow our team, it's just not possible for our team to cover everything. But it is possible for us to cover a lot. At the end of the day, people just want an editor that works the way they want it to work. I guess there is a subset of people that really get off on like, you know, engineering their own keyboard out of wood, with doing their own soldering and then customizing their editor.
They just want an editor toolkit and put it all together. But I think the vast majority of people, kind of me included, would be happier if they just turn it on and it works.
We're trying to find the right balance there. I think we took a lot of languages into core because we didn't have extensibility quite ready. Some of those were gonna be spinning back out because the quality of that experience is going to be higher if people other than us are maintaining it. So it really just boils down to that. I think Antonio, you said it. We're gonna try but we may drop the ball from time to time, like forget to update a language server to the latest version or we're not using the right one. But I think that's the right attitude. If it's in the core, then it should be good. And we're maintaining that. And there's only so many of us, so many hours in the day.
Thorsten: Did you have this opinion, say, eight weeks ago? Or was this newly formed when Zed was open-sourced and all of the issues and pull requests came in?
Nathan: Oh, we knew it would be like this. I did, yeah. It's why extensibility was pretty high up in the roadmap because, and Linux as well, both of those, because those are both kind of like... We knew people would wanna get it working on Linux and whether we liked it or not, or scheduled it then or not, people were gonna attempt to contribute on that front. So we wanted to be receptive to that. And then we knew that people were gonna attempt to contribute things that...
Jason Rudolph, who used to work with us on Atom, said open source contributions are sometimes like someone giving you a free puppy.
So scheduling the extensibility now is very deliberate. We knew we didn't want to delay open source on that stuff being ready but we also knew pretty soon we'd need kind of an escape valve for free puppies that we just couldn't adopt.
Antonio: I want to add on top of that, that's not to say that if something's in the core, it's not an open source project. People can still help us maintain, improve the quality of that. It's just that the barrier to entry is going to be a little higher. We're going to feel more responsible about maintaining a certain type of quality for anything that goes in the core.
Thorsten: It's less controversial than it sounds, but we've all been involved in this one issue where the key bindings were changed from the Zed key bindings to the VS Code key bindings. This was yesterday, right? You all powered through or are powering through and I don't know if you changed it back locally. But I think it brings up an interesting question: would you ever tell a user, not in these words, but through the product that, "hey, the way you've been doing it is wrong"? Or "here's a better way"? If somebody were to say "hey, here's something we should build in the editor: I want to show pictures next to my code so I can type off code of pixelated JPEG" or whatever it is. Is that something where you would say "No, we found a better way to do this. This is not something we want in here"? Or say, they want a shortcut to duplicate a line 5,000 times and that's built in. Does anything come to mind here where that would make you say, this is our philosophy of text editing and we know what it is and there's stuff that can bump against it and that we don't want in Zed.
Max: In that instance of the switching our bindings to be more like VS Code, even though it was gonna be painful for all of us, what won out was the thinking that if there's something that we can be compatible with, so that we don't have to explain anything to anyone, and someone can show up and it's just going to just work for them with no explanation from us needed, then we go with that.
I value that really highly and that's why I even though I don't like the new key bindings we merged it. We basically added a key binding for alt-up back when that didn't conflict with anything and VS Code didn't have a default binding for "select larger syntax node". So we picked one. But now VS Code ships with that feature and they have a default binding for it. I think it makes sense for us to use it because it's if someone really hates it they can customize it. I might have to do that because I'm not able so far to get used to the VS Code one. But I really do value being sort of compatible with any standards that exist. Not that VS Code is a standard, but it's just that a lot of people have used it. So if there's something like that we can just work with, I'm gonna err on the side of kind of adopting that being standard, fitting in with the ecosystem.
Nathan: Yeah, 75% of the market or something.
But then there's other things, right? Like VS Code, I don't think they have yet added multi-buffers and that's our find experience [meaning: this is how you search in project]. And I just liked that better personally than a little menu, a panel at the bottom where it's showing you locations and you're jumping around.
So we decided to buck the trend on that one and we paid for it a little bit. There's some people that don't even understand that those things are editable. It's a little less familiar, it's different. So it's not like we're never willing to... I think I'll be pretty disappointed if we just build like a faster clone of VS Code. We have our own things to express, but it needs to be clearly better or clearly really matter to what we're trying to express to deviate that much from what people expect. But I think you were also asking like, how receptive are we to kind of different ways of doing things and I think it's gonna be case by case. Yeah, I don't think we'll add a duplicate five times command anytime soon.
Thorsten: The multi-buffer, I think, is a perfect example. And the other thing with the tree-sitter's "select larger and smaller syntax node", I don't think VS Code has that, right? They don't have the syntax node selection?
Max: Well, that was what disrupted me so much. This person opened a PR, which I think was a good change, and they said VS Code now has these bindings by default, "select larger syntax node". So Zed should use the same, but yes, when we first built Zed, that wasn't a thing in VS Code.
Thorsten: That to me is an example of, hey, we found a better way to do this. Now, if somebody were to come along and say, hey, I want this other way to be built in first class. Would we then push back and say, no, actually we think this is a better way? What you said about the multi-buffer makes it sound that if we are confident in that we have found a better way to do something, then this is what we're going to do.
Max: Yeah, I do think we have a perspective about what we want in our vision for Code UX. I want to be standard-compliant when there's a standard to adopt, but there often isn't. Multi-buffers is maybe one of our biggest concepts that doesn't exist in other editors.
Nathan: I've never worn the badge "opinionated" as a super big badge of honor. Cause I tend to find people that are opinionated kind of annoying. So I don't want to be, oh, we're so opinionated. We have an opinion on everything and there's a way to do it and you got to do it our way. Like that's not how I want to be. But I also don't want to be like a slave to how it's always been done.
I want to be willing to innovate and go out on a limb. I don't mind there being redundant ways of doing things. Like if there's a way that people are used to doing things that maybe is working for them better than our better way, I would entertain it. But I don't think I would like to have an alternative to the multi buffers that I would want to maintain just because some people preferred that. That's a pretty big feature.
So I feel like it's a case by case thing, but I'm not really here to like ram my way of doing everything down people's throats. I want to innovate and say, here's a good way I think of doing things that we're excited about, but that aura of exclusivity or being a know-it-all that is going to tell you how you should code — I don't know, I'm not that.
But there are some things I think that we found that are cool, multi-buffers being one of them. They're a great way of fixing a lot of compiler errors. So I want people to try it.
I don't know, maybe that's a red flag for people, that I'm not opinionated enough, but yeah.
Thorsten: I don't think so. It just means we can't expect a webinar from Nathan on the best way to edit text or something like that.
Nathan: I mean, I'm not even using modal bindings these days because I used Vim for a while and I got used to that, but then we wrote Atom and I had to go back to the Emacs-style bindings and I just like never... Yeah, I kind of put up with making that switching cost of the muscle memory to Vim just to get like an editor I didn't hate back then.
So, I don't know. Am I the text editing ninja of the universe? That's unclear. No.
Antonio: You got two keyboards though, and in Dvorak, so that sounds pretty ninja to me.
Nathan: Yeah, that's true. Yeah, I use Dvorak.
Thorsten: Is there anything that three years ago you said will be in Zed 100% but you dropped it because you realized this does not make sense or it doesn't fit in?
Nathan: No, but we added chat really early on and then realized like, okay, we're not even editing in this thing yet. What are we doing? So we kind of, we burned a couple of weeks on that. I just got really excited about collaboration and I don't know, I wanted to explore it but it was just not the right time. But now it's back, still a little unloved although people from the community, I saw someone... Yeah, Everson opened a pull request improving it, which was cool to see. So that was one thing. Have we dropped anything else?
Antonio: I don't think so.
Nathan: Yeah, there's some stuff I'd like to drop from the implementation still. Like the way that we serialize workspaces, I'd like to be simpler, but nothing from a product perspective so far.
Thorsten: Interesting.
Nathan: But we have so much to build. It's like skipping a meal when you're already starving to death or something. Is there anything you'd like to remove, Thorsten?
Thorsten: Remove? No. I... I discovered the journal mode that you apparently added, Nathan, two days ago. By accident, I just typed journal in the command thing and then I've realized there's a journal mode. And then I looked at the git blame and I saw that you added it. And also, fun fact, that's just 150 lines, right? It's one file that does all of this in Rust. That was pretty cool.
Nathan: Yeah. Nice. Yeah, it's not like the world's greatest journal or anything. It's just like create a new entry, you know, that has a timestamp with directory structure a certain way. It works for me. I added it like before Zed was, anybody was even using Zed just because I need it, yeah.
Thorsten: I do think that's interesting because it doesn't take up anything. It doesn't cost anything. It's just, you can type journal in and if you want it, you can get it. Otherwise it doesn't hurt you.
Nathan: But that's an example of something that should probably be an extension, I think, at some point, or if it weren't an extension, I would want to go harder on it and really build like a more full-fledged journaling experience into Zed. One or the other, probably the former, probably just make it into an extension in the short term. But it's like not doing that much harm, right? It's 150 lines of code and... But most people don't know about it. We don't really advertise it, right? Yeah.
Thorsten: What I find interesting is more these little small decisions that come up again and again. For example, do we add emojis to the chat? Or emoji reactions? There's all these small decisions that can have a huge impact. Or reactions in collaboration notes, where somebody could leave a thumbs up or something, or do we display images? Is markdown by default rendered and or always enabled? And I see these questions come by in pull requests and I find it really hard. I find it easy to overthink them, right? "oh, does this put us in a different direction? Should we have pixelated emojis? Is this more in line with the aesthetic?" I think it's really hard to find, to find a principle that you can hold through all of these decisions.
Nathan: I agree and I'd be lying if I said I had it all figured out and all in my head. I think we're all just finding our way. And the code you own ends up owning you. That's one thing I'm just cognizant of is like, as we add these things.
Whenever we change the foundation on which that thing is built, now we have to go visit it and deal with it. It just adds surface area and mass. So that's one thing. And then... Emojis, that sounds good to me, other than we have to maintain it and keep it working. But those specific examples sound good, but it just seems like something we'll have to figure out as we go.
I guess I'd like to be as big a tent as possible and be inclusive and include a lot of people's workflows without being a Frankenstein. And that's a tough balance to strike.
But maybe we could sort of over-correct in one direction, add something in and then just realize like, we can't have this anymore. It's kind of tough to take it away because now it's kind of like you're taking something away from people. But if you're willing to do that, then you're willing to kind of take more risk as well in what you add.
I don't want to be ill-considered. And I still think there are ways for where parts of Zed can be better resonant with other parts of Zed and there could be a more holistic product vision. Although I can't come up with any specific examples right now, so there's that.
But I want it to feel like a holistically thought-through, well-designed product. And so the more we expand our surface area and the faster we do that, the more challenging it will be. But I'm willing to kind of get there, sort of add stuff and then integrate it. That's where my head's at. And we'll see if that ends up being a good idea and how that works out and we can adjust. That's where my head's at now.
Thorsten: We're coming up on time. Does anybody else want to add anything? Like "Never coffee machine support in Zed — My name stands behind this"?
Antonio: Only if it's an espresso machine.
Thorsten: Foot pedal support in Zed.
Nathan: One crazy thing that someone's brought up and I thought about too is: could we embed the platform-specific browser so that people could pull up a tab that's pointing at the site that they're building or something. And that's one example of... Web technology is slow, so I don't wanna bring it in. But then it does have utility. So I don't know, I think that is potentially pretty cool but I don't know, yeah.
Thorsten: It sounds like you have pretty strong principles, right? And from that, the rest flows. As in what you said about extensions. It says a lot when you say an extension only has this amount of time to do something. Otherwise, it's disabled or we ignore the result. Because that already says that one value is performance, one value is speed, latency. That, I think, then ripples through the rest of the system or the rest of the community.
Nathan: Right. Our North Star is, you can't make your Zed slow.
Because ultimately the buck stops with us. And if that means that you can't add a feature because the author of that feature, just didn't have the skill or the time or whatever to meet the deadline then I'd rather you have a faster Zed with fewer extensions than letting us get to a point where we bog down and then we're like, oh, well, you installed too many extensions. I don't want that to be a state you can get to. So I hope we can stick to that.