6 ms·

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 collabor

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.
    - tikhonj 4y ago
      Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things. Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system. This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.
  - galaxyLogic 4y ago
    This is important, think about the whole Web. Too many ways of doing things and too much backwards compatibility needed for tools to develop further. I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.
    - sigzero 4y ago
      There are so many ways to do the same thing...in any language. That's just reality.
    - popcube 4y ago
      but Perl have backwards compatibility, developers keep perl1 source code can run on current version.
- 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.

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.
  - tikhonj 4y ago
    Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things. Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system. This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.
- galaxyLogic 4y ago
  This is important, think about the whole Web. Too many ways of doing things and too much backwards compatibility needed for tools to develop further. I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.
  - sigzero 4y ago
    There are so many ways to do the same thing...in any language. That's just reality.
  - popcube 4y ago
    but Perl have backwards compatibility, developers keep perl1 source code can run on current version.
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.