react-native-windows

UWP is pretty much alive. WinUI 3.0 and XAML Islands roadmap at BUILD 2019 https://mybuild.techcommunity.microsoft.com/sessions/77008 React Native for Windows reimplementation https://github.com/microsoft/react-native-windows React Native @ Microsoft, https://www.youtube.com/watch?v=IUMWFExtDSg And even if one disregards the fact that all new Windows 10 APIs are UWP based, the sandbox also applies to Win32 apps deployed via the store or MSIX packages. As for DirectCompute, game developers naturally.

It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? Regarding show, don't tell. The 21st century React Native for Windows is written on top of COM/C++, https://github.com/microsoft/react-native-windows https://www.youtube.com/watch?v=IUMWFExtDSg We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html.

Microsoft maintains it's own fork of react-native that allows this. https://github.com/Microsoft/react-native-windows There's more experimental forks for macos and qt.

Nope, WinUI roadmap https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... React Native for Windows rewrite on top of WinUI https://github.com/microsoft/react-native-windows Announcement done during last month's BUILD. UWP is live and well as Win32's successor.

Actually not, https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... React Native for Windows is being ported from C# into WinUI/C++. https://github.com/microsoft/react-native-windows Plus these guys should spend more time at BUILD and MSDN. All major Windows 10 APIs are UWP only, even if the store is gone, UWP is here to stay.

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# implementa

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 performanc

I think it's wrong/confusing to say that they're "launching" React Native for Windows. React Native for Windows is out already, and it works fine. They're just announcing the kickoff of a C++ rewrite. https://github.com/Microsoft/react-native-windows/blob/maste... > In this sub-folder, we are working on a vnext rewrite of React Native for Windows10 built in C++ that reuses the C++ core bridge implementation from Facebook’s React Native. This will allow React Native for Windows10 to innovate and provide features by sharing the same core as Facebook’s React Native. Cool, but this is basically just an implementation detail. (I do wish it supported Windows 7 and 8.)

ReactXP (https://microsoft.github.io/reactxp/) targets mobile and desktop platforms using the OS's native UI. Windows support is implemented via https://github.com/Microsoft/react-native-windows and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper. Theoretically you could port one of the react-native-desktop projects to use GTK or Qt. Then of course you have native iOS and Android components with Facebook's ReactNative and web support via React. ReactXP wraps all of these projects allowing you to write React components and TypeScript code that is shared among every platform. It's the same workflow as Electron, even less so, with native UI.

That's why ReactNative is my preference. There are forks of it that target Windows and MacOS using their native controls. Microsoft maintains the Windows ReactNative fork (https://github.com/Microsoft/react-native-windows) and they wrap React, ReactNative, and the desktop forks in their ReactXP project. I don't trust Google to emulate a perfect UI among all platforms. I feel like they're generating too big of a workload for no reason, it's a big red flag. I think eventually they'll give up on emulating native controls and choose a unified appearance for all platforms (forcing Material design for everyone) as well as giving the option to customize. I think their endgame is to push Flutter as much as possible so they have Fuchsia developers, then let the other target platforms go unmaintained. Their language, their OS, their devices.

Have you seen React Native Windows (https://github.com/Microsoft/react-native-windows) and react-native-macos (https://github.com/ptmt/react-native-macos)? I haven't used either, but they both look very popular, 5k-10k stars on Github.