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

81–90 of 293 posts

Re: The State of Atom's Performance

#81

Post by Zarel »

acdha wrote: post #61
loup-vaillant wrote: post #47

Earlier quoted context omitted.

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.

> Every time I type `git commit` This is true with something like Vi but with a separate GUI app, wouldn't the most common case be setting EDITOR={atom,code,etc.} and it simply opening a new window in the already-running app? (Or, for that matter, don't most people using something IDE-like use the built-in UI to make a commit?)

Opening a new window in the already-running app is also slow; they cover a strategy for increasing that performance in the linked blog post.

Re: The State of Atom's Performance

#82

Post by ebiester »

smacktoward wrote: post #51
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…

I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know. " Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They ca…

And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)

I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim.

If the goal is to learn GTK, Rust, and C, then it's not a big deal. If the goal is to build something that you need, you end up scratching it and going back to something you know already.

(In my case? Java which has the underrated JavaFX 2.0. And I'm sure I'll look elsewhere some other time - I'd really like to learn Rust better, but I think I'll do something other than a desktop app, or at least wait for better documentation or more time.)

That said, Lazarus looks really cool as well and may be the thing I always hoped for...

Re: The State of Atom's Performance

#83

Post by Waterluvian »

ebiester wrote: post #82
smacktoward wrote: post #51

Earlier quoted context omitted.

I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know. " Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They ca…

And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.) I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim. If the goal is to learn G…

I experienced this too. Strong Python developer wants to build a GUI in a few days to help others perform a task. Uses PyQt, runs into segfaults (in Python?!) and has to drop down a level, understanding the implementation and nuances of QT.

Re: The State of Atom's Performance

#84

Post by Adutude »

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…

From the atom FAQ in answer to the question "Atom feels slow or is consuming too much CPU or memory"

"Atom isn’t designed to be a tiny native-code editor. If the ultimate in speed is what you’re after, Atom probably isn’t what you’re looking for at least for now … and possibly not ever depending on what you’re expecting."

I tried Atom as an alternative to Eclipse, about 3 months back, as I consider Eclipse to be pretty bloated and slow, but Atom made Eclipse look like a speed demon. I tried running with --safe, removing plugins, but nothing seemed to help, it was still painfully slow. Perhaps it's my machine or some other local issue, but I run Eclipse with lots of plugins and it runs great, in comparison.

After reading the above in the FAQ and many many posts about how Atom was running slow and the responses those issues received, it seemed to me like they actually do admit there are performance problems but have the attitude of "That's just how it works, if you don't like it use something else"

Re: The State of Atom's Performance

#86

Post by bdcravens »

mikestew wrote: post #62
nkkollaw wrote: post #24

I do go back to Atom often because of a few details that I like better over VS Code, but it's a lost cause, and reading this proves it. Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal. What…

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…

> I fail to see why one wouldn’t just use VS Code

Github is cool, Microsoft isn't. /s

Re: The State of Atom's Performance

#87

Post by vvanders »

smacktoward wrote: post #51
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…

I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know. " Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They ca…

> This "I don't have to learn anything new" factor is literally the only thing Electron has going for it.

Not completely, don't underestimate how hard it is to write a cross platform UI that runs on Windows, OSX and Linux.

Starting from a web framework not only gives you portability but also a common UI language(that may diverge a bit from native app conventions but that's a tradeoff you need to weigh).

I say this as a die-hard C++/native dev. I've done wxWidgets, QT and a bunch of others and it's never a trivial thing to do.

Re: The State of Atom's Performance

#88

Post by BugsJustFindMe »

joehewitt wrote: post #75
BugsJustFindMe wrote: post #43

Earlier quoted context omitted.

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.

Design for whatever you want to design for. Plenty of us are programmers who program all day every day and still don't agree with you. What you choose to prioritize is different from what you understand, though. So at least now you should "get" the gripes.

Re: The State of Atom's Performance

#89

Post by BeetleB »

cle wrote: post #78
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 key…

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

Although it is ugly, and the documentation is poor, and web site looks like it's from the 90's, and the project lead is a bit eccentric, you may want to consider the Leo editor:

http://leoeditor.com/

It's written in Python, and pretty much gives you access to most/all its internals. Unfortunately, the state of the documentation is pretty poor which is why I never had the time to spend mastering it. But I've followed it enough, and it really is a very powerful editor. I think only Emacs surpasses it in self-scriptability. A lot of non-programmers have used it to do pretty interesting things (helps that Python is "easier" for them than Lisp).

Post reply on HN