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

401–410 of 880 posts

Re: Sunsetting Atom

#401

Post by shp0ngle »

skohan wrote: post #165
jstx1 wrote: 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…

By the way “write once, run anywhere” was the original promise of Java. Back in the 90s! Before JavaScript was even a thing!!!

People wrote Java applets that were supposed to be same everywhere. It even had GUI.

Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.

Re: Sunsetting Atom

#402

Post by fbcpck »

gcau wrote: post #130

I still use Atom purely for its simple easy git UI (while coding in VSCode). VSCodes git UI, and all others I've seen, are a disaster in comparison. I want a simple, easy UI - in atom its exactly that. If I need more I'll just type it in the CLI. I wish there was something else I could use that's like this.

Interesting to find that I'm not the only person doing this! I also just hop to Atom if I need to do something more involved with git

I typically do this when tidying up / amending >1 commit at a time (anything I can't do easily with git rebase interactive mode), or to resolve merge conflicts.

Re: Sunsetting Atom

#403

Post by bogwog »

akagusu wrote: post #330
bogwog wrote: post #122

Earlier quoted context omitted.

I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users. Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting d…

Glad to see that someone remembered FreeHand. It was much better than Ilustrator, this is why Adobe killed it.

I don't know what's worse, that Adobe would do something so shamelessly anti-consumer and anti-competitive, or that the FTC did nothing to stop such an obviously bad acquisition.

Re: Sunsetting Atom

#404

Post by gregmac »

nathansobo wrote: post #385
sdfhdhjdw3 wrote: post #358

Earlier quoted context omitted.

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…

Our goal is to build something substantially better than VS Code.

Can you be more specific about this, and what you're prioritizing?

Eg: Speed? Different UI layout? Fundamentally different design/UX philosophy?

Re: Sunsetting Atom

#405

Post by munificent »

BaseballPhysics wrote: post #295
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…

> 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.

"Native UI" can be interpreted to mean "UI written in native (i.e compiled to machine) code" or "UI written using the OS's native widgets". You are presuming that the only correct definition is the latter, but it's pretty clear from context that they mean the former.

Re: Sunsetting Atom

#406

Post by WorldMaker »

keewee7 wrote: post #79

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

VS Code had a really interesting "head start": the core editor (named Monaco) had been built for very early stages of the Azure Portal and then been adopted into IE 10/11's Developer Tools to replace an aging code viewer/editor. In order to run in Dev Tools it had to run through an extreme gauntlet of some of the web's worst "files": giant one-line minified things, massive multi-megabyte bundles, and so forth. So the Monaco code editor got a huge amount of performance testing and work years before Atom arrived and built Electron.

It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.

Re: Sunsetting Atom

#407

Post by shp0ngle »

joshstrange wrote: post #56

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 went from GoLand (their go thing) back to vscode.

With gopls, vscode is MUCH faster than goland, especially on big repos, and I don’t need to watch the dreaded “Indexing…” all the time.

It misses some features, but honestly it’s so much snappier, so that wins for me.

Re: Sunsetting Atom

#408

Post by emehex »

This is terrible. While I like VSCode, I exclusively use Atom for programming in Python because of Hydrogen [0], an extension which makes .py scripts feel and behave as though they were Jupyter Notebooks. I hope the nteract/Hydrogen devs are able to save their work and move it over to Zed/VSCode.

[0] https://github.com/nteract/hydrogen

Re: Sunsetting Atom

#409

Post by rjh29 »

aniforprez wrote: post #277
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…

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.

Re: Sunsetting Atom

#410

Post by rjh29 »

dham wrote: post #390
chipotle_coyote wrote: post #372

Earlier quoted context omitted.

That's not my recollection, at least. I was more of an Atom fan than a Code fan in the middle of the last decade, mostly due to aesthetics, as shallow as that probably sounds -- but it felt like Code surpassed Atom in terms of community activity head-spinningly fast, like in its second year. I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can ver…

Same, but if you're staring at an editor all day it has to look good. Atom did and still looks way better than VScode. VScode looks like a Microsoft product. You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to ch…

Funny how people are so different. I have never once thought that I needed my text editor to look good. Stare at anything long enough and your brain isn't even going to process it anymore!

fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.

Post reply on HN