React Native on the Universal Windows Platform | Hacker News Reader

React Native on the Universal Windows Platform

blogs.windows.com

246 pointsoutside123450 comments

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.

Currently, it's a fork. Do you have plans to merge it in the main react-native repo? When?

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.

Why does this generate C# instead of C++?

Why not? Seems like a reasonable thing to do. Is there a specific reason it should be C++?

Runtime memory usage and startup perf is better for C++ XAML apps.

UWP C# apps are AOT compiled, the startup hit isn't that bad nowadays.

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.

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.

My two cents.

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

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.

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.

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.

Agreed. I would actually be curious to read some counterarguments. Alas, noone has offered any

I think the community has a prevailing opionion that C# is part of a UWP lock-in and they're concerned about that.

I'm sure at least some people think C++ is helpful as a hedge against this.

Surely writing to the Windows Platform API is where the lock-in is, not the choice of language?

¯\_(ツ)_/¯

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.

Runtime heap usage.

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.

Performance should be a pretty big concern for UI frameworks. Would be interesting to see some benchmarks.

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.

I am just happy one person liked it. :)

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.

did you fork the cli too? or it's the same CLI for the 3 platforms?

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.

[0] https://github.com/ptmt/react-native-desktop

The react-native-desktop author is working on it [1].

[1] https://github.com/ptmt/react-native-desktop/issues/59

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.

> This is a huge game changer.

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.

Who would have thought 2 years ago?

We're working a React Native port for Ubuntu (via Qt/QML). It's still early days, but many things are working.

Source is here; https://code.launchpad.net/reactnative-ubuntu

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.

Also see: https://ericroz.wordpress.com/2016/04/11/f8-app-on-windows-1...

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

This is huge! Fantastic work everyone.

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.

Now I'm excited to try this project out!

For those interested, the GitHub repo is here: https://github.com/ReactWindows/react-native

How many organizations does Microsoft have on GitHub, I wonder?

Seems like every project they publish is under a different account.

They built a meta-tracking site at http://microsoft.github.io/ and it has a list of Other GitHub orgs at the bottom of that page as well as the repository README. Currently missing ReactWindows, but it's just a PR away to fix: https://github.com/Microsoft/microsoft.github.io

This was somewhat expected after Microsoft released a first-party React Native plugin for their Visual Studio Code IDE a couple weeks ago:

https://github.com/Microsoft/vscode-react-native

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?)

Cordova, Xamarin and React Native...oh my! Which one are you all going to choose?

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.

Haxe + for example OpenFL has even more targets, but not as popular.

Xamarin does OSX apps as well, Not sure about Linux

Xamarin is Monodevelop (plus some mobile and Mac stuff). Apparently monodevelop can be used to build apps for Linux using GTK#

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

tl;dr: Lots of options! Yay!

Wait, so will the "jsx" files be HTML or XAML? If written in JS, where does C# come in?

https://github.com/ReactWindows/react-native/blob/ReactWindo...

Looks like it evaluates the JS and creates XAML elements programmatically using C#.

Only works with Visual Studio 2015 Enterprise?

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.

So, I can build the repo with community? Because I found this statement "Assuming you have Visual Studio 2015 Enterprise installed" at https://github.com/ReactWindows/react-native/tree/ReactWindo...

Fixed: https://github.com/ReactWindows/react-native/issues/345

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.

Reply on news.ycombinator.com