5 ms·

> That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Is this really true though? In my esti

> That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Is this really true though? In my estimation the number of features for any given piece of software since the 90s has gone up a little in some cases, down in others (looking at you GNOME), leading to net average of 0. The software with the most gain in features seem to be high end games and AV editing, which also seem to be performing really well because they aren't typically made in electron. What does seem to be true is that developers use frameworks like electron because they believe it saves them a lot of time and their time is more valuable than the user's. Well, that and the rampant complexity fetishism.

vlovich123 5y ago
Performance means having the freedom being able to choose technology stacks along a other axes than performance. Ease of developer use, development speed, debugging, deployment targets, available and market talent are just some other things the business of engineering cares about. So of course engineers may pick Electron because nothing else fits that criteria if you ignore performance. It solves * Cross-platform distribution. An electron app builds off the extensive work Chrome has done supporting the various operating systems (and chromium has ported it to many others). * Democratizes native application development. It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it (+ abundance means it’s cheaper for the business) * Speeds up development. There’s no arguing that ReactJS has been a successfully dominant and powerful JS UI toolkit Sure, do I wish there were better, leaner UI toolkits out there? Yes. If the goal however is to enable the far greater pool of web developers to also be able to build desktop apps with the same ease as a website, I don’t know that you could do much better than the Electron model (there’s an interesting one that uses the browser engine installed in the OS instead to lower distribution size, which is more of a “different but same” kind of situation” kind of thing). Qt is trying ball compete but it’s really struggling and Rust and other tech stacks are struggling to compete. They have perf, but are lacking in the “enable large swaths of developers to contribute” piece.
- ComputerGuru 5y ago
  > It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it That’s not true gatekeeping. Any JS dev is free to learn to write C++ and it's a fairly meritocrital process. I could flip it around and make the same accusation: for decades, "the web" was "gatekeeping" because C++ devs had to learn JS to write apps for the web. Not fair, right? The C++ (or just not-JS) requirement for desktop software was also not necessarily a bad thing either because writing (correct) C++ or other lower-level code is why native apps are better. They’re written by people that are more likely to understand the cost of memory allocations, cache locality, off-main-thread compute, and the inner working of the OS. The good ones understand how the thread pump works and why just as some things need to happen off the main thread, other things need to happen on it. Web devs are used to everything being on the server (meaning "very, very far away" in terms of latency) but native app devs understood/understand "in memory" vs "on disk" vs "on a different machine." (There are tons of crappy "native devs" that don't get these things and it's painfully obvious when you use those apps.) I understand why people might be miffed at that, but if technology x comes out tomorrow that lets VC-backed play dough architects build real skyscrapers, are we better off?
  - vlovich123 5y ago
    It's amusing to me that in one breath the statement seems to claim it's not gate keeping & then proceeds to gate keep & argue the importance of the gate. The fallacy of thought is assuming that JS developers don't know the importance of those topics when in fact I've met many who do understand all of that (including the inner working of the OS). It may not be the dominant trait, but that would be equally true with C++ developers, you'd just be complaining about all the segfaults & security vulnerabilities are because of the people who don't care to learn "correct" C++. It's the no true Scotsman fallacy. Also, I suspect many of the same memory issues would likely appear if they're in JS land - the JS runtime in browsers seems to be spectacularly good at hiding the costs of things that you might naiively expect to have bad performance in a native language where the compiler doesn't do such tricks. It's everything else the browser is doing for you that's likely the memory consumption (GPU acceleration, accessibility, etc). I think maybe there's some ways to provide alternate toolkits that are more efficient while retaining JS developers (something like React.Native layered onto Rust+Iced), but ignoring where the market clearly has spoke about development preferences seems unconstructive unless you have some proposal other than "rewrite everything in C++". > if technology x comes out tomorrow that lets VC-backed play dough architects build real skyscrapers, are we better off? Depends on what that means, but probably. Faster iteration cycles & lower overheads are very powerful effects to drive down costs. Think SpaceX. You'd probably still regulate it in centralized areas, but in the middle of nowhere, why not let people experiment with what's possible? "Hobbyists" already break the sound barrier racing around on salt flats. Before you respond, think about it this way. You're complaining about Electron on an article about keyboard latency which is measuring low-level latency issues well before it hits Electron. Clearly it's a challenge for those engineers & that's a very niche problem. They're writing code in C.
