6 ms·

Ask HN: Is a React Native like approach to desktop apps better than Electron?

58 points by AlikhanPeleg 8y ago

jeffbax 8y ago
Its hard to know without comparison apps, but if it means you aren't just running everything in a browser (and thus, way higher memory usage and likely much crappier native-OS behavior if any at all) -- yes
hungerstrike 8y ago
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 8y ago
  That's pretty much what React Native is, but using JS as the control and React's declarative API.
  - hungerstrike 8y ago
    I thought React ran in-process for native apps.
    - chrisco255 8y ago
      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 8y ago
        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 8y ago
        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.
cjbprime 8y ago
It 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.
- AlikhanPeleg 8y ago
  The .net has Eto.Forms which does something similar https://github.com/picoe/Eto https://github.com/picoe/Eto
- izacus 8y ago
  Huh? There are thousands of successful apps doing exactly that. The browsers Electron builds upon are the prime example!
  - dyeje 8y ago
    How so? They are rendering HTML, not native elements.
    - chillacy 8y ago
      They probably mean the underlying browsers like chrome or Firefox.
- mhasbini 8y ago
  libui[0] is C library that aims to provide this. It have many (WIP) language bindings. [0] https://github.com/andlabs/libui https://github.com/andlabs/libui
- gt2 8y ago
  You could say that's why web won. OP should ask (and perhaps share with us) why the native widgets are important, genuinely interested!
spankalee 8y ago
Blink has so much investment, and is moving so fast, that I don't think React Native's renderer can keep up meaningfully. As far as I know it doesn't support s huge number of useful CSS, like Grids, variables, transitions, multiple border styles, text-transform...
- ryanmarsh 8y ago
  I googled for Blink and couldn't find what I think you might be referring to. Would you mind dropping a link to Blink?
  - AlikhanPeleg 8y ago
    The blink rendering engine inside chrome?
    - O_H_E 8y ago
      yep
  - SteveGregory 8y ago
    It's Google's fork of WebKit: https://en.wikipedia.org/wiki/Blink_(web_engine) https://en.wikipedia.org/wiki/Blink_(web_engine)
    - ryanmarsh 8y ago
      Oh yes, definitely. Momentum matters. I said in another thread here a long time ago, down-voted to hell, that these electron apps would "win" purely because of the momentum. We tend to look at a technology and assess it as a snapshot now. We (people in general) don't usually treat a technology as a function of (now * momentum). I think it's pretty well proven that with technology motion is everything. There are plenty of great things that started out bad, bad things that started out great, and good things that never became great. Motion is the difference.
solarkraft 8y ago
Yes. It still leaves you with the monster of Javascript frameworks, but the (very, perhaps more, significant) monster of running (and distributing!) a browser for every app. It's also arguably easier to make it look nice.
BinaryIdiot 8y ago
As a user I think it is. It doesn't have to be React Native but using actual native components makes applications feel so much better and use far less memory. Take Slack for instance, decent feature set but feels like a web app with how it works and some of the error conditions it fails to handle correctly (like no longer being authenticated requiring a _refresh_ of the app to fix). I don't know if React Native is technically the answer but an approach _like_ RN, like you asked OP, makes the most sense to me from a user standpoint. From a developer standpoint, even with cross platform toolkits like RN, it _really really sucks_ managing multiple platforms. I can understand why most go for Electron or similar. We really need some better, cross platform stories for developers.
petercooper 8y ago
For anyone who's interested, https://proton-native.js.org/ https://proton-native.js.org/ is basically React Native but for desktop apps.
- bruinjoe 8y ago
  Nice. Thanks for sharing.
