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