5 ms·

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness. They specificall

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness. They specifically address those issues in the post: > Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage. > Removing remaining synchronous IO: - Atom still uses synchronous IO (which blocks the UI thread) in some places... Much of the synchronous IO has been eliminated, but there are several Git-related code paths that we still have not updated, and which kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths and convert them all to use asynchronous IO.

RobertRoberts 9y ago
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.
- kalcode 9y ago
  That doesn't make sense...the browser always does the rendering of the dom. Not react. React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom. It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1. Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes. Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI. This has nothing to do with Atom.
  - taternuts 9y ago
    If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?
    - tylerhou 9y ago
      The article says this: > In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage. Emphasis is mine.
    - kalcode 9y ago
      Because they already implemented something similar as per the blog post. React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.
      - kalcode 9y ago
        *wasn't one of the major slow downs
- hajile 9y ago
  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/02/moving-atom-to-react.html http://blog.atom.io/2014/07/22/default-to-react-editor.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 https://github.com/atom/atom/pull/5624 I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost. I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend... EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread. http://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...
  - RobertRoberts 9y ago
    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.

RobertRoberts 9y ago

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.

kalcode 9y ago
That doesn't make sense...the browser always does the rendering of the dom. Not react. React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom. It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1. Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes. Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI. This has nothing to do with Atom.
- taternuts 9y ago
  If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?
  - tylerhou 9y ago
    The article says this: > In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage. Emphasis is mine.
  - kalcode 9y ago
    Because they already implemented something similar as per the blog post. React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.
    - kalcode 9y ago
      *wasn't one of the major slow downs
hajile 9y ago
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/02/moving-atom-to-react.html http://blog.atom.io/2014/07/22/default-to-react-editor.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 https://github.com/atom/atom/pull/5624 I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost. I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend... EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread. http://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...
- RobertRoberts 9y ago
  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.