[hungerstrike]

React is great, but I really like the idea of multi-process desktop apps, where the rendering happens in one process and one or more controlling processes pipe events to and from it. That way you could use any language to build your controllers and the native render could be written in a different language that is native to the OS.

I think the guy who makes SumatraPDF did something along those lines with Swift and Golang, to build a Mac app.

[lilactown]

That's pretty much what React Native is, but using JS as the control and React's declarative API.

[hungerstrike]

I thought React ran in-process for native apps.

[chrisco255]

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.

[hungerstrike]

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.

[lilactown]

Yeah, I think the React Native implementations being intra-process has only been a function of mobile OS's sandboxing requirements. A macOS / Windows / Linux application can feel free to separate the processes, which I agree does sound nicer on the surface.