Live data from Hacker News

The State of Atom's Performance

blog.atom.io

181–190 of 293 posts

Re: The State of Atom's Performance

#181
post #154

Earlier quoted context omitted.

The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs. It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.

Forgive me for being skeptical. Where is this git-time-machine equivalent?

What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit

Re: The State of Atom's Performance

#182
Performance certainly matters. I applaud the tireless effort from the Atom core team.

Personally I'm taking a pause off Atom (after 3 years professional usage) until it definitely improves.

Best wishes!

Re: The State of Atom's Performance

#183
post #136

Earlier quoted context omitted.

Maybe they should rewrite it in React. I've been argued into the ground under the guise that it's faster than the browser's rendering of DOM.

They've been there and done that http://blog.atom.io/2014/07/02/moving-atom-to-react.html http://blog.atom.io/2014/07/22/default-to-react-editor.html Turns out that for the important things in an editor, React has a hard time optimizing as much. I'm a huge proponent of React, but the right tool for the right job is an important principle for the pragmatic. https://github.com/atom/atom/pull/5624 I think since then, th…

This is the exact reason I've commented (and been shouted down for) saying that React is a fad. It's trying to replace fundamental core system with a layer, and do it better. It will never work, it can't.

Eventually everyone will figure out that building "apps" with DOM manipulation will never be as performant as lower level coding (ie, not a script layer), and they will move on. And the DOM will return to light apps and general purpose websites with basic interactivity.

How can it go any other way? Btw, the only reason I am posting this is bit out of frustration that stating something so obvious makes some people really angry. I suspect its because they have invested so much in React, and don't want to consider it a temporary hack until webassembly or shadow dom or some other tech makes it completely obsolete.

I tried out Atom, it's miserably slow. And I recently downloaded VScode, just to give it a whirl, and it's impressively faster. But I use Komodo, and that is based on Scintilla and Firefox, and it works just fine.

Re: The State of Atom's Performance

#184

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 wish engineers and computer scientists would pay attention to that gut reaction more often.

Programming really at some level is as much about translating human ideas into physical computations as anything. In this regard, it is a fundamentally psychological process, as much about the programmer as the computer. There's a sort of psychological-cognitive -> math -> physics process, and I often feel as if the emphasis is on the second two steps, and not so much on the first two.

There's good reasons for this, but it's resulted in a sort of blind spot that often comes out as people just preferring languages like python or javascript or whatever, and not wanting to acknowledge that those fuzzy, poorly understood preference processes are driving development as much as the choice of algorithm or hardware constraints.

I think it's poor ergonomics, really, and effects things as much as memory management models, etc.

We're at a stage, though, where languages like Nim, etc. offer some promise of ergonomics and performance, and I hope people will pay attention to it carefully, so we don't end up in the same situation as the one Atom exemplifies. I like Atom, and don't have any particular attachment to Nim, but do think there's something we shouldn't be ignoring anymore. Often when a language is difficult to intuit, the reaction is to shame the programmer, to characterize them as not smart enough to understand the language. Sometimes there's some truth to that, but sometimes I think it reflects deficits in the language, whose sole purpose, really, is to translate human thoughts into computational events.

Re: The State of Atom's Performance

#185

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

Personally, Atom is not my editor of choice (team Sublime!), but I really hope Atom succeeds. I do love it's hackability, and I would much rather have my plugins in JS, but alas, it's just not fast enough for me, yet. However I held onto Textmate until 2010 and Sublime wore me down, so I'm a laggard as well. So no negativity from me, because I just want a great editor that I can control and hack on. But I'll be real,…

If sublime natively supported JS plugins I think all Electron-based editors would be in trouble.

Re: The State of Atom's Performance

#186

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

>> written in the accessible Javascript language so that anyone can contribute Anyone that knows JavaScript.

Which is a very substantial population.

Re: The State of Atom's Performance

#187
post #14

Meh, tried it a while ago. VSCode is better, but still a bloated piece of software. Glorified text editors that use megabytes of memory when running...

You never have used any of those java based IDE, have you?. A clean install of Eclipse takes about 400 mb before even creating a project. Android Studio is a nightmare of epic proportions. VSCode provides the same level of autocomplete and features at a fraction of memory without lagging at every keystroke.

Re: The State of Atom's Performance

#188
post #168

Earlier quoted context omitted.

Weird question, I know, because I use VS Code as well, every day for about 6 months and love it, but, I’ve never used these other popular editors. What makes VS Code so much better? I chose it because it had some integration with DCC apps I use use, and I like the GUI and general simplicity. What other reasons do people have for loving it?

Relative to Atom, which I left for VS Code: Code is faster and lighter, just as extensible. Better git integration and code analysis, even for Javascript (I finally understand what devs from other languages were talking about!). My workflow is just smoother for everything except Clojure and system admin (but I use emacs for those, atom isn't any better there).

VS Code was my first not-Sublime, not-vim editor, but...I really, really missed my four-up display with four editors in a square configuration. I went to Atom because of that and because of VS Code's inability to keep a pane open even with no tabs (just because nothing's in it doesn't mean I want it closed).

Re: The State of Atom's Performance

#189
post #9
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 found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.

most of their fans will switch to VS Code if they found it, not so for ST and Vim

Re: The State of Atom's Performance

#190
post #154

Earlier quoted context omitted.

The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs. It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.

Forgive me for being skeptical. Where is this git-time-machine equivalent?

https://github.com/pidu/git-timemachine

or

Magit

Post reply on HN