22 ms·

IMO the killer thing that VSCode has over all the other editors is the wealth of extensions and a certain degree of simplicity. What are your plans for Zed in t

IMO the killer thing that VSCode has over all the other editors is the wealth of extensions and a certain degree of simplicity. What are your plans for Zed in terms of extensibility and are you aligning more towards making something beefy and full-featured like the IntelliJ offerings or something more "lightweight" like VSCode or Sublime?

nathansobo 4y ago
We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom. Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions. Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more full-featured IDE. These objectives are obviously in tension, but I think we can build something that balances them well. A collaborative IDE that feels fast and powerful.
- wpietri 4y ago
  Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
  - nathansobo 4y ago
    Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
    - SaulJLH 4y ago
      This "private alpha", any hints on how we might jump aboard!? ;) EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist https://zed.dev/waitlist
      - iamnbutler 4y ago
        it's less about being exclusive and more about getting feedback on the specific features we are focusing on and building at the moment. For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!
    - manaskarekar 4y ago
      As someone who loved everything about Atom except the sluggishness and bloat, Zed sounds like exactly the thing that I've been wanting. VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth. I hope Zed is able to establish a nice extension ecosystem as that is priceless! Thank you!
    - gosukiwi 4y ago
      This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
      - bombcar 4y ago
        Emacs either doesn't have APIs or everything is an API, depending on how you look at it - since it's source is available at runtime plugins and modules can be first-class citizens performance-wise.
      - bee_rider 4y ago
        With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow. There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.
  - boringuser1 4y ago
  - DarylZero 4y ago
    >I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. LOL, as if Firefox provided a stable API to extensions
    - mumblemumble 4y ago
      I think that's the inherent catch-22 of having a big API. You end up in a situation where you can't change things for fear of breaking the API, but you end up also not being able to hold the API stable for fear of not being able to change things. So you end up stagnating and breaking things all at the same time.
      - langsoul-com 4y ago
        Do you think there's any good solution to that problem? I think companies make brand new products whenever that happens. No legacy baggage. If it gets popular enough then the old software gets killed off.
- syrusakbary 4y ago
  This is great. Syrus here, from Wasmer. I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
- the_duke 4y ago
  Hey there. I've been thinking about implementing an editor agnostic WASM based plugin framework and started prototyping with some promising results, although there are also a lot of of WASM related constraints to consider. I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community. Is that something you can see your team collaborating on?
- nurettin 4y ago
  If you make Python a first class citizen and give it special support, you won't be disappointed. Man that felt a bit like extortion, but I mean well.
- Already__Taken 4y ago
  IMO the leap from sublime to vscode was because the extensions made it so welcoming & bultin. I think the next leap from that is by-default sharing of those extensions and config. WASM might be able to do that coupled with security defining execution. We need a trusted mechanism to share what git-hooks promised without thinking about it. Like you said, collaborative. If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
  - dghlsakjg 4y ago
    VScode offers workspace settings that you can check into git that will get picked up by anyone else using vscode on that repo.
quaunaut 4y ago
Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions. Perf became the biggest problem however, which VSCode took over.
- Q6T46nT668w6i3m 4y ago
  Sublime, TextMate, …
  - sealthedeal 4y ago
    I love Sublime, still my fave
    - yccs27 4y ago
      The instant-opening experience is just soo good, and Electron bloat nowhere in sight... I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.
      - distances 4y ago
        I tried to use VS Code but just couldn't stand it. I don't want to say it's sluggish but it definitely isn't snappy, not even with a M1 laptop. It's fine, but it isn't good. I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
      - can16358p 4y ago
        Same thoughts. While Vscode is my IDE now, I definitely love the instant-opening of Sublime. Ironically, it's even launching faster than TextEdit.
  - bayindirh 4y ago
    BBEdit.
    - 4y ago
l33t2328 4y ago
The bloat VSCode has over Atom kills it for me.
- joaonmatos 4y ago
  Atom was unbelievably slower than VSCode for any comparable set of capabilities. What do you mean bloated?
