I am on the team at Microsoft that helped bring UWP to React Native. If there are questions, feel free to AMA.
PS. Many thanks to the Facebook team for building a great platform in React Native and their critical help in helping us bring Windows to the platform.
We are working on Facebook on the best long term strategy for maintaining UWP support. Our fork is only to add the ReactWindows directory and to otherwise track master in the process.
Because it's 2016 and the notion of pinning to C++ is sort of antiquated. C++ can deliver better performance in some cases, but it also brings about a great deal more risk of security issues involving arbitrary code execution and data corruption.
You have to have VERY tight performance requirements to make C++ worth the risk it entails, in my opinion. If the only thing standing between you and a code injection exploit is developer discipline and best practices, then you're in a strictly worse place than managed code.
I actually think C++ is a very good choice in 2016 for the following reasons.
1. C++ is the only high-level language that is vendor supported across Linux, OSX, iOS, Windows, Windows Phone, and Android. React Native is aiming for cross-platform, using a cross-platform non-proprietary language would seem to be a better match. Along the same lines, there is less risk of vendor lock-in with C++ than with C#
2. While raw performance may be less of an issue, with mobile lightweight devices where use is limited by how long the battery lasts - performance per watt becomes an issue. Having a higher performance language can result in using less power and thus a better user experience.
3. Modern C++14 is much better in terms of memory safety and ease of use. The main issue with C++14 vs C# is that C# has better libraries, not with intrinsic usability of the language.
4. The issues with code execution and data corruption are significantly mitigated by the fact that you are targeting basically a sandboxed application. In addition, it is interesting to note that most desktop Win32 applications that people use on a daily basis are probably written in C++, and they have far more permissions than a universal windows app.
This is such a concise and informed comment. Why has it been voted down to being barely dim on my screen? These are good arguments. Please reply to stuff like this instead of knee-jerk downvoting.
I sit upon my horde of HN karma burning it daily. I knew I'd be downvoted for replying to a language preference quote. Especially given how very charged the C++ community is as they feel increasingly abandoned by Microsoft.
But that argument revolves around the growing importance of the Microsoft software store. Its actually an argument between ISVs and Microsoft about how much control MS can have in software distribution and security.
Isn't that a performance concern though? Especially within the context of a react native implementation that environment is already going to push you way above what is achievable with C++.
If we're talking a 5% reduction in the net heap usage for a react native app at the cost of substantially more error prone code, is that really a win? Hell, make it 10%? These apps still readily fit in mobile hardware, and you wouldn't be using react native on a Pi or other more tightly resources embedded system.
Our belief is that using C# enables many more developers to contribute to the project and build plugins versus using C++0x. That said, this is not a final decision. We are open to making a change here if community overall has a reasoned opinion backed by data for using C++ instead.
I do wonder if having two garbage-collected runtimes in the same address space will lead to pathological performance and/or memory usage. But I don't have any solid data on that. Of course, if that is a problem, then it also applies to React Native on Android, but there, it's unavoidable.
As C++ is the native language for the UWP, surely it would map more neatly to the platform?
And the well-known performance and memory advantages, however small, are critical for mobile devices. I don't think Microsoft should commit long-term to C# on mobile just as both Apple and supposedly Google are migrating to Swift as the future of their platforms, for good reason.
> And the well-known performance and memory advantages, however small, are critical for mobile devices.
Windows Phone is many things, and few of those things are good. But in terms of UI responsiveness and overall speed, it puts my android to shame and competes with my iPhone.
And the security story of unmanaged languages is perilously bad. I don't see how people justify it anymore.
This might be far fetched but is there any chance there are plans to enable OSX devs to work with Windows Phone apps? I love my phone, but I can't use anything else than OSX.
This is a huge game changer. We have OS X support with React Native Desktop [0], so that means only Linux support is missing!
I've wondered why we haven't seen a React Native Qt, React Native Gtk+, or React Native Elementary yet. But I guess those communities just aren't very interested in what JS people are up to.
Agreed. React Native is turning into what a lot of us were hoping QT/QML would. But QT offers a very poor experience to both users and developers for mobile use, due to both license issues (making users download an additional binary scares most of them off) and to the uncanny valley caused by using non-native widgets. React Native has neither of these problems on mobile.
QT still rules the desktop, but it looks like only React Native offers hope for a true cross-platform GUI framework.
Thanks, I'm working on it full-time. If you are an everyday Linux user (especially not Ubuntu) and willing to test and/or answer to some questions please reach me out on unknownliveid@hotmail.com.
I hate to be a naysayer because this is great work and all, but frankly, managing all these platforms is going to be a nightmare. In a traditional engine, the code for each platform is embedded at the lowest level of abstraction. That is the way it works for iOS and android at the moment, but adding new platform support via extensions will make the code harder to manage and reason about. I don't want a separate extension for OSX, Windows, and Linux. I want all the code about, say, filesystem handling to be in a single place (in neatly separated platform specific files). This applies to networking code, rendering, input, etc. I know at the bottom of the article there is hope of integrating it with the original project, but given that we are starting literally on the opposite end of the spectrum, I'm worried we will never reach this hypothetical nirvana. The original react native team needs to prioritize getting other platforms in the original codebase, and I may be mistaken, but I have not yet observed this, and so have some cause to worry.
> Excluding all the work on core and third party module parity, and store preparation, there was certainly less than 1 week of 1 developers time dedicated to platform customization and style tweaks in JavaScript.
Wow - great news! We were launching our relatively complex app iOS only, but had some downtime and decided to see how the Android implementation fared: it worked really well (much better than I expected) and hasn't taken much effort to have something that feels really nice.
I have to expect that a framework like this will not work exactly as well as 'True Native' (to coin a phrase), and and as there are now a number of platforms it needs to work across that all functionality exposed by React Native will not work equally well across all platforms.
Is there a resource that compares React Native's functionalities across the platforms ( performance characteristics, behaviors, appearance, and so forth?)
Well, Corvoda and Xamarin are only for mobile apps. If React Native begins officially supporting desktop platforms, it'll be the only (popular) framework of its kind.
Cordova and Xamarin both give you desktop reach on Windows through the UWP. You may be using the UWP to target mobile first and may not think to test for desktop, but both give you that option to expand into desktop.
You can somewhat easily rehost a Cordova app in Electron for desktop reach on Mac and Linux (and even Windows if you prefer Electron to the UWP for some reason).
There already are Xamarin Framework bindings for the Mac and you shouldn't have too hard of a time to use existing Gtk# resources to target Linux. Now that Xamarin Forms is true open source maybe someone will have more incentive to build a good XAML binding and Xamarin Forms implementation for Gtk# (or some other Linux UI toolkit for that matter).
It works on anything since it's just for platform support and unrelated to tooling. But on the tooling side, they also have a companion extension for (the free, multi-platform) Visual Studio Code. From the article:
> In addition to this work on the core framework support, Microsoft is also providing open source tools and services to help developers create React Native apps. The React Native extension for Visual Studio Code (https://code.visualstudio.com/) brings an intuitive, productive environment to author and debug React Native apps.
In addition to the free extension for VS Code (which is free and open source, and available on Mac, Linux, and Windows), we have a free and open source service called CodePush (https://microsoft.github.io/code-push/) for instantly pushing React Native apps to devices.
PS. Many thanks to the Facebook team for building a great platform in React Native and their critical help in helping us bring Windows to the platform.