2 ms·

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, wh

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

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.