bertmuthalaly 5y ago
Electron can save you a lot of time but that doesn't mean your app has to be slow. https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/ https://keminglabs.com/blog/building-a-fast-electron-app-wit...

vlovich123 5y ago

Performance means having the freedom being able to choose technology stacks along a other axes than performance. Ease of developer use, development speed, debugging, deployment targets, available and market talent are just some other things the business of engineering cares about. So of course engineers may pick Electron because nothing else fits that criteria if you ignore performance. It solves * Cross-platform distribution. An electron app builds off the extensive work Chrome has done supporting the various operating systems (and chromium has ported it to many others). * Democratizes native application development. It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it (+ abundance means it’s cheaper for the business) * Speeds up development. There’s no arguing that ReactJS has been a successfully dominant and powerful JS UI toolkit Sure, do I wish there were better, leaner UI toolkits out there? Yes. If the goal however is to enable the far greater pool of web developers to also be able to build desktop apps with the same ease as a website, I don’t know that you could do much better than the Electron model (there’s an interesting one that uses the browser engine installed in the OS instead to lower distribution size, which is more of a “different but same” kind of situation” kind of thing). Qt is trying ball compete but it’s really struggling and Rust and other tech stacks are struggling to compete. They have perf, but are lacking in the “enable large swaths of developers to contribute” piece.

ComputerGuru 5y ago
> It’s not gate kept behind needing C++ developers and makes it easier to have JS developers work on it That’s not true gatekeeping. Any JS dev is free to learn to write C++ and it's a fairly meritocrital process. I could flip it around and make the same accusation: for decades, "the web" was "gatekeeping" because C++ devs had to learn JS to write apps for the web. Not fair, right? The C++ (or just not-JS) requirement for desktop software was also not necessarily a bad thing either because writing (correct) C++ or other lower-level code is why native apps are better. They’re written by people that are more likely to understand the cost of memory allocations, cache locality, off-main-thread compute, and the inner working of the OS. The good ones understand how the thread pump works and why just as some things need to happen off the main thread, other things need to happen on it. Web devs are used to everything being on the server (meaning "very, very far away" in terms of latency) but native app devs understood/understand "in memory" vs "on disk" vs "on a different machine." (There are tons of crappy "native devs" that don't get these things and it's painfully obvious when you use those apps.) I understand why people might be miffed at that, but if technology x comes out tomorrow that lets VC-backed play dough architects build real skyscrapers, are we better off?
- vlovich123 5y ago
  It's amusing to me that in one breath the statement seems to claim it's not gate keeping & then proceeds to gate keep & argue the importance of the gate. The fallacy of thought is assuming that JS developers don't know the importance of those topics when in fact I've met many who do understand all of that (including the inner working of the OS). It may not be the dominant trait, but that would be equally true with C++ developers, you'd just be complaining about all the segfaults & security vulnerabilities are because of the people who don't care to learn "correct" C++. It's the no true Scotsman fallacy. Also, I suspect many of the same memory issues would likely appear if they're in JS land - the JS runtime in browsers seems to be spectacularly good at hiding the costs of things that you might naiively expect to have bad performance in a native language where the compiler doesn't do such tricks. It's everything else the browser is doing for you that's likely the memory consumption (GPU acceleration, accessibility, etc). I think maybe there's some ways to provide alternate toolkits that are more efficient while retaining JS developers (something like React.Native layered onto Rust+Iced), but ignoring where the market clearly has spoke about development preferences seems unconstructive unless you have some proposal other than "rewrite everything in C++". > if technology x comes out tomorrow that lets VC-backed play dough architects build real skyscrapers, are we better off? Depends on what that means, but probably. Faster iteration cycles & lower overheads are very powerful effects to drive down costs. Think SpaceX. You'd probably still regulate it in centralized areas, but in the middle of nowhere, why not let people experiment with what's possible? "Hobbyists" already break the sound barrier racing around on salt flats. Before you respond, think about it this way. You're complaining about Electron on an article about keyboard latency which is measuring low-level latency issues well before it hits Electron. Clearly it's a challenge for those engineers & that's a very niche problem. They're writing code in C.

bertmuthalaly 5y ago

Electron can save you a lot of time but that doesn't mean your app has to be slow. https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/ https://keminglabs.com/blog/building-a-fast-electron-app-wit...