I hope it gets there. I was a sublime user until vs code’s integrations got so far ahead that the productivity gains outweighed the slowness, but I really want it to be faster.
Do zed plugins have to be written in rust? If they do then that will slow community contributions since it’s not as popular as JavaScript for vs code.
If it were just millisecond advantages I would gladly use VSCode, but in large projects the difference is massive, it takes minutes to fully load a project and several seconds to perform certain actions.
The problem was the extension architecture, that they leaned into heavily. It encouraged basically every part of the system to interact with every other part of the system, like having free reign over the whole DOM. That’s what the creators meant by a “hackable” editor.
VS Code is much faster, largely because of its much more sane extension architecture. Extensions are much better isolated, with a much smaller API surface by which they can interact with the editor. And the LSP design means core IDE-like features can be lifted into a privileged part of the system, and implemented once with performance in mind, while the actual analysis is done asynchronously in subprocesses.
If you actually use both Atom and VS Code configured to feature parity, you would notice that VS Code is miles ahead of Atom. Microsoft did an amazing job proving that you can build complex performant software on Electron.
Yes, Electron 2.0.0 was a great update, but it’s not the reason for performance. The reason was better software architecture.
Can confirm that’s it’s very fast. Just lacking plugins at the moment.
I will watch it with great interest
I hope it gets there. I was a sublime user until vs code’s integrations got so far ahead that the productivity gains outweighed the slowness, but I really want it to be faster.
Do zed plugins have to be written in rust? If they do then that will slow community contributions since it’s not as popular as JavaScript for vs code.
VSCode is fine
Maybe for you. I personally am quite picky about tools I use all day every day.
Cool story. Same here. Did you want to get into an internet Snapfish at which tool has millisecond advantages over another?
If it were just millisecond advantages I would gladly use VSCode, but in large projects the difference is massive, it takes minutes to fully load a project and several seconds to perform certain actions.
How large are we talking?
Yeah, it’s fine, I said I use it didn’t I? But it’s just fine, so I’d prefer something even better.
Codium
Sounds exactly like atom… until they killed atom
Atom was never fast
Exactly.
Atom being open source was why I switched to it from Sublime.
Atom’s shitty performance was why I switched away to VS Code.
It was Electrons problem. VSCode was basically Atom. When MS made Electron2 or whatever it got much faster.
It was not Electron’s problem.
The problem was the extension architecture, that they leaned into heavily. It encouraged basically every part of the system to interact with every other part of the system, like having free reign over the whole DOM. That’s what the creators meant by a “hackable” editor.
VS Code is much faster, largely because of its much more sane extension architecture. Extensions are much better isolated, with a much smaller API surface by which they can interact with the editor. And the LSP design means core IDE-like features can be lifted into a privileged part of the system, and implemented once with performance in mind, while the actual analysis is done asynchronously in subprocesses.
If you actually use both Atom and VS Code configured to feature parity, you would notice that VS Code is miles ahead of Atom. Microsoft did an amazing job proving that you can build complex performant software on Electron.
Yes, Electron 2.0.0 was a great update, but it’s not the reason for performance. The reason was better software architecture.