React Native for Windows and Mac

This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers.

Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi.

[1] https://cancel.fm/ripcord/

Exactly like a web browser.

only a portion of the actual running code is JS

“Only a portion” meaning your entire React application! The native parts are the RN framework, any native libraries you’re using, and any native code you’ve added yourself.

What RN brings to the table, as compared to a browser, is a different layout model that’s simpler than the DOM and maps a bit more closely to native widgets.

It also has APIs for sending messages back and forth between JS and native code. That’s also possible with WebViews on all platforms, but RN has a more consistent API (at least on the JS side), so a decent amount of native bindings have been written by third parties.

Or not. I've worked on plenty of applications that had few if any dependencies for those things. I'm sure many others have too.

In some cases that was because we didn't need that particular functionality. Routing has little value if you're building an in-house SPA that always starts from the same dashboard anyway, for example.

In other cases, it's because we're programmers and don't import entire library ecosystems to do what we could do ourselves with a few lines of code or some APIs that are already supported by all modern browsers anyway.

I liked React when it first arrived, because it was a tool that was that did one useful job and did it reasonably well. I dislike the direction it's taken more recently, because it now seems to be trying to do several jobs and not doing most of them very well at all. I understand that this is partly because of the way some developers coerced React into doing things it wasn't really suitable for and the React dev team have been responding to that, but I still think value has been lost in that process.

It definitely isn't, Dart is an advanced clean, strongly typed classical language without JS's warts that's just as clean & productive with a clean complete & well-defined standard library, native support for modules, consistent async/await in all libraries, etc.

I love TypeScript, but it's major productivity advantage over Dart is in JS's dynamism, something that's a lot more restrictive in Dart because it needs to support AOT, which is what allows it to compile to native code & advanced linking + tree-shaking, resulting in its better performance. So there are areas where you need to use code-gen, but having wasted an eternity trying to diagnose runtime issues in C#/Xamarin in libraries that use reflection, I'd much rather use an AOT language that only provides language features that natively supports AOT then running into frequent on-device issues that only occur at runtime.

> For mobile right now, the easiest, most headache-free solution may actually be to forget about cross-platform and just do separate Android and iOS native apps.

Nope, Flutter's Reactive UI & live-reload is far more productive then developing using native iOS or Java/Kotlin tools (which can also be used in Android Studio). SwiftUI is close if you just need to develop for iOS, but I find Dart/Flutter to be a lot more productive than using Swift & Xcode's woefully poor tooling support.