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

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

58 pointsAlikhanPeleg26 comments

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.

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

Nice. Thanks for sharing.

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/) 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.

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.

The .net has Eto.Forms which does something similar

https://github.com/picoe/Eto

Huh? There are thousands of successful apps doing exactly that. The browsers Electron builds upon are the prime example!

How so? They are rendering HTML, not native elements.

They probably mean the underlying browsers like chrome or Firefox.

libui[0] is C library that aims to provide this. It have many (WIP) language bindings.

[0] https://github.com/andlabs/libui

You could say that's why web won. OP should ask (and perhaps share with us) why the native widgets are important, genuinely interested!

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

I googled for Blink and couldn't find what I think you might be referring to. Would you mind dropping a link to Blink?

The blink rendering engine inside chrome?

yep

It's Google's fork of WebKit: https://en.wikipedia.org/wiki/Blink_(web_engine)

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.

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

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.

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.

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

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.

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.

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.

Reply on news.ycombinator.com