3 ms·

Updating the DOM in Electron is like updating the DOM on the web -- you can do it fast or you can do it old. Most Electron apps I've worked on or looked at the

Updating the DOM in Electron is like updating the DOM on the web -- you can do it fast or you can do it old. Most Electron apps I've worked on or looked at the source are using things like React for the DOM, which is much faster than what you describe. But if an app does it "old school" then it can definitely be very slow.

_bxg1 8y ago
Not true. The DOM in Electron is precisely the same as the one on the web, yes. But while React is faster than some of the other data-driven frameworks, it is not faster than "old school" DOM manipulation. The advantage of modern frameworks is developer experience, not performance. The DOM API is fundamentally slow because of how much work the browser has to do under the hood to respond to changes. Every framework, including React, goes through that API at the end of the day. This is why React has its own whole virtual DOM: so that it can touch the real one as little as possible. My full-time job is writing tools in React that often have to handle datasets in the >10k items range.
- hellofunk 8y ago
  My point stands if by “updating DOM” it is meant the developer approach to making DOM changes, which in React go implicitly through a virtual DOM first, yes, which is vastly faster than updating the DOM directly. And an Electron app doesn’t need to be slow just because it uses a browser DOM. I work on a React project that has a faster UI than its native desktop counterpart.
  - _bxg1 8y ago
    An Electron app doesn't need to be slow just because it uses the browser DOM, but UI mutations will almost universally be slower than their native counterparts. Now, if the desktop app is poorly written and the Electron app is well-written, then of course the Electron one can be faster, because there can be sources of slowness other than UI mutations. Let me illustrate the DOM question with an example. Let's say you've got an "old style" jQuery to-do app. The user types something into the field, and clicks "Add". - The input field will be cleared - A new element will be added to the list, containing the string - The counts for "total items" and "items remaining" will be updated Now let's say you rewrite this app in React. The user types something into the field, and clicks "Add". - The input field will be cleared - A new element will be added to the list, containing the string - The counts for "total items" and "items remaining" will be updated Your code that accomplishes this will look completely different - much more readable and less fragile - but the exact same DOM API calls will be made, and it will perform exactly the same. The "speed" we associate with React is not in comparison to "old school" libraries, but to the naiive way of achieving data-driven syntax. You could just nuke the page entirely and re-render everything from scratch each time your data changes. This would be the easiest way of achieving data-driven syntax, but it would indeed be extremely slow. React gives you (something approaching) the performance of jQuery-style mutation, with the developer experience of reconstructing the DOM from scratch every time data changes.

_bxg1 8y ago

Not true. The DOM in Electron is precisely the same as the one on the web, yes. But while React is faster than some of the other data-driven frameworks, it is not faster than "old school" DOM manipulation. The advantage of modern frameworks is developer experience, not performance. The DOM API is fundamentally slow because of how much work the browser has to do under the hood to respond to changes. Every framework, including React, goes through that API at the end of the day. This is why React has its own whole virtual DOM: so that it can touch the real one as little as possible. My full-time job is writing tools in React that often have to handle datasets in the >10k items range.

hellofunk 8y ago
My point stands if by “updating DOM” it is meant the developer approach to making DOM changes, which in React go implicitly through a virtual DOM first, yes, which is vastly faster than updating the DOM directly. And an Electron app doesn’t need to be slow just because it uses a browser DOM. I work on a React project that has a faster UI than its native desktop counterpart.
- _bxg1 8y ago
  An Electron app doesn't need to be slow just because it uses the browser DOM, but UI mutations will almost universally be slower than their native counterparts. Now, if the desktop app is poorly written and the Electron app is well-written, then of course the Electron one can be faster, because there can be sources of slowness other than UI mutations. Let me illustrate the DOM question with an example. Let's say you've got an "old style" jQuery to-do app. The user types something into the field, and clicks "Add". - The input field will be cleared - A new element will be added to the list, containing the string - The counts for "total items" and "items remaining" will be updated Now let's say you rewrite this app in React. The user types something into the field, and clicks "Add". - The input field will be cleared - A new element will be added to the list, containing the string - The counts for "total items" and "items remaining" will be updated Your code that accomplishes this will look completely different - much more readable and less fragile - but the exact same DOM API calls will be made, and it will perform exactly the same. The "speed" we associate with React is not in comparison to "old school" libraries, but to the naiive way of achieving data-driven syntax. You could just nuke the page entirely and re-render everything from scratch each time your data changes. This would be the easiest way of achieving data-driven syntax, but it would indeed be extremely slow. React gives you (something approaching) the performance of jQuery-style mutation, with the developer experience of reconstructing the DOM from scratch every time data changes.