Ask HN: Is a React Native like approach to desktop apps better than Electron?
21–28 of 28 posts
Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#22For anyone who's interested, https://proton-native.js.org/ is basically React Native but for desktop apps.
Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#23Earlier quoted context omitted.
That's pretty much what React Native is, but using JS as the control and React's declarative API.
I thought React ran in-process for native apps.
Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#24Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#25Earlier quoted context omitted.
I thought React ran in-process for native apps.
No, the React process and JS engine run on a separate thread from the main UI thread. The JS thread just passes messages to functions defined natively on the main thread. A lot of this is abstracted away in the components themselves.
If you wanted to use React to render a view for a Golang controller, you’d have to embed a JavaScript engine in your Go process or vice-versa. That’s why I like the idea of a multi process desktop UI kit that coordinates with the renderer via pipes. You could actually use React to do the rendering in this case as well.
Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#26It can be in theory, but in practice managing native widgets across all major platforms is such a mammoth project that it's almost impossible. People have been trying for decades, rarely with success.
Re: Ask HN: Is a React Native like approach to desktop apps better than Electron?
#27Earlier quoted context omitted.
No, the React process and JS engine run on a separate thread from the main UI thread. The JS thread just passes messages to functions defined natively on the main thread. A lot of this is abstracted away in the components themselves.
Yes different threads, same process. If you wanted to use React to render a view for a Golang controller, you’d have to embed a JavaScript engine in your Go process or vice-versa. That’s why I like the idea of a multi process desktop UI kit that coordinates with the renderer via pipes. You could actually use React to do the rendering in this case as well.