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

As a user I think it is. It doesn&#x27;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).<p>I don&#x27;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.<p>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.

For anyone who&#x27;s interested, <a href="https:&#x2F;&#x2F;proton-native.js.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;proton-native.js.org&#x2F;</a> is basically React Native but for desktop apps.

I don&#x27;t think it&#x27;s &quot;better&quot;, it mostly depends on what you want to achieve.<p>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..)<p>If you want a small application that start fast and&#x2F;or use system look and feel. A react-native approach (like <a href="https:&#x2F;&#x2F;proton-native.js.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;proton-native.js.org&#x2F;</a>) will be better.<p>If you plan to customize&#x2F;brand your apps and the app will run for a long time, it doesn&#x27;t really matter. The downside is that it will take more memory.<p>Also, v8, constantly improve, reduce memory usage and optimize javascript performance. Soon it will be easier to run faster code with webassembly. It&#x27;s even possible now to compile your typescript code with AssemblyScript, or do it the hard way with C, C++ or Rust. It&#x27;s only a matter of time before the performance between the two will be reduce.<p>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&#x27;s own or GTK uses cairo.

It can be in theory, but in practice managing native widgets across all major platforms is such a mammoth project that it&#x27;s almost impossible. People have been trying for decades, rarely with success.

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

Its hard to know without comparison apps, but if it means you aren&#x27;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

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.<p>It&#x27;s also arguably easier to make it look nice.

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.

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.<p>I think the guy who makes SumatraPDF did something along those lines with Swift and Golang, to build a Mac app.