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?
The State of Atom's Performance
181–190 of 293 posts
Re: The State of Atom's Performance
#182Personally 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
#183Earlier 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…
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
#184I 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…
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
#185Why 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,…
Re: The State of Atom's Performance
#186Why 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.
Re: The State of Atom's Performance
#187Meh, 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...
Re: The State of Atom's Performance
#188Earlier 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).
Re: The State of Atom's Performance
#189>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.
Re: The State of Atom's Performance
#190Earlier 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?