261
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Jan 2024
261 points (95.5% liked)
Open Source
31021 readers
645 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
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.