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

41–50 of 293 posts

Re: The State of Atom's Performance

#41

Post by hsitz »

ninjakeyboard wrote: post #17
gaius wrote: post #2

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

> it doesn't really matter because you just run a daemon and connect to it.

I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post.

As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds.

Here's blog post that describes this feature:

https://brainlessdeveloper.com/2017/12/27/making-emacs-work-...

The blog post above actually overstates how difficult it is to start working with Emacs in this way. It's dead easy.

Re: The State of Atom's Performance

#42

Post by nothrabannosir »

Dowwie wrote: post #18

I gave VS Code a try recently for Python development. VSC almost won me over. However, in the end I found important features / packages that are available in Atom weren't available in VSC, so I moved back. For instance, autocomplete ("intellisense") failed to recognize functions that were written in files open in the editor!

As far as I know intellisense, it’s based on their model of your AST and import paths in the current file, not which other files are open. Open files are more of a “word complete” feature. i.e. text, non-semantical. like C-N in vim.

(Not to say you’re wrong to expect it—just for context.)

Re: The State of Atom's Performance

#43

Post by BugsJustFindMe »

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.

Re: The State of Atom's Performance

#44

Post by xpaulbettsx »

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…

I don't know why you would characterize it that way when they very clearly describe what they've done to improve this and their plans to improve it further. I wish every company would "refuse to admit" the same way!

Re: The State of Atom's Performance

#45

Post by dchuk »

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…

Most engineers have this bias. Feigned justification for biased decisions in the past rather than challenging original assumptions in the first place.

Re: The State of Atom's Performance

#46

Post by mr_overalls »

rayiner wrote: post #12
gaius wrote: post #5

Earlier quoted context omitted.

So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. Their problem is not technical, it’s ideological

That would impair the stated goal of "hackability."

Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.

Re: The State of Atom's Performance

#47

Post by loup-vaillant »

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.

Re: The State of Atom's Performance

#49

Post by Dirlewanger »

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!

VS Code's update cycle is like once per month which requires a restart. It starts up so fast that it doesn't even matter. Can't say the same for Atom.

Re: The State of Atom's Performance

#50

Post by squant0 »

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.
Post reply on HN