> Electron runs like shit and inhales RAM is because it was programmed by people who don't have solid understanding of fundamentals.
I feel like this is a huge oversimplification. I’d argue that for sufficiently large projects (say, Chromium) every single programmer who works on it could have a strong understanding of performance fundamentals but the product itself could still have performance problems because there are necessary levels of abstraction involved and no one person has the entire codebase in their head. Performance problems could come from emergent behavior that could not have been predicted by the original engineers.
But, as for implementing an app on top of Electron. Say I need to write a cross-platform app with a consistent style and fluid animations. I know how to write a NEON implementation for ChaCha20 for fun, or write a zero-copy binary property list parser that’s faster than anything I’ve found. I have a decent understanding of performance. That doesn’t help me write this cross-platform app. I don’t have to time to write a novel native UI toolkit that allows me to share code while maintaining platform consistency and native performance. I don’t have time to fix the memory consumption of Chromium. I’m going to write my Electron app in JavaScript, carefully, and hope the performance will be acceptable (but not great). I don’t see how that can reflect on any individual programmer poorly.
I disagree. As evidence: games are way more complex, have enormous teams, and manage to simulate an entire game world rendering render hundreds of thousands of polygons 60 times every second. Twitter crashes my browser.
But I don't think that it has _anything_ to do with the individual programmers inherently understanding performance better.
There is likely a huge organizational focus on performance and more people expressly dedicated to the task because it is a higher priority for Epic. It is directly correlated to Epic's ability to deliver a successful product to game companies, whereas for browsers it is slightly more orthogonal to their success.
LLVM has a bunch of contributors who likely understand the intricacies of machine code better than either of us, and:
> Each LLVM release is a few percent slower than the last.
> The larger problem is that LLVM simply does not track compile-time regressions. While LNT tracks run-time performance over time, the same is not being done for compile-time or memory usage. The end result is that patches introduce unintentional compile-time regressions that go unnoticed, and can no longer be easily identified by the time the next release rolls out.
Electron is a running joke because of how horrible the performance is. Again, I don't buy it. I think it's much more a matter of "they can't" than "they don't want to."
I think if those LLVM contributors understood compilers better, they wouldn't be introducing those issues. Look at Jon Blow's achievements on Jai. LLVM is the bottleneck for his entire compiler at the moment, and he's planning to replace it with what... Three people or something? But I also think there are structural issues there. I don't think a top-down project from a large company gets to use that excuse.
That's because GPUs are insane and purpose built. For an honest benchmark, you'd only look at instructions executed on the CPU which won't be any rendering, but stuff like world ops, AI, game flow. Some of those are not really that taxing.
As an example, Stellaris had performance issues that were CPU bound for a while and it's gotten better. It's not a visually demanding game after all.
Think about the requirements for market success of the different pieces of software. Games most run fast and any performance you safe can go back into better graphics. Performance is crucial. Electron is hugely successful despite not being very performant.
Developers love thinking about performance. It's fun and asked us to use so many of our skills. However, for many products other quality aspects are more important, like maintainability, extendability and expediency of development.
That performance often falls by the wayside on terms of business priorities ends up being reflected in the typical developer skill set.
I don't know if I agree. Its plausible, but also these businesses are monopolies, so even if they churn out shit it doesn't undermine their market position.
But I think Electron in particular is a symptom of the fact that GUI frameworks are in general horrible. There was a market gap for usability because using everything else was obtuse, and now we're paying for it.
Which businesses are monopolies? Slack surely isn't. If there's a market for faster chat clients because that's what people want then looks like a business opportunity?
FWIW all of slack competitors are also electron (rocket.chat et all), so it seems like you possibly know something that other engineers don't and might have a competitive advantage!
If someone released a GPU-accelerated version of Electron that had the performance of the GUI in basically every video game, it would destroy Electron. Now, would it be popular? I'm not sure, but let's say the answer is no. Ok, now imagine Google released that.
I feel like this is a huge oversimplification. I’d argue that for sufficiently large projects (say, Chromium) every single programmer who works on it could have a strong understanding of performance fundamentals but the product itself could still have performance problems because there are necessary levels of abstraction involved and no one person has the entire codebase in their head. Performance problems could come from emergent behavior that could not have been predicted by the original engineers.
But, as for implementing an app on top of Electron. Say I need to write a cross-platform app with a consistent style and fluid animations. I know how to write a NEON implementation for ChaCha20 for fun, or write a zero-copy binary property list parser that’s faster than anything I’ve found. I have a decent understanding of performance. That doesn’t help me write this cross-platform app. I don’t have to time to write a novel native UI toolkit that allows me to share code while maintaining platform consistency and native performance. I don’t have time to fix the memory consumption of Chromium. I’m going to write my Electron app in JavaScript, carefully, and hope the performance will be acceptable (but not great). I don’t see how that can reflect on any individual programmer poorly.