Live data from Hacker News

Sunsetting Atom

github.blog

291–300 of 880 posts

Re: Sunsetting Atom

#291
post #79

Really begs the question what Visual Studio Code did right and what Atom did wrong.

Speed. I used Atom for a couple years, but quickly switched to VSCode once it was viable as it was the first electron editor to actually be "fast enough" for me.

Re: Sunsetting Atom

#292

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

Well, unless it is paid, I don't know how would you continue to toil for years making great editor. And unless it is free, gain a good market share to continue to support.

I hope you would have some solution to this conundrum.

Re: Sunsetting Atom

#293

I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode? I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you…

I've tried too many times already to use the Jetbrains IDEs, because I know they're great, specially about the IntelliSense stuff, autocompletion, suggestions, etc. But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it soooo…

Does VS Code support more refactoring and code generation now? I last used it heavily over a year ago, and at the time it seemed like anything beyond moving files and renaming things wasn't really doable. Meanwhile, in JetBrains's software I can extract and inline variables and functions, change signatures, split things out into other files, and more. I think I tried a plugin or two which were supposed to handle those things, but they either just didn't work at all or weren't reliable.

Re: Sunsetting Atom

#294

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

Nathan, I remember your passion for this project from its very early days. It has already borne fruit that has grown into a garden in the form of Electron, and I'm excited to see you are reimagining Atom in the form of Zed.

Best wishes for Zed's success!

Re: Sunsetting Atom

#295

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

> custom native UI framework

Cool project, but this is clearly a contradiction.

wxWidgets? That offers a native UI. Wherever possible it uses the UI controls from the underlying OS/system to render the interface.

Looking at the project page it describes "a GPU-powered UI framework that met our needs."

That's not a native UI. That's a non-native UI compiled to native code, ala something like Flutter.

Re: Sunsetting Atom

#296
Embrace. Extend. Extinguish. I won't touch VSCode with a 10 foot pole. Pick an editor that will last 40 years and isn't run by a mega-corporation that wants to eat FOSS so they can get us to buy into their subscription ecosystem.

Re: Sunsetting Atom

#298
post #150
post #78

Earlier quoted context omitted.

No it's perfectly reasonable. That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit. And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase, they're the same sort of project serving the same sort of mar…

> And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.

If I remember correctly, Electron was made for Atom (by GitHub).

Re: Sunsetting Atom

#299
post #165
post #2

It's what kickstarted Electron which eventually gave us VSCode, Slack, and lots of HN comments about memory usage. It also had the sweetest default theme of any code editor. RIP.

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms. One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to sup…

This is the most sensible take in my mind too.

Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.

Re: Sunsetting Atom

#300

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

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.

Post reply on HN