It’s important to be mindful that the engineering is a minority slice of all the decisions that go into a product’s development.
The reason why some engineers need to be managed by Product and Project is that they don’t think hard about all the constraints, such as the cost of developing multiple native apps vs. the benefit that would provide.
This is often due to a failure of empathy: many engineers envision the common user being like them, when really the common user doesn’t know, notice, or care about whatever this “Electron” thing is.
I’ve seen, time and time again, developers having loud opinions about how choosing X over Y is because people are dumb, or cheap, or inexperienced. Those are all possible, but not nearly as common as they think. They’re easy explanations. But I rarely see developers do the engineering part where they quantify the issue and make a case for picking X over Y.
If developers hate Electron so much, the answer is to develop the skill set for making an informed argument that isn’t limited to just things like RAM and latency and file size. These often aren’t compelling business reasons. They’ll either learn more about why Electron gets picked, or they’ll have a solid case to make for why not to pick it.
I'm on a four-person team building a React Native app. RN is awful, I'll admit, but it would be impossible to work at the pace we do if we were maintaining fully parallel Android and iOS codebases.
Besides, it's the hardware's job to optimize for the capabilities of the SDK.
I was with you for the first paragraph. But that's just despicable thinking:
> Besides, it's the hardware's job to optimize for the capabilities of the SDK.
You can't possibly blame the hardware manufacturers for how poorly React Native runs. Even if the CPU engineers wanted to target React specifically and make it run better somehow (and you seem to think they should), where would they begin? React sits on top of 35 layers of software abstraction and runs in 2-3 virtual machines, how could they target RN?
Assuming they could add magical instructions that benefit React somehow, who's going to patch the 34 lower layers for React to benefit from it? The manufacturers? The React team? You?
I don't have any performance issues with React Native[0], so as far as I'm aware the status quo is fine with regards to how well the hardware is optimized for the SDK. The specific SDK I'm referring to is JSCore, obviously everything on top of that is third-party.
[0] My main beef with React Native is the total lack of useful stack traces. Also, when running on a device, when you tap Debug before manually setting your dev machine's IP, the app is bricked and you have to delete and reinstall it.
This is why you need to become king. In many places, it is the only way to truly deal with this nonsense. Top-down.
If you want a big org to defenestrate electron, your #1 mission is to generate a very scary narrative that electron is a 'legacy' technology and that your competition is already 2 steps ahead. You could spin little lies like "I overheard a member of KPMG discussing our competition's use of SSR and native local apps to deliver leading-edge UX while at lunch last week".
The super shitty thing about electron is that it does, arguably, reduce the overall complexity of delivering an end solution (regardless of the UX). My traditional arguments that complexity is at the heart of all evil do seem to go hard against this idea that I can code an app one time and deploy it everywhere. Clearly, this is not how it works out in practice, but the savings are definitely somewhere in the middle and detectable.
What does HN think about the complexity argument for using electron?
