You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.
- write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature)
- write native UI code using native tooling, and call the business logic library from there.
But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.
I suspect it will be the best way going forward, other approaches all have serious issues.
- It forces you to think about your business logic vs. UI structure.
- It forces you to make your core logic library easily testable.
- Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly.
- The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM.
- Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well.
Biggest issues?
- Getting inflexible people to learn anything other than JavaScript.
- Getting slow compile times under control.
- Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase.
- Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.
We used C++14 which has a pretty good standard library and plugged the holes with some parts of Boost and then standalone libraries like SQLite, json11 and others to provide missing functionality.
I believe it was due to JNI but my memories may be wrong.
Electron is a UI 'framework', so bringing it up is kind of a non sequitur. Your approach of a C++ core is entirely compatible with an Electron UI.
I worked on a project that had its 'core logic' implemented in C++, which we then ran that on the web in Javascript, for the same portability reasons.
We actually used their own Djinni library on one of the projects and it worked well - but even at that time the Dropbox team wasn't maintaining it at all since they never used this approach beyond the short-lived Carousel app.
I have intentionally kept my very specific use case mobile app very very simple and not gone deep on the magic edge cases. It is a private app and will never be on the store. It is basically used as a QR code scanner to track equipment.
I'm sure that if you have a lot deeper/larger apps you'd find more to complain about, but so far I'm happy enough with going from zero to full fledged app in about a month of work.
IMHO, the boilerplate argument with Java is kind of outdated (Project Lombok and modern java solve a lot of that).