brody182 8y ago
what is a good way to encrypt (protect) the electron code files? any good tutorials? is this possible with proton-native?
flavoie 8y ago
I don't think it's "better", it mostly depends on what you want to achieve. Users, except the tech savvy one, will not notice if you do a nice job. (hard to miss with UI framework like fabric, semanticUI, etc..) If you want a small application that start fast and/or use system look and feel. A react-native approach (like https://proton-native.js.org/ https://proton-native.js.org/) will be better. If you plan to customize/brand your apps and the app will run for a long time, it doesn't really matter. The downside is that it will take more memory. Also, v8, constantly improve, reduce memory usage and optimize javascript performance. Soon it will be easier to run faster code with webassembly. It's even possible now to compile your typescript code with AssemblyScript, or do it the hard way with C, C++ or Rust. It's only a matter of time before the performance between the two will be reduce. As for the problem mention about the whole browser ship with every apps. Maybe we will see a solution similar to adobe air in the future or a way to strip down blink based on the app requirements. Technically a browser is just a standardized drawing library, like flutter uses skia, Qt it's own or GTK uses cairo.
jamespetercook 8y ago
There are rumours that Apple is working on “marzipan” which will allow iOS apps to be compiled for the Mac by targeting x86. React native could be coming to the desktop.

58 points by AlikhanPeleg 8y ago

Its hard to know without comparison apps, but if it means you aren't just running everything in a browser (and thus, way higher memory usage and likely much crappier native-OS behavior if any at all) -- yes

hungerstrike 8y ago

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 8y ago
That's pretty much what React Native is, but using JS as the control and React's declarative API.
- hungerstrike 8y ago
  I thought React ran in-process for native apps.
  - chrisco255 8y ago
    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 8y ago
      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 8y ago
        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.

cjbprime 8y ago

It 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.

AlikhanPeleg 8y ago
The .net has Eto.Forms which does something similar https://github.com/picoe/Eto https://github.com/picoe/Eto
izacus 8y ago
Huh? There are thousands of successful apps doing exactly that. The browsers Electron builds upon are the prime example!
- dyeje 8y ago
  How so? They are rendering HTML, not native elements.
  - chillacy 8y ago
    They probably mean the underlying browsers like chrome or Firefox.
mhasbini 8y ago
libui[0] is C library that aims to provide this. It have many (WIP) language bindings. [0] https://github.com/andlabs/libui https://github.com/andlabs/libui
gt2 8y ago
You could say that's why web won. OP should ask (and perhaps share with us) why the native widgets are important, genuinely interested!

spankalee 8y ago

Blink has so much investment, and is moving so fast, that I don't think React Native's renderer can keep up meaningfully. As far as I know it doesn't support s huge number of useful CSS, like Grids, variables, transitions, multiple border styles, text-transform...

ryanmarsh 8y ago
I googled for Blink and couldn't find what I think you might be referring to. Would you mind dropping a link to Blink?
- AlikhanPeleg 8y ago
  The blink rendering engine inside chrome?
  - O_H_E 8y ago
    yep
- SteveGregory 8y ago
  It's Google's fork of WebKit: https://en.wikipedia.org/wiki/Blink_(web_engine) https://en.wikipedia.org/wiki/Blink_(web_engine)
  - ryanmarsh 8y ago
    Oh yes, definitely. Momentum matters. I said in another thread here a long time ago, down-voted to hell, that these electron apps would "win" purely because of the momentum. We tend to look at a technology and assess it as a snapshot now. We (people in general) don't usually treat a technology as a function of (now * momentum). I think it's pretty well proven that with technology motion is everything. There are plenty of great things that started out bad, bad things that started out great, and good things that never became great. Motion is the difference.

solarkraft 8y ago

Yes. It still leaves you with the monster of Javascript frameworks, but the (very, perhaps more, significant) monster of running (and distributing!) a browser for every app. It's also arguably easier to make it look nice.

BinaryIdiot 8y ago

As a user I think it is. It doesn't have to be React Native but using actual native components makes applications feel so much better and use far less memory. Take Slack for instance, decent feature set but feels like a web app with how it works and some of the error conditions it fails to handle correctly (like no longer being authenticated requiring a _refresh_ of the app to fix). I don't know if React Native is technically the answer but an approach _like_ RN, like you asked OP, makes the most sense to me from a user standpoint. From a developer standpoint, even with cross platform toolkits like RN, it _really really sucks_ managing multiple platforms. I can understand why most go for Electron or similar. We really need some better, cross platform stories for developers.

petercooper 8y ago

For anyone who's interested, https://proton-native.js.org/ https://proton-native.js.org/ is basically React Native but for desktop apps.

bruinjoe 8y ago
Nice. Thanks for sharing.

brody182 8y ago

what is a good way to encrypt (protect) the electron code files? any good tutorials? is this possible with proton-native?

flavoie 8y ago

I don't think it's "better", it mostly depends on what you want to achieve. Users, except the tech savvy one, will not notice if you do a nice job. (hard to miss with UI framework like fabric, semanticUI, etc..) If you want a small application that start fast and/or use system look and feel. A react-native approach (like https://proton-native.js.org/ https://proton-native.js.org/) will be better. If you plan to customize/brand your apps and the app will run for a long time, it doesn't really matter. The downside is that it will take more memory. Also, v8, constantly improve, reduce memory usage and optimize javascript performance. Soon it will be easier to run faster code with webassembly. It's even possible now to compile your typescript code with AssemblyScript, or do it the hard way with C, C++ or Rust. It's only a matter of time before the performance between the two will be reduce. As for the problem mention about the whole browser ship with every apps. Maybe we will see a solution similar to adobe air in the future or a way to strip down blink based on the app requirements. Technically a browser is just a standardized drawing library, like flutter uses skia, Qt it's own or GTK uses cairo.

jamespetercook 8y ago

There are rumours that Apple is working on “marzipan” which will allow iOS apps to be compiled for the Mac by targeting x86. React native could be coming to the desktop.