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?

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.

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!

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?

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.

That's not my recollection, at least. I was more of an Atom fan than a Code fan in the middle of the last decade, mostly due to aesthetics, as shallow as that probably sounds -- but it felt like Code surpassed Atom in terms of community activity head-spinningly fast, like in its second year.

I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can very much see the seeds of Sublime Text's package system in it, and Sublime is a very obvious influence on Atom/Code. (Although they were smart to have package management fully integrated; Sublime's package management system is a bit clunky by comparison.)

> Atom practically invented the kind of extensions that VSCode had

Let me introduce you to Emacs, vim, Sublime, TextMate, ...

There is a fundamental difference between the kind of extensions that Atom has and the type Code has. It's something that people often miss when they compare the two.

Atom was made to be infinitely customizable by using web technology. You can dynamically change everything you want with custom HTML, CSS, and JavaScript. Nothing is off limits. Want to shrink the size of the tabs? Just throw in some CSS, everything is changeable.

Code on the other hand runs plug-ins in a separate isolated thread where they are left to communicate with the editor through an extension API. Every customization "hook" that a plugin has access to needs to be explicitly added in that extension API. The things that the devs didn't think (or want) to add are simply impossible. Want to shrink the size of the tabs? Tough luck (except for unsupported hacks).

Code is awesome, but I think Atom should get more credit for what it tried to do. It is arguably the most customizable text editor ever.

Sublime, TextMate, …

wonder how much coffeecscript played a role in it. I happen to be writting coffescript at the time and noticed how it tended to hide its unnecessary wrapping when you use its syntax sugar. Still kinda wish we have a typed version of it.

I said basically the same in a sibling comment but I can't agree with you. VS Code doesn't start fast enough and it's not smooth to write with. It's not exactly bad but you definitely feel the slight delays and slowness all the time.

I went back to Sublime exactly to get faster startup and smoother writing than what VS Code was offering. So I'm pretty excited to see how Zed turns out!

Which editor did you came from to think vscode start fast? msword?

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 :).

woah, as a long time vim user who's been too lazy to switch, this might push me over the edge.

Atom was unbelievably slower than VSCode for any comparable set of capabilities. What do you mean bloated?

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.