"Learn once, write everywhere". Can't speak about performance comparison vs using Qt/.NET/whatever but the whole idea about React Native is that today, you can write a native app for iOS, tvOS, Android, web, macOS, Windows, and a few others, all using the same language and framework. You still have to understand platform specifics like UX guidelines but you use the same technology to build a fully customizable, and fully performant, native experience. It's sort of like using C++ but way more developer friendly.

The cons:

- an extra layer of abstraction

- need to write a plugin if you want to surface a native functionality to RN if it's not yet supported

- no visual UI editor like in native tools (Qt/VS), although you generally won't need it with React Native's code-first and instant refresh development workflow

- you need to be comfortable with React Native / JavaScript, obviously :-)

It's not gonna run everywhere, for the same reason WPF doesn't run everywhere. Given that the apps written with this will bind to Windows using C++, and there is no abstraction in between (like Qt), it's not gonna be portable. As far as I understand, it is going to be a reimplementation of React Native where the apps might have a similar style, but the backend will be completely Windows specific. And nothing will stop a developer from using native Windows APIs, so they will.

> The "current" subdirectory adds support for an earlier React Native for Windows10 implemented from scratch in C#. It reimplemented the JS<->Native bridge in C#, and shared the JS with Facebook's implementation of React Native. The ongoing direction of React Native involves a closer interaction between C++ and JS which is hard to achieve with a separate C# implementation.

Given that they say that the "old" version "shared the JS" in past tense, that seems to hint that the "new" version will not share the JS? In that case, what is left of React? It sounds like it will be the same style of API and workflow, but different widgets and no cross-platform compatibility.

Source: https://github.com/Microsoft/react-native-windows/blob/maste...

He said "Learn once, write everywhere" not "Write once, run everywhere"

You can also write a native app for Android/iOS/tvOS/Windows/macOS/Linux and a few others, all using the same language and framework - C++ and Qt - see: https://doc.qt.io/qt-5/supported-platforms.html

It's impossible to use native widgets with Qt. React Native for Windows will make it possible to write applications in the React style (PropTypes and automatic propagation of updates), but using native Windows widgets.

While Qt emulates something like WinForms quite well, I don't think it emulates WPF widgets at all, which I speculate this wraps.

Given that WPF is the primary GUI toolkit on Windows, the only reason to accept Qt, is if you're making something like a WinForms application that you need to run on all platforms.

Sounds like it will bring React apps a lot closer to their Windows underpinnings:

> Sometimes an app needs access to a platform API that React Native doesn't have a corresponding module for yet. Maybe you want to reuse some existing .NET code without having to reimplement it in JavaScript, or write some high performance, multi-threaded code for image processing, a database, or any number of advanced extensions.

> React Native was designed such that it is possible for you to write real native code and have access to the full power of the platform. This is a more advanced feature and we don't expect it to be part of the usual development process, however it is essential that it exists. If React Native doesn't support a native feature that you need, you should be able to build it yourself.

Source: https://github.com/microsoft/react-native-windows/blob/maste...

The new version wraps WinUI/UWP widgets not WPF

All right. Still Windows specific though. Could WinUI/UWP become available on e.g. Linux, or is inherently bound to Windows?

Qt's licensing for commercial products is something like $500/month/developer. For a small team of 6 developers, that's $36k in licensing a year. Unfortunately, you're not allowed to take existing Qt code and "port" it over to the commercial license -- you're required to start from scratch IIRC.

You can use the open source version of Qt with LGPL for commercial products.

Does QT use the latest C++ standards? Or do you have to adhere to old conventions?

Qt itself puts lots of effort on compatible APIs. Therefore they don't fully push "modern" APIs. However internally they use a lot of modern C++ and enable many modern things in different small steps. For a C++14/17 purist it will still be "ugly", though.