I've just started designing something very similar in my free time, but for Go (golang): interface around native GUI + WebKit webview + React + bindings.
I'm glad that we are slipping away from Electron...
Native widgets, bridge between JS thread and the native world. That gives you good performances and the flexibility of JS/Typescrit and React to glue things together.
(I haven’t tried yet, but that looks quite nice on paper)
Hm, as far as I know, the problem most people have with Electron is not around the language, React or bindings but the fact that there is a embedded browser in there that adds a lot to the size and memory consumption (and security issues).
I'm curious to hear why you're glad we're going away from Electron into something that seems to be about the same thing, albeit a different language?
I expect it to be a little better trade-off given the following points:
1. JS is kept for what it's meant to be and do; nothing more.
2. A WebKit webview is probably lighter than Chromium + NodeJS.
3. The whole thing should be managed to be linked as a shared library, avoiding many pitfalls of Electron's applications (by means of a semantic-versioned library).
4. The whole solution is really language-agnostic, despite my efforts with Go.
It goes even further as it get rid of the webview
https://microsoft.github.io/react-native-windows/
Native widgets, bridge between JS thread and the native world. That gives you good performances and the flexibility of JS/Typescrit and React to glue things together.
(I haven’t tried yet, but that looks quite nice on paper)