
React Native for Windows and Mac - ed
https://microsoft.github.io/react-native-windows/
======
wyc
React Native scares me with its dependency webs:

[http://npm.anvaka.com/#/view/2d/react-
native](http://npm.anvaka.com/#/view/2d/react-native)

From my experience, it's really great to work with and definitely saves a ton
of work, but the depgraph above fills me with doubt for use in sensitive
applications such as in finance or healthcare. For this reason, I've been
trying out Flutter or even considering to go back to native apps. Perhaps
there's some kind of middle ground where we can create a tight microkernel-
like thing natively using secure enclaves and key managers, but expose an API
to the "untrusted" parts of the program. This approach is not without its own
downsides, such as dark patterns in a compromised UI. However, as one friend
pointed out, a lot of those deps are indeed for build time only, which have
different risk profiles.

The depgraph of reactjs is far simpler and easier for me to understand and
therefore feel trust:

[http://npm.anvaka.com/#/view/2d/react](http://npm.anvaka.com/#/view/2d/react)

Does anyone know if there has been reliable research towards the security of
the entire RN dependency tree? Seeing a stray dep there that has 1 maintainer
on npm/GitHub who has been inactive for over a year makes me nervous. Any one
of those JavaScript projects could do something nefarious deep under the hood,
and this to me seems to expose a huge surface area for attackers.

Here's a classic throwback to keep us on our toes :)

[https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html](https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html)

~~~
AaronFriel
Speaking of trusting trust, I think I'd love for Node¹ to support something
like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into
a particular package certain capabilities are disabled. I would like to be
able to assert that when I import some package, it and all of the packages it
recursively includes do not perform network requests, do not use the
filesystem outside of some folder, and so on.

A fine grained capability system for packages would dramatically improve the
safety profile, and if this were built into package.json and the lockfile we
could do the following:

1\. Packages advertise what their default capabilities should be limited to
2\. Changes in those capabilities are encoded in the package lock file, and
can't be changed without the user explicitly affirming them

¹ and other langs with extensive use of package managers and micro-packages

~~~
pier25
> A fine grained capability system for packages would dramatically improve the
> safety profile

I think Deno does that (the new project by Node's original creator):

[https://blog.logrocket.com/what-is-deno/](https://blog.logrocket.com/what-is-
deno/)

~~~
jakear
Deno gives all packages the same permissions of the main app. So if your app
can make network requests, so can every dependency you use. It’s not a great
situation. I’ve brought this up to them and their response is that per-package
permissions would be too difficult to implement.

~~~
vijaybritto
Yes, checking everyone at the main door is indeed easier than checking
everyone at every single point of contact. It needs a vast architectural
change compared to current implementation as you need to enforce those rules
at runtime!

~~~
jakear
Well yeah, but I thought the whole point of deno was to make vast
architectural changes to allow for increased security. Seems odd to stop half
way.

------
satvikpendem
I tried using this a few months ago, as well as React Native for mobile and
React Native Web for web, and I felt like they were all just hacks glued
together to get cross-platform support, and RN isn't even native, it still
includes a Javascript bridge. Build dependencies and packages were a
nightmare, things continuously broke. I tried Flutter afterwards and it just
felt like a breath of fresh air. Everything "just worked", on all the
platforms I tested it on: web, iOS, Android, Windows, Mac, and Linux. Updates
on one are hot reloaded to another. In contrast, Expo sometimes just broke.
This was all wrapped up in one package instead of needing to use separate
build chains for each platform.

I wonder if React Native can do all of this officially, but I suppose that's
not their prerogative, given that RN is mostly used by Facebook for apps and
these other platform efforts are by third parties, like Microsoft here.

~~~
diegof79
I had the same experience.

Expo is wonderful for prototyping and quick iteration. The ability to use
Snacks online and see them working on the phone is great.

But beyond that everything in RN feels hacky and unfinished. While working
with it I had some silly issues with Metro, and found some subtle bugs in Text
and Button components.

About the "Native" part. I think that a lot of people have the expectation
that doing RN apps will be the same as building a iOS or Android native app.
But RN+Expo is not that different from frameworks like Ionic. Is really hard
to do an app that follows the Apple HIG or Material Guidelines, you end with
something in the middle that doesn't look or feels truly native (at least not
without tons of extra work to imitate things that you get for free in the
native UI kit) .

RN without Expo is not so nice, lots of rough edges and sooner or later you'll
need to write interop code in Objective-C or Android Java to take advantage of
the native platform.

~~~
WrtCdEvrydy
Expo has one small issue... if you are in an organization that isn't capable
of keeping it up to date and it becomes deprecated, your app will stop
working.

If this happens over a weekend, expect your phone to blow up every three hours
until it gets republished and fixed.

~~~
behindsight
Unless you are referring to another issue, using `expo build:android` will
create an apk file so you don't have to rely on staying up to date with the
Expo app.

~~~
WrtCdEvrydy
Yeah, but if you are using their native extensions and they deprecate your
version, their repo will become unavailable and your app will fail to start.

------
dep_b
Those JavaScript cross-platform solutions are opaque boxes that run basically
their own operating system within an operating system. This comes at a penalty
of a non-standard UX and higher than usual CPU usage and memory usage. But
after they tackled that hurdle (like Visual Studio Code, excellent work), they
still lack a lot of platform standard goodies like Accessibility and
AppleScript.

I prefer solutions like Xamarin / Mono where you can have a Cocoa UI coupled
with C# or F# based dll's. Let's be honest, as long as you have a good way of
maintaining a good state in your app for example by already using ViewModels
that did most of the heavy lifting like formatting strings, having the state
in a state machine and so on, getting the UI to work as required is just an
exercise of filling in the colors between the lines.

Barely anyone would notice they were using a Xamarin based solution on a Mac,
while the JS based applications are immediately really obvious to the trained
eye.

~~~
techntoke
It's almost like people want a new markup language for defining interfaces
that isn't based on JavaScript.

------
rafamvc
Flutter seems to be gaining ground on React Native. And they also have web and
desktop ports. Recently flutter overtook react native on Google trends.

~~~
owenversteeg
Flutter on the web is absolutely insane. For those who don't know, it
basically strips away everything and wraps it in a big terrifyingly complex
mess of code and renders everything in a canvas. Flutter advocates like to
claim that that's "only a fallback" for when things get complex but as far as
I can tell the vast majority of things (including the simplest examples from
Flutter itself) force the entire thing into canvas: it's basically Flash 2.0,
but worse.

I seriously hope that Flutter fades. It's very dangerous in many ways. Even
ignoring the huge downsides of basically having a new Flash, consider this:
the massive Flutter layer is, surprise surprise, yet another Google project
that is magically _significantly_ slower in Firefox. I don't mean a small
difference here, I mean that on a brand new fancy flagship I tested on,
Flutter in Chrome is buttery smooth and Flutter in Firefox is a miserable,
laggy experience. If it gets popular, this will become yet another reason
pushing people off Firefox and cementing Google's dominance of the web.

Flutter is a very, very dangerous thing.

~~~
snodnipper
Adobe Flex was my most productive client development experience over the past
20 years. I transitioned to Android _but_ there were many hideous things with
that (e.g. ghastly emulator, legacy Java support etc.).

My personal hope is that Flutter gains traction and the web can move beyond
current web/native technology. Postscript / PDFs aren't suitable for game
experiences...and to my mind web standards have been shoehorned into
supporting web apps, where there is a mismatch with native technologies. I'd
like to think that Flutter can help bridge that gap.

This is not to say that accessibility etc. should be ignored...nor better
support in Firefox...but even Brendan Eich is using Blink/V8 with Brave.

Anyhow, thoughts of one.

~~~
nojvek
Ahhhh Adobe Flex with MXML and ActionScript3. Before Typescript and React with
JSX got popular that was the cool kids club. RIAs yo! Rich internet
applications.

I loved what Flex brought to the table. Too bad Adobe didn’t open source flash
and let it die.

~~~
KuhlMensch
It lives on in web APIs

------
qppo
I'd love to abandon my C/C++ UI frameworks for React, but I need

\- consistent rendering/support across multiple platforms and versions

\- multiple windows

\- rendering to a window that isn't owned by the UI being rendered or created
by the framework

Can I do that all in React native? Edit: don't need to bring up electron.

~~~
metalliqaz
what the heck is that third one about?

~~~
qppo
I work with applications that generate windows and manage their lifetimes
independently of whatever is inside the window. afaict, most web/mobile UI
frameworks assume they're the only thing in the universe, whereas on desktop
there's a complex application managing zero or more rendering surfaces and
portions of the code only know about the one that they're supposed to target.

It's a hairier problem than you'd expect it to be. I'm not an expert but my
understanding is that it's tricky to deal with the event loops when you're not
the master of your domain, at least in a platform agnostic way. The workaround
is usually to spawn multiple processes, but then the management of app state
has to have an IPC layer underneath the internal APIs and there needs to be a
master daemon running somewhere.

In keeping with front page posts, the plugin API for Apple's Logic Pro (audio
units) is an example of that. You are handed an NSView* and need to render on
it, but you don't create it.

------
ed
MacOS implementation here [https://github.com/microsoft/react-native-
macos](https://github.com/microsoft/react-native-macos)

------
szhu
I think the killer feature here is natively targeting Windows AND macOS
simultaneously.

The only cross-platform alternatives that I've seen in the ecosystem use
either web or Gtk in the frontend, and both of these have a distinctly non-
native feel to them.

~~~
int_19h
In which ecosystem? If you mean desktop apps in general, then there are many
other options. Qt and wxWidgets, to name a couple of popular ones that have
been around for a very long time.

~~~
ComputerGuru
My problem with those two is the damn C++ API. I’ve used both in the past, but
I’ve moved on from C++ for desktop applications to greener pastures but these
toolkits’ APIs are a pita to use via ffi.

~~~
int_19h
They're both pretty popular to wrap; I'm surprised that whatever
language/ecosystem you're using doesn't have a wrapper lib already.

------
Etheryte
While personally I dislike React Native in the strongest terms possible for
the number of nigh impossible to debug technical issues it has brought the
projects that tried to tame it, there is a really interesting moment happening
here. Microsoft is embracing Facebook's cross-platform tools to eventually
compete with Google's cross-platform Electron. Microsoft currently relies on
Google for the internals of VS Code, Github for Desktop and many more of its
popular pieces of kit, and it doesn't seem very happy about it.

My own experience with React Native has been nothing but terrible, but it will
be interesting to see how all of this will play out in the long run.

~~~
nailer
V8, Chromium and Blink are an Open Source projects that Google is one of the
main contributors to, but they're not 'Google'.

If Google went away tomorrow, V8, Chromium and Blink would still exist, and
Microsoft would be able to use all projects.

~~~
biggestdecision
Sure they are open source projects, but the majority of dev work is done on
Google's dime. Google employs many of the most important people in these
projects. Sure the code will still be there if Google gives up, but will
anyone have the capacity to step up and maintain them?

~~~
nailer
Yes. Microsoft would hire them, and already is doing do.

There's plenty of commits to V8 from outside Google. Blink is a fork of a fork
of a twenty year old project.

------
brdd
I'm really excited, although the Mac part of this page is somewhat misleading
— there isn't anything available on the Mac side yet (everything is "coming
soon")

~~~
manquer
you can checkout the code here [https://github.com/microsoft/react-native-
macos](https://github.com/microsoft/react-native-macos). It still being
actively developed and not yet ready for release.

------
parshua
I wish someone would take a web renderer, took the Javascript away, made a
native react-like library for it, and made a universal interface to it so any
language could use it. That would finally fix the problem with the UI building
issue, while allowing flexible language access. That would be the best of both
worlds.

~~~
tsukurimashou
sounds a lot like what wasm is trying to achieve (minus the web rendering
part)

------
ARandomerDude
> Windows

> We are actively developing React Native for Windows...

> Mac

> Coming soon

So React Native for Windows.

~~~
olyjohn
Don't forget... Microsoft <3 Linux. You can tell it's a top consideration.

~~~
snazz
They don't <3 _desktop_ Linux and probably never will. To them, Windows and
macOS are the major desktop operating systems, and Linux is the server
operating system. VS Code likely only runs on Linux because Electron runs on
Linux.

------
tphan
I've used React Native for a client and, whilst it was super clunky, I still
enjoyed being able to write React to deploy to mobile. With React Native for
Web, you can technical write code that writes to a bunch of different
platforms, a big selling point for businesses.

~~~
yesimahuman
Check out Ionic which now fully supports React and will give you a similar
benefit but without the need to use RNW or have different code for each
platform. Also Ionic’s components are much more robust and widely used than
RNW.

~~~
crazypython
I agree that Ionic's components are easier to work with and less of a hassle.
However, React Native components let you talk directly to native, even using
native components from the native platform's ecosystem in your code. It's a
tradeoff developers have to make.

[https://github.com/wix/react-native-navigation](https://github.com/wix/react-
native-navigation) is beautiful, it uses iOS' own navigation APIs, but it's a
pain.

~~~
yesimahuman
That’s fair! One other option is to do both: use Capacitor and embed it inside
native navigation controls (i.e. a native shell), then use Ionic React for
screens, etc.

One other aspect is that Ionic React uses react-dom so it will be a pretty
normal react dev experience compared to RN which isn’t 1-1 (CSS being an
example).

------
iainmerrick
I asked this on a previous React Native thread, and I’m still curious: is RN
(on mobile, as that’s where it’s currently used) _actually_ faster than
something like PhoneGap? Are there any benchmarks or demos? Anyone got any
anecdotes of a like-for-like comparison?

I’m skeptical (though certainly willing to be convinced) because RN runs your
JS application in a separate thread from the UI, with a rather expensive
bridge sending JSON messages back and forth. That seems to me a poor design
choice.

Browsers have the downside of working with the complex DOM that doesn’t map as
well to native widgets. But browsers are mature and highly optimized. So I
would guess that performance might be a wash.

~~~
firloop
Performance is just one reason companies adapt something like React Native,
the ability to have web developers* come in and string native-quality
components together is another. React Native can feel better than mobile web
and have access to lower level APIs.

* I think this is more of a selling point than a reality. I think in practice, to make a React Native feel and work well requires native platform knowledge.

------
willswire
Not sure what the advantage here is over Electron. I know the chromium engine
is a resource hog, but the scalability/mix between platforms makes it worth
it. Curious to know what your thoughts are folks!

~~~
comex
> I know the chromium engine is a resource hog, but the scalability/mix
> between platforms makes it worth it.

Worth it for some. Personally, I refuse to use any Electron apps because they
have a highly non-native-feeling UX and because they're resource hogs.

This announcement excites me, because React Native is likely to be an
improvement on both counts.

The UX still won't be quite as native-feeling as a single-platform app
designed for that platform's unique idioms – but as long as it uses native
controls under the hood, that's still 10x better than Electron in my book.

And even without the bloat of Chromium, an app written in JS is still likely
to be slower than one written in, say, C++ or Rust – but most GUIs don't
really need that level of performance. And at least on macOS, the competition
is not C++ or Rust but Objective-C and Swift, which are both slower, more on
par with JS in terms of performance.

~~~
antigirl
VScode looks and feels native and not memory intensive

~~~
zapzupnz
It might feel native on platforms where 'native' doesn't mean anything
(Windows, Linux), but the only native thing about it on macOS is the fact it
has proper global menu bars — which is something provided by Electron for
free.

Everything else is custom.

------
zapzupnz
I'd love to see some dog-fooding on this. Maybe a branch of VS Code for RN.

I mean, say what you will about the quality of even Apple's own Catalyst apps,
but at least they eat their own dogfood (although with the unfortunate
consequence of making us eat it, too).

There are so many different competing projects at MS to do practically the
same thing, it'd be great to see RN for Windows and macOS used for something
major from MS.

~~~
sophiebits
Last I heard, they are using it for at least significant parts of Office and
Skype.

------
freewizard
There was a community effort[1] with similar goal on macOS. I was a tiny bit
disappointed that they stopped working on it when Apple announced Project
Catalyst. It's good to have MS carrying the touch on this topic.

[1] [https://github.com/ptmt/react-native-
macos](https://github.com/ptmt/react-native-macos)

------
SZJX
Looked at it a while ago when I was trying to start a cross-platform app (both
on mobile and on desktop), but under the Mac section it simply said "Coming
Soon!". I thought there's some update with this post receiving so many
upvotes, but apparently it's still the same, and Mac support is still in a
very early experimental stage.

Flutter left me a similar impression.

I eventually ended up using Quasar [https://quasar.dev/](https://quasar.dev/),
which allows you to use one Vue.js codebase but deploy to Cordova on mobile
and Electron on desktop. Vue is definitely not the prettiest solution out
there, but I had to be practical and actually get the app out.

Maybe if I started the project one year in the future, the landscape would be
totally different already. It's definitely changing rapidly.

~~~
chimp_brain
I think I might be on the same boat. I have personally looked into all
frameworks and planning to hire a team, quasar seems is one of the options.
The application isn't for any mission-critical application, revolves around
curd. Quasar is a good option albeit with a lot of baggage, Flutter is clean
but for Desktop use case it's still evolving. How was your experience with
Quasar? Would you recommend Flutter over Quasar?

------
FpUser
They supply short Counter example and claim they're both the same. However
looking at the code button handler called onClick for react and onPress in
React Native. Unless this is a simple typo why doing crazy things like that?

------
Bellamy
React Native is getting better all the time and it's mature already. I think
people who criticize RN are the devs who had to work with the first few shitty
versions of RN in a shitty complex project. I think that's the case in many,
if not all, open source projects.

We do pretty complex stuff with RN as does Facebook and it's been serving us
well. I don't know why someone would want to use it with Windows, but this
tells how far the project has gotten.

I would love to developed native, but you just save a lot (maybe half) time
using RN if you need the app for both platforms.

------
EastSmith
I looked at the docs, and checked the Calculator demo app. It a Visual Studio
solution. I will not install Visual Studio because each time I install it
(last time it was 5 years back now), my Windows Installation gets polluted
with all kinds of packages that I now never ever been able to figure out how
to uninstall.

I can copy couple of dlls in a project folder, and run npm / yarn install, but
that is the most I am willing to do.

So, my question is: is there a VS Code / npm only demo?

As an ex-windows developer, turned react dev - I am excited.

------
chadlavi
I swear to gosh Facebook, if you tempt my employer into making me write
Windows apps...

~~~
hpen
I would be happy to add Windows as a platform to my apps. More market == more
money. Only as an add-on. I wouldn't want to write Windows exclusive apps for
sure.

~~~
eyelidlessness
Not meant to disparage, but how lucrative is that market? How much do Windows
users (outside of business) actually spend on software (regardless of business
model)? It's a leading question, but a sincere one.

~~~
Spivak
Who buys software outside of businesses? God I feel like I haven’t paid for a
stand-alone piece of software in years.

~~~
eyelidlessness
I do. Not a ton, but enough to be a part of the drop in the bucket that makes
the Apple ecosystem more attractive to smaller-purchase businesses that target
it. I just... haven't seen much of that targeting Windows for a long time.

------
ipsum2
On the React Native MacOS fork:

> This repository is a working fork of facebook/react-native that adds support
> for the official React Native for macOS implementation from Microsoft.

Does anyone know when these changes are planning to be upstreamed?

~~~
eyelidlessness
RN's been available for many years, and little interest has been shown in
providing first class support for desktop targets. That said, it wouldn't
surprise me if:

1\. the recent FB messenger desktop apps are RN.

2\. they leverage work done in forks (like this one from MS) to achieve that.

------
ShaneMcGowan
React Native for Xbox seems like a step in the complete wrong direction...

~~~
cbhl
Glad to see I wasn't the only one confused by the Xbox and game controller in
the header.

(I mean, sure, it "just" runs Windows, but...)

------
OzzyB
> React Native for Windows and Mac

> Mac: Coming Soon

You know what, I think I'll wait for Flutter Desktop, or see who wins true
cross-desktop compatibilty since Flutter already has Mac support but no
Windows.

------
langitbiru
A decade ago, Java was the de-facto language to build a cross-platform desktop
application (with Java Swing). Now it is JavaScript. So be it then....

Too bad Rust does not have something similar.

------
pier25
Didn't Microsoft use RN for building Skype or did I dream that?

~~~
saagarjha
Skype is Electron now.

~~~
contextfree
The previous version of Skype was based on an older, internal-only fork of RN
for Windows.

------
yoloClin
Is anyone able to provide a map of modern frameworks? With React-native,
React-redux, Angular, Vue and probably a bunch of others.

I'm really not sure what's relevant now and what was relevant 6 months ago.
I'm genuinely curious, but it's pretty difficult to grasp and no framework
homepage is going to tell you "Don't use me, I'm about to be a dead project!"
and every developer will tell you their preferred framework is the best
framework.

~~~
yodon
"I can't figure out what will be relevant in six months" might have been a
legitimate complaint a decade ago, but those days are long gone.

React has been a core part of the front end ecosystem for almost 10 years.
Angular is more than 10 years old. Vue is the "new kid" on the block at about
six years old.

React is roughly 10x more popular than Vue or Angular according to npm usage,
has been far more popular in usage terms for many years, and continues to be
growing faster than either Vue or Angular.

Complaining you can't figure out if React or Angular or Vue will be relevant
in six months is a bit like complaining you can't figure out if C++ or Java
will be relevant in six months. Yes, there is lots of advancement happening in
the front end space. Yes, that's a good thing. No, it's not an excuse to act
like you're paralyzed to understand the current state.

~~~
NocturnalWaffle
React, almost 10 years? It was only open sourced 7 years ago and definitely
took time to fully catch on..

~~~
yodon
I'm truly amazed to still encounter "omg React is so new and unproven how can
we possibly keep up with stuff like this?" posts. Next up: is no-sql just
another fad or will it catch on?

~~~
fenwick67
Who said that in this thread? (Nobody, they just pointed out you are wrong
about the timeframe)

------
shmerl
No Linux support.

~~~
justinmcp
You could try moving [https://github.com/justinmcp/react-
native/tree/ubuntu](https://github.com/justinmcp/react-native/tree/ubuntu)
forward. I no longer have the time.

------
billions
React Native seems to be quickly becoming the standard for fast development
coupled with native integration

~~~
deadmutex
Does Facebook use it?

~~~
outside1234
Yes

~~~
msrmthehomeless
Only for its marketplace app

~~~
sophiebits
This isn’t true.

------
jonbronson
Unfortunately, `Good First Issue` and `help wanted` sections are currently
empty for the macOS fork.

------
igravious
Excuse my ignorance. What's new about this? I thought React Native was already
a thing?

~~~
filoleg
React Native was a thing for native mobile app development. The post is
talking about React Native becoming available for native desktop app
development.

~~~
BHSPitMonkey
You mean when this came out 4 years ago? I'm not sure why this is being posted
as "News"...

[1]
[https://news.ycombinator.com/item?id=11386595](https://news.ycombinator.com/item?id=11386595)

[2]
[https://news.ycombinator.com/item?id=11490190](https://news.ycombinator.com/item?id=11490190)

~~~
contextfree
While it's not that new (has been public for over a year), this is a
different, newer implementation of RNW (written in C++ instead of C#)

------
djabatt
The web site reads "Mac coming soon" the headline reads differently.

------
jbverschoor
Only a matter of months before VSCode will not be an electron app anymore.

------
unnouinceput
. (dot) (ignore me, I need this comment to comeback to it in the future)

------
AbuAssar
The mac related lib and docs are still ComingSoonTM

------
m_mueller
Why is Microsoft doing this instead of Facebook?

------
markharper
What would be the benefit over electron?

~~~
hpen
1\. Not using the DOM for rendering. 2\. Integrating native APIs is much
easier.

~~~
wtetzner
> Being compiled to native code is a huge benefit.

It's still just running Javascript. The real difference is that it uses
widgets that are native to the platform, instead of a browser engine/DOM.

~~~
eyelidlessness
It's not "just" running JS, it's _also_ running JS. Part of the control flow
into and out of the native widgets is JS, and part of it is abstractions over
scripting bridges employed by RN (and its various forks).

------
mister_hn
Where's the Linux one?

------
albertTJames
Today an Electron wept

------
jasonhansel
Of course, no Linux support, since this is still Microsoft :(

~~~
johnghanks
Classic HN - never anything positive to say about any story here.

------
natch
React Native is best understood as an insurgent attack on native mobile
platforms, funded by overwealthy and bloated companies that do not control
mobile platforms, but feel entitled.

Microsoft and Facebook attacking Apple and Google basically.

IMHO it's not a sincere effort to make a nice platform. It moves fast and
breaks things in major ways with each minor point release, with the current
excuse being that it's not at 1.0 yet. But it offers just enough to introduce
FUD into the competitors' ecosystems. And that's the entire goal as far as I
can tell.

If you value getting useful deep knowledge, stay away. If you want to play in
the shallows and be patching stuff up all the time with JavaScript/TypeScript,
React Native is an option.

~~~
rosywoozlechan
How are Facebook and Microsoft any more or less "bloated" than Google or
Apple?

Also Discord's iOS app is built with ReactNative, and it is a pretty feature
rich application, seems like it works for those use it.

~~~
natch
They have lots of money but without carrying the cost of maintaining an active
hardware product line. Unless you count Oculus for Facebook and a few minor
things for Microsoft but those are in the noise.

