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

The State of Atom's Performance

blog.atom.io

Post reply on HN
Print view View original

71–80 of 293 posts

Re: The State of Atom's Performance

#71

Post by mikestew »

nkkollaw wrote: post #66
mikestew wrote: post #62

Earlier quoted context omitted.

Memory usage? Sure, but as developers we probably have GB and GB sitting there GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor. And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resourc…

You know, I'm not saying those things aren't important. I'm just saying that the general use case sucks enough that I'd think you'd want to worry about that _first_, then perhaps think about startup time (maybe).

Sorry, wasn’t really arguing with you personally. And I agree, I am way more tolerant than I should be because “shiny”. Last I used VS proper (and it has been a while), it was a pig, but kinda worth it for the developer experience. But as you point out, all that piggishness and the experience is less than great? Umm, someone needs to do a rewrite.

Re: The State of Atom's Performance

#72

Post by oblio »

dchuk wrote: post #34

Reading updates like these from Atom reminds me a lot of some struggles I've seen with my teams in terms of how to breakdown problems you need to solve. I try to emphasize the idea of challenging the base assumption that current problems are stemming from to determine whether we've created our own issues or are truly facing problems we need to solve for our business. People tend to ignore the base cause/assumption an…

My guess is that they can't challenge those assumptions since they'd break backwards compatibility for plugins.

Re: The State of Atom's Performance

#73

Post by terminalcommand »

goalieca wrote: post #55
ParkerK wrote: post #3

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…

Emacs starts reasonably quick and it is written in a very extensible language.

The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon.

I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.

Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).

Re: The State of Atom's Performance

#74

Post by oblio »

squant0 wrote: post #50

It's funny reading this article that details how many core issues still exist, yet all the while both Atom and VSCode have spent significant engineering time and resources building superfluous features like shared real-time code editing and (Atom's) github integration. They are marketed as "text editors" and the feature work should be prioritized as such.

What makes you think those features are superfluous? That's how they plan to make money with these applications (well, I guess part of the plan).

Re: The State of Atom's Performance

#75

Post by joehewitt »

BugsJustFindMe wrote: post #43
joehewitt wrote: post #25

Don't get all the gripes about slow startup time. How often do you launch your editor? We're programmers - the editor stays open all the time!

I would like to be the first to welcome you to the world where your personal preferences and experiences aren't universal. I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.

> I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.

Ok, well if I was developing a programmer's text editor I'd consider you a marginal user and design for the use case of the editor staying open 24/7. Startup time seems pretty low on the priority list.

Re: The State of Atom's Performance

#76

Post by beckler »

joshmarlow wrote: post #28
Waterluvian wrote: post #13

I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job." I often have to fight with myself to pick the right tool for the…

Firstly, I agree with you! I like the philosophy that "Production should be as boring as possible." That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers. I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.

I heard once that if you're doing something boring to pick an exciting technology. If you're doing something exciting, pick a boring technology.

Not sure what you would consider exciting or boring, but I thought it was decent advice.

Re: The State of Atom's Performance

#77

Post by joehewitt »

loup-vaillant wrote: post #47
joehewitt wrote: post #25

Don't get all the gripes about slow startup time. How often do you launch your editor? We're programmers - the editor stays open all the time!

Every time I type `git commit`. Every time I visualise files with ranger (terminal based file browser). Every time I typed an email, back when I was using Mutt —which I might again. For such quick jobs, launching the editor should be instantaneous . And I don't want to use another editor for them, I like the key bindings of my main editor.

Have you considered that Atom is not an editor meant for "quick jobs"? It's a workhorse for programmers who are coding all day every day.

Re: The State of Atom's Performance

#78

Post by cle »

ninjakeyboard wrote: post #16

I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like…

I tried out Atom and found its "hackability" sorely lacking compared to Emacs. Which made me sad, because it's the only new-gen editor to really claim to be "hackable".

Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.). In Emacs, all of that is just a few keystrokes away. Atom is somewhat introspectable in that I can pop open a Chrome dev console and poke around at the DOM and the JS files, but it isn't at all as straightforward as in Emacs (e.g. given some keystroke or some function in Emacs, it's extremely trivial to jump to the source code and start modifying/debugging it). Given that these activities aren't clearly documented in Atom documentation, I can only assume that they aren't priorities for Atom and that, in fact, Atom isn't designed to be "hackable" in the sense that Emacs is "hackable".

Which is really disappointing, because a truly "hackable" editor a la Emacs, built on a web stack like Electron, would make me giddy with excitement.

Re: The State of Atom's Performance

#79

Post by Jare »

aftbit wrote: post #67
goalieca wrote: post #55

Earlier quoted context omitted.

Emacs starts reasonably quick and it is written in a very extensible language.

I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance. https://lwn.net/Articles/673724/

That sounds similar to the "snapshot" feature Atom is using.

Re: The State of Atom's Performance

#80

Post by mynameisvlad »

terminalcommand wrote: post #73
goalieca wrote: post #55

Earlier quoted context omitted.

Emacs starts reasonably quick and it is written in a very extensible language.

The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon. I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because…

> I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.

I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used.

Here's the GH issue: https://github.com/Microsoft/vscode/issues/22900

Post reply on HN