Live data from Hacker News

Sunsetting Atom

github.blog

461–470 of 880 posts

Re: Sunsetting Atom

#461

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…

Is it caled Zed because it is inspired by the old Zed text editor? https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...

Re: Sunsetting Atom

#462
post #435
post #165

Earlier quoted context omitted.

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…

Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.

This so much. I'm not fan of electron apps, but it's 1000x better to accept the chromium memory usage than a Windows VM memory usage. And I think that sharing the code between web and desktop also gives us very usable web apps (at least in case of Slack).

Re: Sunsetting Atom

#463

“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure. But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.

GitHub has been sh*tting the bed left and right. I audibly laughed when I saw this article.

I don't know if it started when MS bought them, but it's when I think the decline became very apparent.

Re: Sunsetting Atom

#464

Earlier quoted context omitted.

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish". We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block). Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.

While any software can be cancelled, I'd say Atom is being cancelled because of investment in VS Code (both currently owned by MS), I don't see any reason to think it's "inevitable" that VSCode will be cancelled, except in the sense that eventually everyone dies and the earth falls into the sun.

Re: Sunsetting Atom

#465

“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure. But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.

> Apache Retirement Home for Veteran Projects Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat. I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding fo…

I think this conflates several concerns which are unrelated. In particular, for a project to be under ASF stewardship does not mean it doesn't have large companies backing it. Look at projects like Kafka, Pulsar, Camel, Arrow, Spark, Flink, Pinot, Superset, Druid, etc. pp., they are all thriving and have strong funding.

Re: Sunsetting Atom

#466

Earlier quoted context omitted.

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?

Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions. Perf became the biggest problem however, which VSCode took over.

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.

Re: Sunsetting Atom

#467
post #165

Earlier quoted context omitted.

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…

I am honestly not sure why do people minify javascript in electron apps. It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter?? But people here can enlighten me.

Minification helps the parser too, try running VS Code from sources and you’ll notice startup is significantly slower.

Re: Sunsetting Atom

#468

Earlier quoted context omitted.

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.

As someone who loved everything about Atom except the sluggishness and bloat, Zed sounds like exactly the thing that I've been wanting.

VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth.

I hope Zed is able to establish a nice extension ecosystem as that is priceless!

Thank you!

Re: Sunsetting Atom

#469
So I wonder a bit, VSCode has clearly won over Atom.

But technically, as far as I know, they are both pretty similar.

So where is the difference? Are these just small details which VSCode got better? Or are there bigger things?

Or why else did VSCode actually won?

I have used both in the past. VSCode seemed a bit snappier, which is an important aspect for an editor. But I'm not sure if this was really the case actually. Or also, why there would be such a difference. Both used Electron, and I assumed both would use similar techniques for the editor.

Re: Sunsetting Atom

#470

Earlier quoted context omitted.

Did you consider using Flutter? If yes, what made you choose against it?

It's been a few years since I used Flutter, but doesn't it still require you to use the related language Dart? I liked the idea of it, and I thought the tight integration between Flutter and Dart allowed them to do some cool things. But I wasn't a huge fan of the language itself. And I think it's a lot to ask prospective extension-writers to learn a new language.

If you know Java or JavaScript, Dart is extremely easy to pick up.
Post reply on HN