For the most part the games just work, it's more system issues that I've run into where Linux suspend mode and the audio stack can be a little flaky and required Claude to diagnose and sort out.

Bad code has a cost associated with it as well, it takes time to reject it, explain why it's wrong, and deal with the frustration of someone less experienced. Unfortunately with some developers they want to push that off on the person writing the code and bear none of the burden.

I've seen the costs of the latter in open source projects I've worked on. People who feel encouraged stick around, support the community, and when given good feedback will often learn from it and submit better patches. Taking the time to communicate and make sure everyone feels included is part of the cost to get that.

For me the problematic dynamic came from having things upset me and build up until I would get so angry it would explode outward. I grew up learning to hold it in, so I had no idea I could talk about problems with people. It wasn't so much letting go of the anger as talking about feelings and difficulties with people allowed me to avoid hitting that breaking point and over time, the anger and resentment has faded. Additionally, those conversations led to a level of trust where I feel like I can reach out to the person when something comes up or even strongly supported by them.

Coming from alcoholic parents, you might want to check out Al Anon. I found that and Codependents Anonymous invaluable as places where I was surrounded by people struggling with many of the same social issues I did. Also, it was unique in that it's an environment where talking about these sort of things is encouraged and invited, in public I tend to find that people find these topics uncomfortable and unwelcome.

The only time you need to access Electron APIs is to create and manage windows, system menus, etc.

For all the hate against it, we've been very happy with Electron. There's no way we'd have been able to afford to offer Windows and OS X given our limited budget without it.

The React way of managing views makes a lot of sense - change a variable and the whole UI updates accordingly. Also, rather than going through the typical debug, modify code, recompile cycle, there is a Hot Reload mode in RN where your code updates are immediately applied when you save. Laying the UI out with RN's CSS-style syntax is a lot easier than doing it by hand or mucking with Interface Builder / Android XML files. There is a lot that RN wraps around that gives easier management of than the native approach to, e.g. a BackButton component vs. dealing with a stack of Android fragments.

I haven't done any PhoneGap programming, the lack of native UI always scared me off. Without that, I never felt like I could hit a level of polish that was acceptable. The nice thing with RN is you can build you own native components and access native functionality as needed. It's not super well documented, but powerful when you need it.