5 ms·
Electron seems to have reached the status of being a political topic. For many people it's something to rally around or (more frequently here) against. You're e
by westoncb 5y ago
Electron seems to have reached the status of being a political topic. For many people it's something to rally around or (more frequently here) against. You're either for it or against it.
The above arguments would not be taken seriously on another topic, but here their weakness can be overlooked (by some) since folks are already committed to the the stance they support.
Look at the argument more closely: they're naming several random bugs. You can name several random bugs related to any UI framework on the planet with a sufficient user count. It's meaningless.
I'd urge people to look a little closer at arguments being put forward by the anti-Electron faction here if you don't yet have data yourself.
For myself, whenever I read these kinds of comments (or the tiresome refrain about absurd memory usage) it feels to me like there must be two Electrons: the first being the Electron which is the foundation of nearly every app I actually find useful these days (which do not exhibit e.g. exorbitant memory consumption issues [it's a marginal, non-issue increase in my experience] or higher bug-rates than native apps)—and then there's the second Electron, which afaict is a conceptual construction supporting a particular perspective on the 'correct' way of writing software (hint: anything using web tech isn't it).
Edit: something that would help move legitimate analysis of this topic forward: comparisons to other frameworks should be made after normalizing with respect to feature count/complexity, i.e. how much higher is memory usage vs. a competing app that actually offers similar features—e.g. comparing Discord to an IRC client would not be particularly informative (but that kind of mismatched comparison seems to be a common source of misconceptions here)
- Nicksil 5y agoOf course any point is meaningless when you define it as such for yourself. Your differing perspective and casual dismissal doesn't make their points any less relevant. The points they brought up are not meaningless and more people than what it seems you imagine are affected by the shortcomings outlined by the points made prior.
- westoncb 5y agoBut... I didn't dismiss them, I specifically addressed the flawed structure of their argument. They made some more assertions in the second paragraph but didn't offer any support for them so I haven't addressed them separately. With something like: "Undo support used to be table stakes, but now I'm surprised when it works" —I have to go back to the "two Electrons" I mentioned previously: not sure what world this is where software and business interests have so radically altered as to no longer support e.g. undo. It sounds like they ran into a bug related to undo somewhere and now are weaponizing the fact (as in their first paragraph) as a general argument against the framework.
- pseudalopex 5y agoBasic keyboard shortcuts and undo support aren't random bugs.
- ridiculous_fish 5y agoThese are not "random bugs" but deeply established Mac UI conventions. My point is not "Electron apps are buggy," it's that they are undermining an established set of UI conventions, without advancing a replacement. There's a virtuous cycle when apps use a platform's native components: apps get the standard UI behaviors for free, users can bring their knowledge from one app to another, and the platform owner can enhance the UI frameworks, improving all the apps on the platform. At least that's the hope. I can see a future dominated by Electron apps. But Electron is not converging on a new set of UI behaviors that I can bring from one app to another. In any given Electron app, gestures like arrow keys work differently not only from native apps, but from other Electron apps. So I don't use the arrow keys: one less word in my UI vocabulary.
- deleted 5y ago[deleted]
- westoncb 5y agoOkay I think I see what you're saying here. The terminology of reducing "UI vocabulary" threw me off some, since you could alternately describe it as an expansion of UI vocabulary: so many things don't have a convention yet that every developer is free to define their own (similar situation in e.g. video game UI where there's constant invention since a fixed widget set isn't getting re-used). > ... they are undermining an established set of UI conventions, without advancing a replacement. > There's a virtuous cycle when apps use a platform's native components There's certainly an advantage there, but it basically comes down to whether you more highly value cross-platform capabilities or specialization for a specific platform. So why not acknowledge it as the tradeoff it is? Instead the common stance here is to frame it as some kind of cataclysmic regression in software development. Anecdotally, as someone using mostly Electron-based software, I've yet to run into any kind of issue related to platform integration—but I wouldn't be surprised if people ran into an occasional glitch or inconvenience there. It makes sense given what the software is.
- ryandrake 5y ago> whether you more highly value cross-platform capabilities or specialization for a specific platform. I'd argue that very few, if any, end users care that an application works and looks exactly the same on Windows vs. Mac vs. Linux. The typical end user has one platform they use, and they expect their applications to behave consistently with each other on that platform. The people who tend to care about being consistent across platforms are 1. developers who don't want to write platform-specific code to properly support each platform, and 2. designers for whom platform conventions are inconvenient constraints and get in the way of the great vision they drew in Photoshop. In other words, not end users, who are usually the actual target market.
- AnonHP 5y ago> For myself, whenever I read these kinds of comments (or the tiresome refrain about absurd memory usage) it feels to me like there must be two Electrons: the first being the Electron which is the foundation of nearly every app I actually find useful these days (which do not exhibit e.g. exorbitant memory consumption issues [it's a marginal, non-issue increase in my experience] or higher bug-rates than native apps) It’s also very tiresome to see such weak defenses when one looks around at the experience of people who have only 8GB RAM and are running Windows 10. If it’s just a war of anecdotes, I have several to share on why Electron is bad (or is badly used) by apps like MS Teams and others. Long ago, people used to complain about Java apps (mainly due to startup time). Electron apps make those seem like nothing to complain about. It’s not just high memory usage or the UX being poor, it’s also about being a poor citizen on the computer and making things worse for all the other applications running at the same time.
- westoncb 5y agoI only upgraded from my 8GB laptop a couple months ago. And I did run into issues with memory frequently—but here's the thing: I would be running 4 or 5 Electron apps at the same time and they were fine; the memory issues were always from Chrome, so I had to be careful not to keep too many open Youtube, Github, Amazon, etc. tabs open. A heavier Electron App, e.g. Slack, would be equivalent to maybe two Youtube tabs, out of the ~50 tabs I would have open. It's not ideal, but it's nowhere near as egregious as comments on HN would leave you to believe. > it’s also about being a poor citizen on the computer and making things worse for all the other applications running at the same time I'm not familiar with this argument. How is it a poor citizen aside the dubious claims about excess memory usage? Or is this just a repetition of that argument? (Incidentally I've also had the misfortune of using MS Teams recently, and I would fully support anyone's complaints about it.)