Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sunsetting Atom

github.blog

Post reply on HN
Print view View original

491–500 of 880 posts

Re: Sunsetting Atom

#491

Post by HideousKojima »

IncRnd wrote: post #179
dkarl wrote: post #28

Earlier quoted context omitted.

They embrace, extend, and extinguish products they don't make money on, so that people are forced to use products that they do make money on.

Microsoft doesn't make money from VS Code. Atom was retired due to a lack of activity with the project. I've never even seen anyone use Atom, since the time it was released 8 years ago.

Had two coworkers at my last job use it when they needed to edit some of our legacy PHP stuff (we were mostly a .NET shop) but even they switched to VS Code eventually because the writing was on the wall for support.

Re: Sunsetting Atom

#492

Post by SahAssar »

brundolf wrote: post #115

I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe) But once I tried VSCode... man, there was no going back. It was infinitely more performant and cohesive. Atom (with IDE-like features installed) felt so sluggish by comparison. I think the main improvement…

> It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented

Wasn't brackets and atom released pretty much at the same time, both built on CEF?

Re: Sunsetting Atom

#493

Post by stjohnswarts »

I expected this with the Microsoft takeover. Most "extraneous" non-profitable activities and projects will be killed off. Also MS produces VS which is a successor in a sense to Atom.

Re: Sunsetting Atom

#494

Post by bee_rider »

gosukiwi wrote: post #478
nathansobo wrote: post #346

Earlier quoted context omitted.

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.

This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.

With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow.

There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.

Re: Sunsetting Atom

#496

Post by eikenberry »

nathansobo wrote: post #253

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…

When will the source repository going to be made public and what license do you plan to use? For the editor and the UI kit. Looking forward to seeing how that all works.

Re: Sunsetting Atom

#497

Post by marricks »

dewey wrote: post #256
marricks wrote: post #177

Earlier quoted context omitted.

Also all have the same magnitude of latency and lag. At least you know if one of them bugs you, they all will.

There's a bunch of Electron powered apps that feel really snappy, definitely faster and snappier than some default apps Apple ships on macOS these days. Examples for me would be: VSCode and Linear

I should have put the example I was comparing to: VIM. I like VIM as an editor because it's extremely fast and works well once you adapt to it.

I'm sure VSCode and Linear are fast, nice, and fine. I just hated the lag/latency compared to my terminal text editor.

Re: Sunsetting Atom

#498

Post by nwatson »

exyi wrote: post #459
fmntf wrote: post #433

Earlier quoted context omitted.

I work on the linux kernel using CLion and the IDE is still fast. I would not be interested in a non-Java IDE for the performance.

Are you using 32-core / 100GB RAM monster machine? I do everything on my rather powerful laptop, but Jetbrains IDEs are just too much. I can't have more than one project open at time, which is limiting. I didn't try CLion, only IntelliJ for Scala and Rider for C#/F#, all on smallish projects and it will still take 3-6GB of memory :| I'd be interested in even lighter than VSCode IDE ;)

I often have several simultaneous PyCharm projects open with separate completely introspected and navigable virtualenv's with lots of installed libraries, and also ongoing DataGrip, and at times CLion or IntelliJ sessions ... all the Jetbrains IDEs are performing quite well. At times running Docker as well. 32GB Macbook Pro M1.

Re: Sunsetting Atom

#499

Post by qbasic_forever »

sdfhdhjdw3 wrote: post #358
nathansobo wrote: post #253

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…

Humble question, I don't mean to sound confrontational, I ask of genuine curiosity: Why not contribute to VS Code instead? For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS…

I don't think VS code would ever accept a change to native UI or switch off of electron, so it seems like a nonstarter for someone who wants to experiment with native UI text editors.

VS code is written almost 100% in JS and typescript, it will always be a nodejs app through and through without a complete rewrite. And even if they wanted to rearchitect VS code all of the extension APIs, extensions themselves, etc. would demand the existing nodejs runtime.

So long story short... VS code is a good editor if you want to contribute to a nodejs and web tech based text editor, but not if you want to explore other architectures or ideas.

Re: Sunsetting Atom

#500

Post by gibbitz »

rjh29 wrote: post #409
aniforprez wrote: post #277

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?

IMO the killer thing is performance, VSCode starts fast and is smooth to write with. It blew away the older set of Electron-based editors. They work tirelessly on performance every release and it shows imo. Allowing extensions without destroying perf isn't easy either.

This is why I continued to use sublime text all the way up to capitulating to TypeScript. Code was slower because of all the intellisense. I've had Code freeze on me a few times. Something that I don't have happen in Sublime or Vim. If you have a lot of RAM and work on a current mainstream OS it may seem smooth, but it's still using 400mb of RAM. May as well use Eclipse or WebStorm FWIW. That said I'm using VSCode now too, but things can always be better :).
Post reply on HN