Live data from Hacker News

Atom was archived today

github.com

201–210 of 614 posts

Re: Atom was archived today

#201
post #37
post #18

Earlier quoted context omitted.

Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.

Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser ve…

With regards to various applications, the question seems it is not if Electron is fit for them, but if they really need to be a "native application". Why does a chat application need to have it's own native package and can't run in a browser tab? With all the recent development on WebRTC and even File System Access API, can't really find a sole reason* (but feel free to point them out) for 99% of Electron applications: seems some kind of developer ego "we are not just a[nother] web app, we are native".

* Looking at an arbitrary article, "Why does Slack desktop app use Electron?" [1], the answer seems mostly aesthetics, "faster performance [citation needed] and the frameless look".

[1] https://brainhub.eu/library/electron-app-examples#:~:text=Wh...

Re: Atom was archived today

#202
post #7

Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta. The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engine…

we had the conversation at University back in 2002; it went, "Atom is a dumb name" (for a beta package for editing, building in). What is this, the year of Marvel Comics taking over the Galaxy or something?

Re: Atom was archived today

#204

Earlier quoted context omitted.

Sorry but the very good Electron app which actually is very good, VSCode, really does suck if you maintain 10 projects. That’s not a lot of projects. It’s just a lot of browser tabs multiplied by documentation in an actual browser.

I agree you have to keep the number of VSCode windows quite low (5 is ok, 10 will make it struggle) but in fairness how many times have you had 10 instances of Visual Studio or IntelliJ running? I've never got close to that.

"No worse than a Java-based app" is sorta damning with faint praise. Java is notorious for being ill-suited for user-facing desktop apps - and justifiably so, at least historically.

But I agree with your core point. I use VS Code all the time, regularly switching between maybe a dozen different projects, and I personally don't run into performance issues or resource constraints very often. Certainly less often than with heavyweight IDEs like IntelliJ, Eclipse or XCode. But I felt the same way about Atom as well, so maybe my typical project/workflow/usage pattern is less resource intensive than others. (For one thing I hardly ever run apps from _within_ the IDE, I prefer to build/test/run from a terminal, so that might be a factor.)

VS Code isn't quite as responsive or quick to start as something like vim, or even emacs when run in a terminal, but its resource demands seem roughly on par with any other feature-rich IDE/editor in my experience.

Re: Atom was archived today

#205
post #34

Earlier quoted context omitted.

Two big ones I can think of: 1. Have your application look and act like a standalone application rather than a webpage—Chrome tried to support this with application shortcuts (or whatever they were called), but it never worked well enough 2. Give your application access to native APIs and capabilities that you can't get through the browser, like direct filesystem access

>1. Have your application look and act like a standalone application rather than a webpage That sounds suspiciously like "properly adheres to the native OS's conventions", the lack of which is the #1 criticism of electron.

They are talking in the context of games though, for which there aren’t such strong conventions, besides lives in your applications folder, and runs full screen.

Re: Atom was archived today

#207
post #75
post #32

Earlier quoted context omitted.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

>VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.

Its good, but not that good. There are still some pretty basic features that full fledged IDEs have - like multi window/display setup. And before someone suggests opening another instance - no, that is not enough and creates some synchronization issues that are no-go.

It also handles huge files very badly - try opening up 1-2gb XML files. It will either ask for more RAM, and crash. Or open it and disable all formatting options. Mind you that other editors can handle such files.

Or try to do a complex multiline regex find and replace - it will just sometimes crash outright on bigger files.

Re: Atom was archived today

#209
post #170

Earlier quoted context omitted.

> VSCode is one of the greatest pieces of engineering of our time. I don’t know… things like vertically landing rockets, the Large Hadron Collider, inflating space stations, CRISPR, mRNA vaccines come to mind among many other things that surely surpass VS Code when it comes to engineering marvels.

I hold VSCode to be at least equal to those achievements. Having used dozens of text editors and IDEs in the course of my programming career, I can appreciate how non-obvious it is for a piece of software this complex to work so fucking well all the time. And considering how many people are empowered by the productivity gains VSCode brings, I'd say that the real-world impact of VSCode is also much greater than that o…

VSCode over mRNA vaccines?

That's too obvious of a troll, please, stop here for a second, take a deep breath and reconsider. It's okay, you can let go of your past mistake, nobody will blame you.

Re: Atom was archived today

#210
post #73

Earlier quoted context omitted.

> People hate on electron, but it's a pretty amazing piece of tech if you ask me. It really does come down to how people build on top of it. I tried opening a 2gb log file in Atom and it took like 10 minutes before crashing. VSCode on the other hand, while a bit slow, opened it and I could search quickly and scroll it without any issue at all. That was what caused me to switch.

Opening large files is a pretty niche case anyway. Even CLI tools like less and grep are slow with things like searching muti GB files.

/s here you forgot this
Post reply on HN