5 ms·

> Somehow things got wrong somewhere. The hardware folks gave us magical exponential growth for a straight 30-50 (depending how you count it) run. That lead t

> Somehow things got wrong somewhere. The hardware folks gave us magical exponential growth for a straight 30-50 (depending how you count it) run. That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. (note: business here just means "non-devs" and can include some devs). We used that amazing hardware to optimise towards delivery speed over everything else (and while we did/do some horrible things - there is no doubt that a modern dev in 2021 commands processing power and vast libraries that would have been a dream to kid me in the 80's) and when every layer of your stack leaves performance on the table that adds up cumulatively. Throw in that on the time scales of computers humans are laughably slow and you can get away with a lot of inefficiency. It's an interesting trade-off - I figure at some point we'll reach the limits of what we actually can do and efficiency will shoot back up the importance chart (in some ways for the hyperscale folks it has for a while, 5% improvement over millions of boxes adds up). Saying it's "lazy devs not optimising" isn't fair though, they are optimising but in other directions.

AnIdiotOnTheNet 5y ago
> 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...
blacktriangle 5y ago
Exactly. Today's dev is optimizing for feature delivery speed. While the kid in me that wrote 4k demos dies a little more inside every day at what we've become, you can't deny that if you had told us back in the 80s that we would receive a customer request in the morning, design and develop the feature in the afternoon, and push it into production for thousands of users across the globe that evening, I'd have thought you were insane. We mourn what we've lost in dev but we're so used to how amazing things have gotten on the axis of feature delivery speed we fail to appreciate it.
fouric 5y ago
> That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Right - the question to ask is "what are businesses incentivized to do?" and the answer is "add features". With some exceptions. Video games, for instance - gamers don't like it when their $60-$80 AAA game runs at 15 FPS on their $3500 rig, so video game developers are actually incentivized to optimize for performance. If we can change the incentives, then we can influence the outcomes. One way of changing the incentives is to get users to complain about slow products and use faster ones (although that might be difficult). Another, possibly more feasible way, might be to get federal and state governments to start requiring user-facing software products purchased/contracted to have maximum latencies on a given baseline spec. You can bet that that would cause certain companies to suddenly care about performance.

AnIdiotOnTheNet 5y ago

> 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...

blacktriangle 5y ago

Exactly. Today's dev is optimizing for feature delivery speed. While the kid in me that wrote 4k demos dies a little more inside every day at what we've become, you can't deny that if you had told us back in the 80s that we would receive a customer request in the morning, design and develop the feature in the afternoon, and push it into production for thousands of users across the globe that evening, I'd have thought you were insane. We mourn what we've lost in dev but we're so used to how amazing things have gotten on the axis of feature delivery speed we fail to appreciate it.

fouric 5y ago

> That lead to a "we can add more features or we can make it fast" pick one and the business always picks more features. Right - the question to ask is "what are businesses incentivized to do?" and the answer is "add features". With some exceptions. Video games, for instance - gamers don't like it when their $60-$80 AAA game runs at 15 FPS on their $3500 rig, so video game developers are actually incentivized to optimize for performance. If we can change the incentives, then we can influence the outcomes. One way of changing the incentives is to get users to complain about slow products and use faster ones (although that might be difficult). Another, possibly more feasible way, might be to get federal and state governments to start requiring user-facing software products purchased/contracted to have maximum latencies on a given baseline spec. You can bet that that would cause certain companies to suddenly care about performance.