- nsonha 4y ago
  anyone can say vscode is bloated except atom. I gave it credit for being highly modular though. I remember being to disable the statusbar component (not just the UI) completely.
rjh29 4y ago
IMO the killer thing is performance, VSCode starts fast and is smooth to write with. It blew away the older set of Electron-based editors. They work tirelessly on performance every release and it shows imo. Allowing extensions without destroying perf isn't easy either.
- gibbitz 4y ago
  This is why I continued to use sublime text all the way up to capitulating to TypeScript. Code was slower because of all the intellisense. I've had Code freeze on me a few times. Something that I don't have happen in Sublime or Vim. If you have a lot of RAM and work on a current mainstream OS it may seem smooth, but it's still using 400mb of RAM. May as well use Eclipse or WebStorm FWIW. That said I'm using VSCode now too, but things can always be better :).
  - galaxyLogic 4y ago
    Part of it may be just Windows. I use Windows a lot to move files and folders around and the File Explorer is something I constantly need to wait on to respond. The Windows as GUI is not very responsive in my experience.
  - manigandham 4y ago
    > "but it's still using 400mb of RAM" Why does this matter? What is the point of saving RAM instead of using it?
    - Karunamon 4y ago
      It matters because your program is probably not the only one running.
      - manigandham 4y ago
        It’s a small amount and if you’re using it then it should take priority. Modern operating systems with SSDs are very good at managing memory anyway.
bstar77 4y ago
NeoVim can compete on this front. See LunarVim for a heavily extended experience.
- theonething 4y ago
  woah, as a long time vim user who's been too lazy to switch, this might push me over the edge.
  - bstar77 4y ago
    I pair it up with Alacritty on Mac and Linux for a nice performance boost. It will work in iTerm or one of the default Linux terminals, but much slower.
    - theonething 4y ago
      Nice! I'm on iTerm but may just go whole hog and switch out that too. Thanks for the tips! I love HN. P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?
rattray 4y ago
Interesting. Will you have built-in LSP support for most popular languages then?
brianzelip 4y ago
The killer feature for me wrt to Atom -> VSCode was the built in terminal.

nathansobo 4y ago

We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom. Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions. Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more full-featured IDE. These objectives are obviously in tension, but I think we can build something that balances them well. A collaborative IDE that feels fast and powerful.

wpietri 4y ago
Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
- nathansobo 4y ago
  Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
  - SaulJLH 4y ago
    This "private alpha", any hints on how we might jump aboard!? ;) EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist https://zed.dev/waitlist
    - iamnbutler 4y ago
      it's less about being exclusive and more about getting feedback on the specific features we are focusing on and building at the moment. For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!
  - manaskarekar 4y ago
    As someone who loved everything about Atom except the sluggishness and bloat, Zed sounds like exactly the thing that I've been wanting. VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth. I hope Zed is able to establish a nice extension ecosystem as that is priceless! Thank you!
  - gosukiwi 4y ago
    This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
    - bombcar 4y ago
      Emacs either doesn't have APIs or everything is an API, depending on how you look at it - since it's source is available at runtime plugins and modules can be first-class citizens performance-wise.
    - bee_rider 4y ago
      With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow. There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.
- boringuser1 4y ago
- DarylZero 4y ago
  >I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. LOL, as if Firefox provided a stable API to extensions
  - mumblemumble 4y ago
    I think that's the inherent catch-22 of having a big API. You end up in a situation where you can't change things for fear of breaking the API, but you end up also not being able to hold the API stable for fear of not being able to change things. So you end up stagnating and breaking things all at the same time.
    - langsoul-com 4y ago
      Do you think there's any good solution to that problem? I think companies make brand new products whenever that happens. No legacy baggage. If it gets popular enough then the old software gets killed off.
