4 ms·
Really the choice of language is unlikely to be the cause of any slowness you are experiencing in different versions. JS can be faster than a native experience,
by hellofunk 8y ago
Really the choice of language is unlikely to be the cause of any slowness you are experiencing in different versions. JS can be faster than a native experience, all depends on program architecture. The main JS engines are blazing fast and a low-latency UI is perfectly possible; sluggishness is not a sacrifice you must accept when coding in nearly any language in 2018. But bad practices in any language can lead to a poor user experience.
- TeMPOraL 8y agoTechnically true, but in practice, the culture matters. JS ecosystem is what it is - based on past and current experience, you can't expect efficiency coming from there.
- hellofunk 8y agoMaybe not from the ecosystem at large, but from Microsoft, on something like Outlook, sure you can expect efficiency.
- Sylos 8y agoI am not aware of a single piece of software written by Microsoft that I would call efficient, apart from maybe Notepad or MSPaint.
- gspetr 8y agohttps://en.wikipedia.org/wiki/Sysinternals https://en.wikipedia.org/wiki/Sysinternals Very efficient, though technically MS acquihired Mark Russinovich. He still works on them even though he's Azure CTO.
- Amezarak 8y agoMaybe so, but I have never seen a fast Electron app. VS Code, Discord, Slack, etc., all have awful performance on older hardware where native programs like the full Visual Studio fly. It's my personal suspicion that people cheerleading JS all are working with fantastic developer hardware, where the performance impact is pretty muted.
- _bxg1 8y agoPart of that is electron itself - I've heard it carries quite a bit of bloat - and part of that is the DOM. The DOM is very slow because of the guarantees it makes. You can edit any part of the HTML at any time - by hand or by API - and everything will resize and reflow implicitly. That's an incredibly powerful yet heavyweight feature. If they're using React Native, the only non-native thing is the raw JS logic itself, which is far, far less of a bottleneck.
- hellofunk 8y agoUpdating 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 agoNot 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 agoMy 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.