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?
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.
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?
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.
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.
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.
> 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.
This is a sign that emacs has too much extensibility (or, to be more accurate: too little isolation). It's been observed before that emacs really is the antithesis of the alleged Unix philosophy of "doing one thing and doing it well". It is an inner platform.
Causally linking glaring deficiencies (long lines, concurrency) to overriding virtues (extensibility) is a weak but common snow job aimed at emacs's critics who know nothing of emacs's internals. For this emacs critic who knows quite a bit about emacs's internals, I call you out.
There's only one reason for emacs's many wtf frailties. No one's paying to fix them.
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.
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.
The web stack is abysmally slow, so you have to carefully pick the levels at which you offer extensibility. Emacs doesn’t have to worry about a DOM, CSS, etc. There’s just not that much between between grabbing input events, storing a character in a gap buffer, updating a glyph matrix, and painting the screen. And it’s all heavily optimized to be usable over ancient serial links: https://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-.... So even making each of those steps heavily programmable in Elisp—every key press invokes a Lisp function that can be rebound, or adviced-around, still ends up performing reasonably well on a modern machine.
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.
>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
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.
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.
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?
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.)
Same, but if you're staring at an editor all day it has to look good. Atom did and still looks way better than VScode. VScode looks like a Microsoft product.
You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to change the text editor in real time. You don't really need to do much as it already looks good though.
Funny how people are so different. I have never once thought that I needed my text editor to look good. Stare at anything long enough and your brain isn't even going to process it anymore!
fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.
While I am a Mac user, I've used Vim a lot, so I don't want to make it sound too much like I demand text editors be visually stunning works of art. :) Code initially looked just kind of clunky and toylike to me, in a way that Atom -- and Mac native editors like TextMate and BBEdit -- didn't. It's a little hard to explain. Code still isn't my favorite editor, but it's probably my favorite cross-platform editor.
For me, it’s the noise and clutter — every time I spin it up, it feels like VS Code is demanding my attention in multiple popups, and there’s a new tab or button I’ve never seen before with some mystical purpose, and the bottom bar is some jarring color that makes me feel like something is broken.
IntelliJ IDEs feel similar — sometimes I’ll open them up and after upgrading several plugins and dismissing a bunch of popups and “what’s new” dialogs, I don’t even remember what I was trying to do in the first place.
A month ago I switched back to Vim, from TextMate, but still on a Mac, and honestly: Vim is kinda pretty. I spend most of my day in fullscreen Vim, and with a good theme, Airline and a pleasing font it’s just as pretty as VSCode if not more.
I was under the impression that the "forced" upgrade to Sublime 4 caught quite a few out, and may have been a nail in the coffin.
I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.
> This is how it's always been I think; their model.
I don't think ST needs to move fast. It's a good quality editor. It doesn't need a bunch of new features every couple of months. Just getting a major update once a year is fine imo.
I think that the learning curve might be in reference to installing plugins.
Installing an extension on vim (never done emacs) is something that does not just happen easily. There is no intuitive search for extensions built in, you likely have to install software that manages your plugins.
VSCode on the other hand rarely requires more than a single click through a built in interface.
The plugin ecosystem exists for command line editors, but it definitely has a learning curve
Emacs has a built in package manager as well as several alternative external package managers! Most of the time installing a package is as simple as running "package-install" or having a "use-package" expression somewhere in the init scripts!
I personally do not use any of these package managers and instead use my systems package manager on Gentoo to manage everything. Gentoo has most of the popular projects in the ::gentoo repo under app-emacs, and packaging your own is only a few lines of bash.
While I don't know about the plugin ecosystem of Vim/Emacs, I definitely agree with the learning curve part.
In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
In Vscode even if I forgot Cmd+W/Q I can simply click the close button. Not to mention that all the shortcuts are just globally used shortcuts in all the other software.
While I respect praising by the community of Vim/Emacs, I really don't think it's beginner-friendly.
So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific.
> In Vscode even if I forgot Cmd+W/Q I can simply click the close button
there is a close button in emacs. however unlike vscode, emacs can also run in the terminal
> So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific
can be said about windows too. i started off on windows and jetbrains. today im on minimal linux, stumpwm as window manager, and emacs for everything except browsing. i find it very liberating having cut down my dependencies without having cut down functionality
When I run Emacs with a blank config, the default display has this:
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r Browse manuals C-h i
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h RET Exit Emacs C-x C-c
Activate menubar M-`
GP's post was in response to the complaint that Emacs/Vim are hard to exit. They said that "Or, you know, you could just click on the File menu and click on Quit."
And I'm just saying you can't do that in the terminal.
The rare time I use vscode instead of neovim I always end up with a lot of random characters into the code and have to close it without saving for fear of having broken something. You call that user friendly?
User friendly is what most users find it easy to use.
Your argument is more on the lines that you are a legacy user who does't want to move.
The whole idea of using vim/emacs was when intellisense/autocomplete was in its infancy. And programming general required using typing skills as a autocomplete mechanism. The only real use of all that edit-commands-as-a-mini-language philosophy of vim is to write keyboard macros. Which again was needed because people lacked decent autocomplete features. Besides typing fast itself isn't connected to coding productivity these days.
See my previous comment. LSP/intellisense support is available on vim/neovim and many other editors. It is not like it is an exclusivity to vscode. Also many people actually configure their vscode to use vim-like keyboard bindings because they actually like the separation of the different modes.
Macros, substitutions and search commands are useful for many things and an editor like vim/neovim/emacs is not only used for code.
> Unlike VSCode, Emacs and Vim have a learning curve
have you seen the extent of available emacs packages? maybe it is a learning curve for a person who just learned how to power on a computer but i find emacs soo much more approachable
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.
Thing is, the vast majority don’t care about infinite tweaking. I’d never want to change the tab size or anything else like that. It should be right to begin with. Also I don’t want to have to deal with extensions breaking every update.
What I, and almost everyone else wants is extensions which provide real utility like language packs, linters, git tools, etc. All of this works well on VS code.
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.
I love BBEdit, but its package ecosystem isn't well-developed compared to most other editors, and it doesn't have any kind of package manager -- it's more like Vim's native packages, e.g., "download the package and put it in this folder, and check occasionally for upgrades when you remember and re-install when appropriate."
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.
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.
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!
Sublime test starts faster and smoother than vscode, but it's plugins leave too much to be desired compared to a good vscode setup.
I was a massive sublime text 2 user with a living document I would share on how to set everything up just right, but now I only ever use it to open the odd 100+mb sql dump if I want to search for something and have it be syntax highlighted.
I don't percieve any of that but I also don't care if a game framerate is 30 or 60 or 120, it's probably the same type of brain difference! More choices is always a good thing.
Comparing it to Atom etc. It takes like 3 seconds to load a medium-sized Python project for me. And I was a long time vim user. The speed of vim is not worth the ridiculous gap in features.
Which gap? There are so many plugins. The only use I did of vscode this last year was to use the drawio integration and now I am doing diagram as code when I need to with mermaidjs or python diagrams and no longer uses it.
Even if it took 3 minutes to load it wouldn't matter because I plan to work on the project for days if not hours. OTOH, like you mentioned feature parity just puts VSCode in a different league altogether.
3 minutes(the imagined extreme scenario) pales in comparison the hours of time most people waste in meetings, or sipping coffee, or chatting with colleagues.
Just how much do you plan to achieve in 3 minutes?
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 :).
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.
Because all my ram is already consumed. I have a 16gb MacBook running only a browser, vscode, ms teams, and the docker containers for the app and I have no memory left so I see a spinning ball every time I change windows. Ms teams was the final straw. Slack was about 300mb but teams is now 700mb+
Once you exceed it some of the content will go to swap, which is going to slow down the system (and wear an ssd faster). 400MB is not that much though, for me Code usually takes at least 1.5GB RAM.
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.
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.