syrusakbary 4y ago
This is great. Syrus here, from Wasmer. I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
the_duke 4y ago
Hey there. I've been thinking about implementing an editor agnostic WASM based plugin framework and started prototyping with some promising results, although there are also a lot of of WASM related constraints to consider. I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community. Is that something you can see your team collaborating on?
nurettin 4y ago
If you make Python a first class citizen and give it special support, you won't be disappointed. Man that felt a bit like extortion, but I mean well.
Already__Taken 4y ago
IMO the leap from sublime to vscode was because the extensions made it so welcoming & bultin. I think the next leap from that is by-default sharing of those extensions and config. WASM might be able to do that coupled with security defining execution. We need a trusted mechanism to share what git-hooks promised without thinking about it. Like you said, collaborative. If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
- dghlsakjg 4y ago
  VScode offers workspace settings that you can check into git that will get picked up by anyone else using vscode on that repo.

quaunaut 4y ago

Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions. Perf became the biggest problem however, which VSCode took over.

Q6T46nT668w6i3m 4y ago
Sublime, TextMate, …
- sealthedeal 4y ago
  I love Sublime, still my fave
  - yccs27 4y ago
    The instant-opening experience is just soo good, and Electron bloat nowhere in sight... I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.
    - distances 4y ago
      I tried to use VS Code but just couldn't stand it. I don't want to say it's sluggish but it definitely isn't snappy, not even with a M1 laptop. It's fine, but it isn't good. I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
    - can16358p 4y ago
      Same thoughts. While Vscode is my IDE now, I definitely love the instant-opening of Sublime. Ironically, it's even launching faster than TextEdit.
- bayindirh 4y ago
  BBEdit.
  - 4y ago

l33t2328 4y ago

The bloat VSCode has over Atom kills it for me.

joaonmatos 4y ago
Atom was unbelievably slower than VSCode for any comparable set of capabilities. What do you mean bloated?
nsonha 4y ago
anyone can say vscode is bloated except atom. I gave it credit for being highly modular though. I remember being to disable the statusbar component (not just the UI) completely.

rjh29 4y ago

IMO the killer thing is performance, VSCode starts fast and is smooth to write with. It blew away the older set of Electron-based editors. They work tirelessly on performance every release and it shows imo. Allowing extensions without destroying perf isn't easy either.

gibbitz 4y ago
This is why I continued to use sublime text all the way up to capitulating to TypeScript. Code was slower because of all the intellisense. I've had Code freeze on me a few times. Something that I don't have happen in Sublime or Vim. If you have a lot of RAM and work on a current mainstream OS it may seem smooth, but it's still using 400mb of RAM. May as well use Eclipse or WebStorm FWIW. That said I'm using VSCode now too, but things can always be better :).
- galaxyLogic 4y ago
  Part of it may be just Windows. I use Windows a lot to move files and folders around and the File Explorer is something I constantly need to wait on to respond. The Windows as GUI is not very responsive in my experience.
- manigandham 4y ago
  > "but it's still using 400mb of RAM" Why does this matter? What is the point of saving RAM instead of using it?
  - Karunamon 4y ago
    It matters because your program is probably not the only one running.
    - manigandham 4y ago
      It’s a small amount and if you’re using it then it should take priority. Modern operating systems with SSDs are very good at managing memory anyway.

bstar77 4y ago

NeoVim can compete on this front. See LunarVim for a heavily extended experience.

theonething 4y ago
woah, as a long time vim user who's been too lazy to switch, this might push me over the edge.
- bstar77 4y ago
  I pair it up with Alacritty on Mac and Linux for a nice performance boost. It will work in iTerm or one of the default Linux terminals, but much slower.
  - theonething 4y ago
    Nice! I'm on iTerm but may just go whole hog and switch out that too. Thanks for the tips! I love HN. P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?

rattray 4y ago

Interesting. Will you have built-in LSP support for most popular languages then?

brianzelip 4y ago

The killer feature for me wrt to Atom -> VSCode was the built in terminal.