Sunsetting the Atom Text Editor
As new cloud-based tools have emerged and evolved over the years, Atom community involvement has declined significantly. As a result, we’ve decided to sunset Atom so we can focus on enhancing the developer experience in the cloud with GitHub Codespaces.
[…]
It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop. However, reliability, security, and performance are core to GitHub, and in order to best serve the developer community, we are archiving Atom to prioritize technologies that enable the future of software development.
Founder of Atom here. We’re building the spiritual successor to Atom over at Zed.dev.
They call it a “a lightning-fast, collaborative code editor written in Rust.”
Previously:
12 Comments RSS · Twitter
One of the first sentences: "When you move the cursor or type a character, you should see pixels on the next refresh of your display".
My Apple ][ could do that. But they're coming from Electron. :) Says a lot about the state of software development honestly.
I'm primarily using Visual Studio Code now, and it doesn't have any issues refreshing the pixels on my display. I don't notice any difference in responsiveness between it, or any native app I'm using.
VS Code is amazing, but it is really slow (to me it feels like doing everything through a layer of molasses).
I've documented a couple of examples of VS Codes' slowness, e.g., in these examples VS Code is 9 and 14 times slower then the editors I compared them to (Vim and BBEdit):
1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993
2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889
Speed or not, it seemed like the writing was on the wall for years. GitHub use VSCode as the basis for Codespaces, a bunch of folks I'm sure felt that two somewhat competing editors wasn't in the interest of Microsoft, even if GH is still kind of separate.
For what it's worth I've been fairly happy with VS Code, but find it pretty easy to break things by not being careful about which extensions I use. But, mostly I'm surprised to see just how quickly it's become the default amongst students I teach, and there it has a lot of power as an environment that's easy to pick up, but gives you plenty to grow with!
"I've documented a couple of examples of VS Codes' slowness, e.g., in these examples VS Code is 9 and 14 times slower then the editors I compared them to"
The reference above was specifically about how responsive the editor feels when typing characters, I think. But even so, the two examples you mention don't seem like problem areas to me. I don't usually open large minified JS files and format them, so I'm not bothered if it takes a few seconds.
The things I actually care about are the typing experience, and actions that tend to genuinely take a long time, like full-text search across a whole project. In those areas. Visual Studio Code is extremely fast.
I should also point out that you're on a Mac, which is an OS not exactly known for being particularly fast at rendering anything in any way related to the web. Opening an empty text file in VS Code on Windows is instantaneous for me, so I wouldn't be surprised if your comparison had more to do with OS X than with VS Code.
> I should also point out that you're on a Mac, which is an OS not exactly known for being particularly fast at rendering anything in any way related to the web.
I've never heard this before, do you have a source illustrating how web rendering is slow on macOS?
I don't know if anyone has done any objective testing, and I also don't know how well M1 Macs perform, so take this with a grain of salt, but... pretty much everything related to rendering is slow on Macs.
This started with Quartz when Apple switched to OS X. Initially, the idea was that faster hardware would fix the issue, and it did, up to a point. I never really realized that until I started using Windows regularly, but damn, everything related to drawing stuff on the screen on a Mac just feels sluggish to me now. Using a Mac after using Windows for a bit feels like I'm back in 2001, running the Public Beta on a PowerBook.
Windows is so much better at blasting pixels on screens. Even something like dragging around a window feels kind of weirdly more responsive on Windows, and this extends to browsers. Websites just feel faster on Windows, from rendering to JavaScript and CSS effects.
This probably has a bunch of different reasons: no Quartz or Display PDF on Windows, better GPUs, higher refresh rates on screens, and so on. I doubt it's just one thing that creates this difference. And obviously, you can go and buy a 200$ Windows laptop, and you'll have a horribly laggy experience, too.
But it's no coincidence that the people complaining about Electron performance are almost exclusively Mac users.
> Using a Mac after using Windows for a bit feels like I'm back in 2001, running the Public Beta on a PowerBook.
It would be nice to get some objective measurements. I used a high-end ThinkPad for 8 months or so last year as my primary machine (for reasons). When I used an M1 Mac, I was always surprised how butter-smooth the rendering is in Safari compared to Edge or Chrome on Windows. But I admit, this purely a subjective observation.
At any rate, circling back to VS Code. Someone did end-to-end latency measurements of VS Code and various other editors:
https://thume.ca/2020/05/20/making-a-latency-tester/
The latency of VS Code is worse, but not that much worse than other editors. Or put differently, if someone use iTerm2, they probably should complain about the latency of VS Code (iTerm2 is worse).
> But it's no coincidence that the people complaining about Electron performance are almost exclusively Mac users.
lmfao!
Electron is a race to the bottom middle. Mac users complain once the native experience is gone for the bottom middle (premium prices beget a premium experience with native apps, the thinking goes). Then there's all the other sacrifices in the temple of the holy MacOS UI and HID made by Electron on its race to the bottom middle that leave Mac users surly. Electron doesn't respect MacOS, that is the only thing that is no coincidence about Electron.
Native is important for all sorts of reasons, and in my case especially for accessibility, but yes, clearly form means a lot to Mac people. I'd go back to Windows for purely utilitarian reasons, only it's not UNIX(R), unless, of course, someone here would like to say something nice about WSL. And the accessibility support on windows means that, paradoxically, I'd get much better support for Electron and other toolkits, yet, a worse selection of apps, including Catalyst apps I like to use because they mirror iOS functionality. You can't win, as long as mobile is in charge.
