Live data from Hacker News

Atom was archived today

github.com

371–380 of 614 posts

Re: Atom was archived today

#371
I'm not a huge fan of Microsoft, but they hired Erich Gamma and that was a brilliant move. He is an engineer I have tremendous respect for, with obvious vision. He was key in VisualAge for Java, which was a Java IDE, written in Smalltalk, which supported refactoring down to the smallest level (including file operations). He was obviously a key designer for VSCode. From its earliest days, I could see how they were sketching in facilities for advanced features in an open way, and it has maintained its development well.

Re: Atom was archived today

#373
post #150

Earlier quoted context omitted.

Exactly. The truth is that over that last 15+ years _most_ of the apps that people use _most_ of the time are a perfect and natural fit for the web UI/UX: text, media, hyperlinks, standard form/window controls, with relatively modest standards of performance and responsiveness, etc. Assuming developers avoid resource leaks (and to be fair some notable Electron-based apps tend to be both leaky and long-running) the ma…

I have never, in my life, used an electron program that isn't irritatingly slow on my main computer. Yes, it's not something you'd probably call a fast computer (4th gen i3, 4GB ram), but this same computer doesn't drop a frame in equivalent native programs. Most of the time the CPU is almost idle. I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.

> I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.

As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.

From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.

FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps

I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.

UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:

* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.

* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.

* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.

IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.

Re: Atom was archived today

#375
post #362
post #328

Earlier quoted context omitted.

> Moreover it is supported out-of-the-box in emacs: `M-x list-packages`. Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.

Menus? Clicking? That doesn't seem very emacs-y of you. M-x weirdness - up to and including the fact that it refers to a "Meta" key not found on modern keyboards - is exactly the kind of gatekeeping that allows me to feel superior for knowing how to exit emacs gracefully. But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-ab…

To be clear, I’m not talking about the menus in some special Emacs port like aquamacs, I mean the regular Emacs, with its menu bar, seen here: https://www.gnu.org/software/emacs/tour/

Re: Atom was archived today

#376
post #75

Earlier quoted context omitted.

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 the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

I appreciate you saying Emacs, and vi, but I don't think we even have to reach out of the Microsoft ecosystem to find an even great achievement of engineering for a productivity app; namely Excel.

Re: Atom was archived today

#378
post #143

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

> All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered…

You do realize there are huge mechanical hammers that do require training to use, right?

Re: Atom was archived today

#379
post #231
post #115

Earlier quoted context omitted.

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

Having worked with a handful of terminal CLI purists I'm convinced most of the people who bang the drum hard for vi and emacs aren't nearly as productive as they think they are, and instead evangelize it largely for some mixture of these reasons:

1) They have a strong preference for keyboard only operation

2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are

3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit

Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.

Re: Atom was archived today

#380
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…

Electron shouldn't exist. It's an insult to the engineering discipline. :barf:
Post reply on HN