The biggest problem I've run into with React Native has been their handling of issues. Far too frequently I'll google an issue I'm having and click a link to a bug report that matches the exact problem I'm having and provides a repro only to see that the issue was closed for inactivity. Never mind the issue is still valid, and the comments on the issue will ask for it to be re-opened and the response is to open a new issue.
So then you start this goose chase of hunting down the current issue since it starts getting into this loop of closed, open a new issue, closed, open a new issue, closed, open a new issue, etc. And everytime this happens relevant information gets lots because its not transferred to the new issue.
And then you finally find the newest, currently active iteration of the issue and find out that its still not fixed and the workaround is to stop using the React Native version and re-implement the feature yourself natively on both ios and android.
I remember asking about this on Reddit and got a response from someone on the RN team.[1]
> In practice this means that we have issues coming in, but we never close them when they are fixed, causing them to pile up. So we decided that the best thing we could do is mark them as stale and close old issues that nobody has commented on in a while. If we mistakenly closed something that is still an issue, the community will let us know and we can reopen it.
The discussion I had with them was interesting, but it didn't leave me feeling like anything would really change. Seeing your comment reminded me of this and I guess the status quo has remained.
I can't seem to understand what the problem with "pile up" is? The whole idea of logging issues is to see how long they're open for! In fact good projects take the painstaking exercise to coalesce tickets that are in fact the same with an original item IN ORDER TO track the correct age of the ticket.
Nope, wrong on all counts. You need to delete stale issues, it's no good having an endless backlog of someone's nice-to-haves that they no longer even care about.
And, the "whole idea" of logging issues is not to see how long they are open for... it's to, you know, log issues, because they can't be fixed instantaneously. Measuring how long they are open for is just a pointy-haired boss side effect, because those are the kind of idiots that would think that kind of metric means anything.
>Measuring how long they are open for is just a pointy-haired boss side effect...kind of metric means anything.
I don't think such cynicism is warranted. Open issue time is a useful metric, at the very least over time, of how
quickly developers are fixing problems and how complex they are becoming.
Certainly not something for a pointy haired boss to optimize exclusively for, but a useful bit of data to be taken into consideration with other measurements of performance.
most of the time the issues are also not fixed (a cross multiple releases)
some of the issues are really basic ones, one can wonder why they made a release with them in the first place.
If you have enough issues, just deduping and knowing when a commit fixes an issue to remember to close it becomes a problem.
Not saying this is an excuse, but it's unfortunate reality that "close most issues, see which ones come back" is one of the easier ways to focus on the most important bugs
Well, unless they have a triage team, you're counting on developers having a Spidey-sense that there's an open issue related to what they're working on. I assume the issue list is something they never asked for but feel obligated to doing a minimal amount to clean up.
This assumes that the person fixing the bug is either the same one who filed the bug, or they were motivated to fix the bug after finding the GitHub issue.
In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
And this is exactly why React Native is such an unprofessional pile of crap. Random code changes from random people with no prioritization, documentation or coherent history.
The response that I've gotten, after complaining repeatedly, is that the team simply has no time to look at any externally reported issues, and that it's essentially a waste of time opening an issue.
This makes me very sad (as an ex-FBer especially), I wish that FB would just add another 3 or 4 engineers to the team with the explicit goal of giving them the bandwidth to be good open source stewards. I'm sure the FB engineers don't like having to ignore the community, but they do as a matter of policy.
They could learn a lot from Microsoft. VS Code, Typescript and related projects are a shining example of how to handle issues on open source projects. In fact, considering what heavy users they are of React Native, maybe Microsoft could be taking a more active role in the core project.
This is a great point. There have been a few issues that I've followed only to find that eventually the entire thread on Github with tons of example cases of the bug gets "closed for inactivity" because nobody from Facebook would respond to it.
They don't need to add more engineers - as an open-source project, all they should have to do is put one person to manage the community, encourage and vet new contributors. But that would mean losing some control.
I've found that to be relevant for a few issues (including one of my own) with Facebook Open Source projects—that or they just go unheeded by staff, but confirmed by a stream of others.
I am a distant outsider to that company, I haven't used the platform in years and remain quite critical of it and many business practices especially regarding recent exposures (though I am a fan of their engineering they've released or open-sourced for the web)— yet I can understand somewhat how staff associated with such projects are not necessarily actively and regularly allocated to addressing those issues. At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company [re: endpoint-shareholders]—mindshare, general confidence, whatever. Big corps often do what big corps do...
>At times they're passion projects that still need to gain traction that entreats the company to something worthwhile to the company
That's not the case with React Native though.
The problem is that the surface area is vast, and the popularity is booming through the roof. If RN team looked at every issue, the (very active) development would stall completely. On the "web" React repo we can afford to do this because our surface area is much smaller, but on RN it's not practical.
So instead, the RN team tends to focus on the issues that are reported most often by the FB product teams. While this is not a great outside communication strategy, it ends up highlighting most pain points shared by folks outside the company too. Note this includes vast architectural improvements as highlighted in the post--something that goes way beyond a traditional GitHub issue report.
While admittedly this approach puts FB's needs first, it also serves as an important way to keep the team focused. It is very hard to deal with dozen new issues every day and still move the project forward so they chose this path.
I want to highlight that RN has maintainers outside of FB who help with different parts of the codebase (because again, the surface area is vast), sometimes with more expertise in those areas than people at FB. So the project isn't dependent on FB maintainers looking at issues alone. Folks outside can, and do help.
This doesn't mean issues don't end up being addressed in the end. But GH issue communication model just doesn't scale well for RN.
Why should Facebook pay for that? If there are issues that are extremely costly to a bunch of outside teams maybe they should be the ones hiring people to fix their problems.
Because the overall health of the open source ecosystem around React and React Native depends upon the cost of development being somewhat predictable.
Most of the bugs in this category are inefficient for most teams to tackle because they get below the surface of the APIs and tooling. Not only is there (by design) no contract for how these things should work, but the appeal of React and React Native is that the developers and teams using them can be selectively ignorant about these things.
In life one must choose which things to devote energy into becoming expert in. These kinds of bugs tend to be show stoppers for teams impacted by them. It's a coincidence that Facebook itself has not been impacted, but someone needs to adopt a higher level view to realize these are very important issues which the maintainer should be addressing as top priority.
Facebook is a many billion dollar company and can surely afford to put a few more top engineers on the team to do this stuff. These things create major credibility issues for React Native supporters in their own orgs.
If Facebook decides to upgrade to a newer Babel library (for instance) and it creates a major issue with an open source library that is used by 30% of React Native projects, this warrants direct attention by Facebook.
If a RN update causes thousands of teams using RN to get failed builds, there should be someone at Facebook trying hard to reproduce the problem even if there is no obvious theoretical reason why it should have occurred and it is not impacting Facebook's builds.
React Native is a great project, but this stuff causes a tremendous amount of thrash and wasted time for the teams impacted. It could be much more efficiently dealt with by Facebook directly (and should be).
It looks like Microsoft is pursuing React Native as an alternative to Google's Flutter.
It may be strategic for them to take that role and hire folks to work on React Native, either a MS fork, or as part of a conjoined effort with Facebook.
FWIW I think you guys should put out a major call for help to other companies and add more non-FB people to the core committers.
React Native is fantastic, but the ecosystem is thrashed around horribly by these kinds of bugs and the non response from Facebook for things that impact most of the non-Facebook open source ecosystem around React Native.
Been actively wondering if there would be enough interest/momentum for a community LTS fork.
Love RN, and the daunting vastness of the surface area not lost on me, but would be totally ok with me if development stalled for 6 months of purely bug-fix releases. Maybe I'd sound differently if I cared about integration with native apps.
Can't understand how any internal team at Facebook tolerates the sloppy coding practices of the RN team. Is everything just technical debt to be ignored and left behind so the team can work on the latest shiniest feature?
I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository.
To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue.
If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com.
At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past.
We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons.
But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion").
Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized.
Well, I see there's at least been some action on the TextInput regressions that were keeping us on fork! <3
Not that running a patched version is necessarily a huge deal, but it's nice to have that 'this random code is approved by someone that actively works on the codebase' stamp.
(well, still might be on 0.55.3 for the version if NetInfo we can work around, but I do appreciate the project, warts and all)
There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...
I've had the same experience in multiple open source projects. Seems like not spending though resources on unsexy things, like QA, is typical for open source – although I'd rather expect it from volunteers than FB's engineering team.
Lots of negative or neutral posts in here, so let me chime in: I love React Native.
It’s not perfect, but it’s very damn good. One of the most impressive pieces of software I’ve encountered in 9+ years of mobile and full stack development.
I do all my projects in RN now, and I believe it gives me a 2-3x iteration speed advantage over my competitors with indistinguishable-from-native interactions (using react-native-navigation) and the ability to be on all platforms. For a solo dev, these advantages are insanely powerful and are the major reasons that my business is viable.
At 5k+ DAU I believe it is the largest production game written in RN.
There are more apps but I’m on mobile and it’s too hard to link them.
Major kudos to the RN team for all their hard work. RN makes me feel very dangerous as a solo developer and honestly makes mobile development more fun than I have ever imagined (especially paired with TypeScript). Thank you!
I tried your game on my Pixel 2, and aside from the performance issues already mentioned by other posters, there are very clear 1px misalignments (buttons borders, screen edges) that make it fairly clear (imo) the app is not native.
I don't have a lot of Android devices to test with, though it looks perfect on the ones I have. I would love to see screenshots of the imperfections you're talking about, it would be a huge help! If you see this, please send them to rawrmaan [at] gmail [dot] com. Thank you!
I will say that Android performance, especially in recent RN releases, has been one of my biggest issues with RN.
Everything about the game is highly optimized and performs beautifully (60fps) on all 2013+ iOS devices, but inexplicably performs very poorly on even some very new Android devices. I think it has to do with problems with the Android driver for Native Animated.
I've really enjoyed react native, and I dread doing application development work outside of it now. Many of the complaints in this thread are totally justified and reasonable complaints, but even with those issues I find RN to be the best platform to develop cross platform applications.
You've developed a fun little game but on Android it really feels 'out of place'.
The UI elements seem to be from iOS and performance is surprisingly poor for such a graphically undemanding game
I addressed the performance in another reply, but I would agree that it is surprising. And yeah, the UI is mostly iOS-inspired. Looking to bring it to more of a happy medium over time.
I haven't installed it, but I note that there's no explanation of what a "Picross / Nonogram" is on the google play page. So if I stumbled across this game I wouldn't have any incentive to try it out.
Given your background, maybe you or someone else here could help me. I am about to start a new mobile project, and I have yet to decide whether to use RN or Ionic.
My project will be nothing very fancy: mainly "forms" and use the camera and audio recording. But at some point in the future I would like to use hardware features more heavily (real time audio processing, GPS among others). Would you think RN would be a good fit for this? Have you had experience with Ionic? If yes, how do you think both of this compare?
I know that Ionic is not native, but I am more looking to understand how many headeches will I get to use the phone hardware on each of these two platforms.
I can’t comment on Ionic, but for the features you’re talking about, RN is definitely suitable. The RN ecosystem of native modules is certainly massive. Off the top of my head:
I'm curious, you use react-native-navigation. Did you ever try react-navigation? That's what we are currently using. Don't have any strong complaints, but know it does everything in JS. Was wondering if maybe you tried both and have any comments.
I haven’t tried a recent enough version of react-navigation to comment, but the older version was so bad in terms of complexity, missing basic features and inconsistent paradigms that I am permanently taste averted to ever installing the npm package again.
react-native-navigation appears to me to be the best available option. The main downside is that it kind of “takes over” your app in terms of the native bootstrapping process on either platform, which can make integrating other native modules slightly more challenging.
1) It runs very well without a network connection, you just can't access the online features. I've written my own syncing logic to make sure a user can experience the game for days or even months without having a network connection, and then have all their progress saved when they connect.
2) It works very well on low bandwidth connections. The puzzles are represented as strings and there are no remote images loaded.
3) For features that make sense in this game (sharing, IAP, haptics, notifications), it supports native functionality flawlessly. It is very easy to write native modules for RN, and there are may great npm packages that implement commonly needed native functionality.
I write native modules for a React app, and it's not easy at all. React on iOS is an unprofessional abomination, a mass of compiler and console warnings that make it almost impossible to determine what your own code is doing.
I’ll just have to disagree. There’s a bit of a learning curve, and yes the React project is full of warnings, but Xcode has filters for that, and breakpoints work brilliantly. I guess I have a big advantage in having 6+ years of native iOS dev experience.
Yea, I only have 7 years native experience, which tells me Xcode filters don’t work worth a crap at separating out our warnings from RNs warnings, and that warnings are still a clear sign of amateurish coding practices, and burying the console in gibberish is, like the warnings, a recipe for obfuscating serious issues.
There sure are some things to fix (Tutorial label placement on iPhone X, some buttons look blurry) and some behaviour that is not native (like the transition between screens), could be implemented but gives a clue that it might not be a native app.
Thanks for the kind words! Yup, fixed the tutorial button for the next release, and I should add @3x assets--I have poor vision so I forget about stuff like that.
On iPhone X, the placement of the tutorial button in the notch gives a non-native feeling. But a lot of existing native apps are also guilty of this. Otherwise, kudos, it is indistinguishable
Thank you! This is actually my fault and is fixed in my upcoming release. All of the other views are iPhone X optimized, which is quite easy to do in RN.
My largest issue with RN is that despite being "cross platform" there are numerous times it is not, and the documentation may or may not reflect this. From the image cache policy for remote objects not being obeyed on Android, resulting in all images being cached all the time (open for multiple years, never even acknowledged), to basic features like tiling an image just now coming to Android. Heck even making something as simple as the keyboard not occlude the field being typed into is not cross platform, with the docs just saying that some props may work better than others on android versus iOS.
That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
React Native is partially magic, and JSX is really nice to work with. But the complicated things take minutes[0], and the simplest things take hours[1].
All that said, I'm still thankful to Facebook for putting out this project. Even if it does behave... weird at times.
[0] Networking? Stupid easy. Even if my linter is unhappy about 'fetch' not being declared anywhere. Great libraries mean things that are normally a nightmare, like, authentication become really easy. And the community has a to of tutorials.
[1] Want to make an image responsive? Or just learn how to render an image properly at all? It is the opposite of intuitive. Also React-Navigation is bad-but-getting-better to work with.
re: react-navigation, I am one of the two primary maintainers of this project and I started working on it in January of this year because it was in a pretty rough state. I think it has come a long way in that time even though there is still plenty to do. I would love to hear what simple things have taken hours for you when using it, feel free to reach out on Twitter in DM @notbrent or email brent at expo dot io. Also, the roadmap for our next major version is here: https://github.com/react-navigation/react-navigation/issues/....
Short summary is, well, the drawer is all sorts of weird. How the drawer interacts with everything else is also kind of weird. How to open a drawer with a NavigatorService is not something I could find documented outside of Github, and the comment there was old and what was suggested didn't work.
I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.
Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.
When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.
(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)
So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.
I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)
> That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.
That just sounds like a poor understanding of dependency management.
Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.
> That just sounds like a poor understanding of dependency management.
And yet a lot of tools and large packages will spit out an error telling the user to run NPM update. As someone who is new-ish to JS, I generally try and follow the recommendations of those who are supposed to know better.
> The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).
I previously did C++. Breaking changes were few and far in-between. It helps when the library is only updated once every few years. :-D
Now days? Things that break in my environment:
1. Android Studio, I have never not had 2-3 hours of down time after an upgrade. Mostly involving...
The Android Emulator. After updates, it just doesn't start. This leads me to: The images on the Android Emulator. I finally have found one that works reliably, I am sticking with it.
Finally, Expo. It is just odd in places.
That is pretty much my entire development stack, short of my editor. Happily enough, VSCode updates just fine.
I have the RN debugger working more or less. There is a Cross Origin Resource error that occurs everytime RN opens up chrome, it opens chrome up to localhost, and I have to type in my IP address instead, which is a bit odd, but the debugger now attaches reliably, so compared to what it was like before, I'm good.
The Expo client is random. It tries to install Expo on the Android emulator all the bloody time, sometimes it works, sometimes it doesn't. I just want Expo to open. I have to use the client to open the emulator if my IP address changes, and this can take 10-15 minutes to jump back and forth between trying the command line client and the GUI client, eventually one of them opens my app.
And then if I login to my app too many times in the emulator, I max out the # of connections allowed to google's auth service and I have to shut down the emulator to close the connections or else I can't login again. I'm guessing it is a bug with how hot loading code works (not cleaning up open network connections?), but at least I understand the fix for it.
Basically the entire RN development stack seems like jank.
Also JS taking 5 minutes to compile blows my mind. I've compiled entire embedded OSes in less time than that (and they did more!).
never had problems with expo, the emulators dont hold state if you close them, only time it will reinstall is if you close and open the emu OR expo client has updated but you get a prompt asking to update
FWIW I regularly (every month-ish) update all my dependencies in my native iOS projects (cocoapods) and it’s exceedingly rare that things break and when they do, it’s a matter of tweaking <15 lines of application code to fix. Stuff really only gets ugly if you go upwards of a year without updates, and even then it’s still somewhat manageable.
So maybe some library ecosystems are worse than others.
I've had the same experience with the current enterprise Android project I've developed and maintained by myself (at a company). I have my library versions all in my top level gradle file and every few cycles I'll go through and update everything to latest and just build the app and see what happens. It's rare anything bad happens at all. I encounter far more trouble upgrading gradle and the build plugin itself than my dependencies.
Having to delete node_modules to “fix” it is indicative of a poor package manager. Although not entirely the same, it reminds me of cabal hell, in Haskell many years ago.
I'm borderline infuriated that this isn't the default way that npm works. Maybe if people didn't willnilly break things and followed semver, it'd be okay, but I waste too much time bisecting why some package that used to work is blowing up my build or failing in less obvious ways.
But I'm a crusty almost-30 .Net developer used to Nuget.
> Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5.
No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them. Whether one particular package correctly respects semver is irrelevant.
Because that's not how it works. Subdependencies are still liable to slight shifting - of course there is the shrink-wrappish package-lock and npm ci, but they do some weird things I don't want to elaborate here.
It's not related to RN but you touched on something with NPM that made me realise that, for some reason, I never trusted its `update` command. If I wanted to update a specific dependency to a new version I would take the `apt` approach and just install it again, or tweak the version number directly.
Contrast this to how I've approached it in, say, Ruby...I'm very confident in blindly running `bundle update` and checking the diff to see the result.
Hi! I've contributed at lot into RNN and love to read comments like yours. I feel the library is very underestimated by the community and IMO should be maintained and shipped with React Native by default.
I've been planning to switch to V2 in our starter kit for the next major release.
I have been working on a commercial RN project for 2 years now. As of today, the project is ~50kloc, and provides builds for Android, IOS, Windows, and Macos platforms. I started it using RN after prototyping with an early Ionic2 version and checking Xamarin.
The code share between IOS and Android is very high, almost 100% (except a few simple home-made native components), and we are above the 85% of shared code between the mobile and desktop versions (mobile is RN, desktop is react-native-web + rewriting of several components on a Qt WebEngine with native versions of a few RN components rewritten in C++). The C++ part is actually very simple, and under 2Kloc. Note that we use Typescript everywhere on the React side, and we consider it very valuable.
Overall, everything works great, we have a few performance issues here and there, but nothing we can't deal with. However the biggest flaw is how indigent the build system is (combining all the flaws of npm and the issues of android upgrades), we still do not manage to have reproducible builds, and it's been sometimes very painful to fix an issue a few weeks later because it would just not build and require a few hours to make it build again.
Oh my where do I begin -- Yarn (to me) appears to be faster, and breaks less (if ever). With NPM I kept finding things not working, and having to delete node_modules and re-installing. Yarn just works, and I haven't even considered using NPM since installing yarn.
Ehh, I have a `yarn depreset` command in my package.json files on most projects at work because I still often have to delete node_modules and reinstall everything. I got tired of typing out the whole thing.
Granted this is oftentimes because our dependencies float a bit, especially since we've been migrating to a new major version of one of our major dependencies, but it's still usually the quickest way to fix weird dependency issues.
For us, npm tends to be really wonky in a CI environment. Partially because our CI container needs updating, but also because `npm install` doesn't actually do what you think it does. Gotta use `npm ci`. But the npm in our CI container is old enough that it doesn't actually support that command (yeah yeah, I know -- I don't have access to that part of our build process).
As of npm 6 though, the differences between yarn and npm have been whittled away considerably. Really, the biggest reason we use yarn is because we also use React and a number of other libraries that come from Facebook, so we're just staying under the same umbrella. We don't expect Facebook to break their own tooling, basically, while npm has indeed broken a few things for us in the past, many times critical things.
Not the most compelling of reasons to be sure, but that's why.
It caches locally and doesn't hit the net for most redownloads, the lockfiles are significantly more reliable, there's the ability to "force" a transitive dependency to another version, the workspaces system lets you work with monorepos with multiple packages much easier, tools like "upgrade-interactive" are built in and make upgrades much easier, and more that i'm probably missing.
So I just thought I would put my thoughts into this, I've been using React Native to create a number of Apps for a very large company for a few years now. These Apps are used out in the wild and I get to see them being used. As a codebase I think it's great - a really nice way of working and creating something. It's got great integration with tools and the general code setup is really nice.
However; If I'm being honest I don't think I've ever seen a worse managed project in my career. Each version that comes out seems to be completely incompatible with the previous one. Getting the App to simply run can take far longer than it takes to actually build the app. There is no locking of library versions so things conflict constantly. Often times the team will update React Native to use some new feature, this makes all backwards compatibility with Xcode incompatible. I think I drew the line when the advice was, just update your whole OS, download the latest Xcode, Yarn and then this latest version will work.
To be frank, it's infuriating - and I know it's not yet 'officially' released but if this is the state of how they plan to manage React Native in the future, I can't see much hope in it. And that would be a shame, because as a framework I think it's fantastic.
I never really understood the version numbering. It's still pre-1.0 and yet it's somehow production ready and encouraged. We're using React Native at work but I'm really conflicted about it for a number of reasons. As the sole mobile developer it's my responsibility to deliver our apps but something in the back of my mind doesn't sit comfortably pinning everything on a framework that isn't even v1.0 yet and it shows.
A few years back I was working with Titanium SDK to build apps in my spare time; so it was a pretty obvious choice for me to checkout React Native. It's pretty cool at first but once you dig a little bit deeper and try to tweak things here and there, add extensions, third-party frameworks, ..., the pain becomes very real.
In fact, I learned iOS app development using Swift & Xcode just to not work with React Native anymore.
I think the commenter is saying something I've felt about cross plat for most of the 10 years I've been working in it... ultimately the best user experience is delivered by the native platform and tools.
Cross platform tools can get you really close but you'll be spending a non-trivial of your time tinkering/tweaking shared code to fix or create different issues on different platforms. That's time that takes away from creating a great user experience on a single platform.
That's not to say Cross-platform tech is all bad. Just that you have to be aware of the tradeoff that you won't be able to 'give it your all' towards the best user experience on a single platform.
PS - the one tech stack that gets you really close from all the ones I've tried (Mono, C++, hybrid web apps, RN) is Unity. But that's for an entirely different use case than apps :)
The huge myth about cross-platform mobile development using web technologies isnthat it gives you a faster time-to-market.
The reality I’ve seen, developing both hybrid and native, is that native has the faster time-to-market because all of native stuff (debugger, GUI builder, etc) works out of the box and all the time saved by a shared codebase is eaten up with tweaking the shared code, having to do stupid JavaScript tricks, and dealing with all the bullshit of the web that hybrid development brings into your app.
I'm sure the users appreciate native. Native is the best you can get. Anything else my be better for the developer, but is worse for the user. Especially with something like power consumption
Yes, they do. Obviously they might not know that the difference is due to the app being coded differently, but people do notice the little bugs and odd workarounds and slightly off UIs in apps where the dev(s) are either not skilled enough or don't care enough to hunt down every case. Granted, they may not react (heh) much more than "Huh, this app does this weird thing"
Of course they notice. It is very easy to spot when a company is cheap and uses cross platform tech. Some (Xamarin) are easier to hide than others (RN, Cordova), but it’s always there.
> No updates but if you'd like to help financially sponsor the work to get this done...
For a project coming from Facebook, this is a bit rich. It's basically saying "you can pay us to build it for you," which isn't wrong, but it's not what you expect from filing an issue on an open source project.
What is very well known and understood with React Native is that Facebook has surprisingly limited resources to work on it, so Facebook developers mainly work on parts of React Native that Facebook uses. It's understood that if you have a feature or use case that Facebook also doesn't have, you should be prepared to contribute that yourself.
It's not a case of limited resources. There's twice more people on React Native team than people working on React itself, and that doesn't count all the neighbor projects that RN relies on (Metro, Yoga). And still this isn't enough.
At some point you can't "throw more people" onto the problem. Facebook can't just add a few hundred developers to the RN team and expect them to collaborate well. But that's more or less what you're asking about.
Realistically, several companies "scratching their own itches" as referred to in a sibling comment reply tends to work better because it creates focus and areas of responsibilities around real use cases.
RN isn't maintained by Facebook alone. The surface area is vast, and there are many folks externally who help with different pieces that they depend on or care about. There's a few consulting companies that help maintain RN, and they need to earn money in order to be able to contribute to open source instead of working on their client's projects.
I think this very problem is what makes a lot of people cynical about open source software. HN sees frequent "If you want to see development on [open source project X] continue, money puts fingers to keys" cries for help—from the FSF to Mozilla to Apache. And yet, when one of the most valuable companies in the world writes a blog post about their open source software, leading with:
> At Facebook, we're using React Native more than ever and for many important projects. One of our most popular products is Marketplace, one of the top-level tabs in our app which is used by 800 million people each month.
has a project that's short on cash, how much money does it really take to make this stuff happen? When a company with tens of thousands of employees and billions in revenue and a billion users can't manage to address the very real and critical problems that their insanely popular framework has, what is a tiny project like PyPy supposed to do? What are the folks that make react-router supposed to do? What about the people that contribute to vim/iTerm2/VLC?
Certainly, the world keeps turning and open software keeps getting written and improving. But if you're embedded in open source and you see this kind of nonsense, it's hard not to feel a twinge of cynicism that even a deep-pocketed sponsor can't manage to help a project be exceptional.
Facebook invest in the part of ReactNative that they care. Other companies can invest in the other parts that they care.
Isn't that the point of Open source? Project gets better by everyone scratching their own itches, which collectively means everywhere got scratched.
How would RN being closed-sourced better in this case? Facebook will still fix RN in the part that they care, the different is you don't even get to use that.
It's not unheard of to have "sponsored" issues. In this case though, none of the commenters on that thread work at Facebook. It doesn't mean the issue won't be fixed if no one sponsors it but if you care about it getting fixed sooner, you can send in a fix yourself or sponsor someone else to do that work.
The downside with those is that the build of JavaScriptCore is significantly bigger than the one React Native currently ships with. It's quite a big dependency to have in an app, and a shame Google doesn't expose the system V8 runtime on Android in the same way Apple does with JavaScriptCore on iOS.
Android stopped having a system V8 runtime several years ago. Ever since all webviews you use are just frames to a normal app that's updated over the normal app stores.
React Native is hot garbage. I work on a commercial project and it's unbelievable that it can't even compile without hundreds of warnings. Talk about low quality development work.
And every few weeks I shudder to pull a new version, knowing something will have change that broke our builds.
Now let me tell you about debugging in poor network conditions. Ugh.
That doesn’t seem to be something I’ve seen any of the core contributors acknowledge and is often overlooked. As a relatively inexperienced developer it seems like a bad thing on the face of it but the builds still succeed... what’s the tradeoff?
I'm actually a native developer. I'm responsible for a framework that supplies the react app with features it can't implement on it's own (or can't implement efficiently enough). So when I do builds, I need to know if I have any build warnings in my code, but it's almost impossible to see mine in the mass of React build warnings.
It also makes me wonder how compatible react apps will be, for example one build warning about a deprecated iOS feature I inherited actually causes a crash on iOS 12. We have over 400 warnings from the react code alone, how many of those are future land-mines? Quality development dictates your builds have few, if any, compiler warnings. Even if they are things you know will never be a problem you fix them or adjust your warnings so they don't potentially obscure other, more dangerous warnings.
That's a good rule for any professional development project, but when you are developing a shared class library for other developers to build professional products from, it's far more important. The React team's failure to clean warnings makes me question their actual ability and commitment.
If I recall correctly, many of these warnings come from the default settings provided by the starter Xcode template. As we mostly integrate React Native into existing projects here at Facebook, this is something that we're mostly blind to.
As it happens, someone sent a PR the other day that fixed a bunch of these warnings just in time for the new release candidate we just cut this week. Please give 0.56.0-rc a try. If there's any warnings that still need to be addressed, send a PR or open and issue and ping me. This is something we want to actively clean up :)
Hi - What's the latest philosophy/best practices on interop with React web?
Is the philosophy still 'learn once write everywhere'? There are so many different approaches now to reuse React Native with React, like react-native-web and react-native-dom, it's confusing.
Some of those solutions are non-starters for me since I started with a React webapp and want to now have a React Native app that shares most of my existing code.
My gut feeling is just stick with HOCs, SFCs, proper isolation of the views and I'll be able to share the bulk of things like action creators, reducers, etc. Is this reasonable? Are there other good practices?
Your plan of sharing business logic sounds good. We don't currently have any recommended way to share code between web and iOS/Android, although I'm hopeful we will at some point in the future.
I'm actually curious - how does the React (Native) team feel about such efforts? Initially RN was pitched not for cross platform app development, but "learn once, write anywhere". I guess this is the reason why sharing more code between RN and web hasn't been prioritised by the FB RN team, but do you see your team wanting to encourage this?
For sharing code (even view code) between React Native and React web projects, also consider Microsoft's ReactXP project[1]. It is very actively developed and might be what you're looking for.
Have you used it? I saw it before but felt wary about having yet another layer above RN and React. I’ve been burned by taking on too many dependencies doing magical/black box things in the past...
Could you possibly say in more detail where in the RN codebase can I find the exact code which generates the "single JSON message that lists mutations to perform" that you claim? I'm super interested and desperately trying to pinpoint it, but I'm having really serious trouble with that :(
Awesome, thanks for posting this! Been hearing/reading some of the claims that FB is done supporting RN and it got me spooked :p
We've been working on a RN project [1] for the list 6 months or so. Although it's been a bumpy ride - overall I have loved it. RN mixed with Firebase has been an awesome experience.
Is there any of this new architecture on the master branch yet? I am currently working on a React Native renderer and would like to try and make sure it will be compatible with this re-architecture.
Most of the code is in the repo in React/Fabric/ and ReactCommon/fabric/ but unfortunately it's not runnable yet due to some missing dependencies that aren't currently in the open source repo.
Question to RN experts: does anyone of you know where in the RN codebase can I find the exact code which generates the claimed "single JSON message that lists mutations to perform"? I'm super interested in pinpointing it, but I'm having serious trouble with that :(
One of my main issues (as RN plugin developer) is build system being so fragile. Plugins are usually declaring different library versions. Same thing with gradle versions itself. Currently RN is using gradle 2, but some plugins started to use gradle3, which lead to even more incompatibilities.
I also have several suggestion for RN, but have bad experience with ignoring my issues. React team recommends react-native.canny.io for feature request, but those are pretty much ignored too (not seen official response to any of those).
This is very frustrating as plugin developer who really want RN to progress forward and works for free in my free time.
Any plans to fix the hundreds of build warnings RN causes and the broken configuration settings that make parallel builds impossible? Huge pain points in our hybrid native/RN app.
I moved a way from react-native to flutter because developing react-native is frustrating.
Note: I love React and Redux but I HATE react-native!
a) Flutter's hot reload is a much better experience than react-native or Expo.
b) I am more confident with Flutter (React-native makes me feel incompetent since I have no idea about native stuff). With Flutter, I feel that I am in charge of my code, because dart compiles to native arm code.
c) I have OCD and don't like RN's console warnings when I am compiling the code.
d) Flutter UI widgets are so consistent that I don't even bother testing on both platforms. (one is enough)
e) I dislike RN's ecosystem. I don't even bother making canny request on react-native's canny, due to lack of response. None of the most popular planned FRs from last year are done yet ! https://expo.canny.io/feature-requests?sort=top
f) React-native's libraries are out of date.(I prefer corporate backing over community support)
g) lack of response on stack overflow
If I wear react-native, I would take Flutter's approach instead of bridge. Completely modernize JavaScript, get rid of its bad parts and compile it to arm. SKIA is open source and if Dart can compile to it, so should JavaScript with more tweaks of course.
I think sadly a lot of it is just FUD. Refer to the comments about npm I'm addressing elsewhere in this thread. They're just ill-informed, or deliberately throwing shade.
> Documentation is written with IOS as the primary system. I still consider this to be a betrayal of programming fundementals
>Hot reload stopped working overnight once. No way to root cause this. Ive never guessed so hard. Still not fixed, might just reflash my entire computer since uninstalling and reinstalling didnt work.
But really, showcasing the native platform for dev being Apple Irks me. They are bottom barrel for programmers.
My dream is react native reimplementation (not just bindings but complete rework) with Kotlin. It could compile to Android, iOS, Browser as a native target without any need to bridge between JavaScript and native code, work faster and having first class sane language. I think that only big corporation could make it, Jetbrains, hear me :)
Why not check Xamarin? It’s already on a modern language (C#), great cross platform capabilities (Xamarin Forms), but can also directly interop with native APIs when needed (they are always needed).
I like Xamarin but I do not like the dev process yet for the frontend. I think if that would be leaner (more Core2 and potentially command line and reloading instead of recompile: only for dev ofcourse) it would be more popular. Now it is a very heavy process; thats not because of c# or f#; they can both be very dynamic. Not sure why not more work goes into making development smoother.
Having said that, I for one like working with Forms+renderers and a reactive framework a lot more than RN. I can go for years and have my code work fine after updates; I find npm such a nightmare and RN feels too driven (logically) by FB needs.
Check out Dart with Flutter. You get browser compatibility with Dart alone, iOS/Android through Flutter. Flutter isn't a JS bridge solution as RN is, alleviating some of the pain that RN exposes.
Also Flutter is getting a lot of traction right now.
The development experience is incredible (probably why Facebook mentioned instant reload), lots of companies are trying it out e.g. Evernote and the community is buzzing with new plugins. Plus it doesn't wrap native components so the core of it just works cross-platform.
I think the flutter approach is probably the better one, since the ux stack has more control over how things are done.
Instead of being wrappers around complicated native UI libraries, it's a 'game engine' over a lower level graphics layer. It's a smaller surface area to screw up on and create abstraction leaks. You don't have to be a iOS/Android and react native expert to fix hard issues, just a flutter expert for the most part.
It's just too bad the language run time is dart and it's run by google, which is infamous for being fairly ADD with projects.
Flutter is at least open source, here's hoping that the dev community gets organized enough to have the will to adapt annual iOS updates into the Cupertino widgets once Google drops support for the project.
1. Apple doesn't refresh the UI components annually. In fact the last time it happened was 3 years ago. Not to mention that the Cupertino widgets are very limited in nature.
2. This project definitely feels different compared to some of their others. The experience is just so much better than writing iOS or Android code that I think they would be insane not to support it.
Maybe they don't do full-on refreshes a la iOS 7, but perhaps they tweak little animation physics here and there. I'm thinking of this article's critiques of Cupertino widgets feeling a bit off:
React Native had hot reloading a year before Flutter was announced. Not to take anything away from Flutter (I heard it's great!) Personally I'm rooting for all declarative UI libraries and platforms, and I'm very excited Flutter is getting traction.
eh. The wrong type of typo can take down the entire app. Other typos it can recover from. Trying to change redux components just doesn't work. All in all it isn't too hard to fool RN's hot loading.
I'd also note that hot loading is turned off by default for RN! I can see why, having it on I have to know what types of things I can use it with and what types of changes will need a full relaunch.
Let's not even get into the "reload" button and what that may or may not do. (Note: I am using expo, so I have an additional layer of bugs and abstraction on top, having to force close Expo on the phone is way too common in my experience)
There's also been a number of complaints from RN users lately that the RN team hasn't been communicating well, that the roadmap is unclear, etc. This at least gives an indication that RN is being actively developed and what they're working on.
Proooobably moreso a response to the Twitter drama from a few days ago where people were claiming that Facebook was moving away from RN... especially considering the author was in that thread.
A little sad, if it deemphasizes .net. I hope the Core transition doesn't turn into a boondoggle, though I'm afraid; it's taking a long time to reach parity with where the full framework was. The history of major language rewrites is not overly encouraging.
Working in C# on .net 4.5-4.7 is such a tremendously productive platform.
BUILD 2018 was full of .NET goodies, including .NET Core 3.0 roadmap with Forms/WPF/UWP/XAMLDirect support as the main goal.
It appears it is the usual political issues between Microsoft divisions, which I thought had gotten better after all the re-organizations that took place.
I wouldn't be surprised if this JavaScript everywhere wasn't yet another way Microsoft is trying to appear cool among the Google devotees crowd, like how they are jumping in PWAs as well.
That's a ridiculous thing to say considering 50% of dev's are writing on Microsoft stacks and the company pulls in over 20 billion in actual profit each year.
God, I hope not. They would have to re-implement every tiny little detail of every button, textbox, and every other widget on each platform. Then they'd have to keep it up to date every time the platform updates. That's just an impossible task.
It's pretty possible, and has been for a while:
1) Flutter already implements the Material spec and Cupertino spec, so the biggest cost, the upfront cost, is satisfied. In fact, the Flutter team found inconsistencies with the Cupertino spec vs. what iOS' animation kit implements and filed bugs for them.
2) It's OSS; this problem will minimize as more people are contributing and using Flutter.
Most iOS developers writing 'custom' UI, etc. are just customizing UIKit controls. Same for Android. Not many are creating UI controls from scratch with custom hit testing, drawing, and accessibility handling.
Its very unfortunate that that there is not built-in library for navigation in RN or Expo. React Navigation is a capable tool, but the API is very awkward and convoluted, even for doing very basic things like opening modals.
I recently started building an app using Cordova. I chose Cordova because I'd used it before and enjoy using VueJS (have used React and have no problems with it, just really enjoy Vue).
What a mistake.
I run into problems with the build on a weekly basis. I generally have very good debugging skills but in many cases could not figure out what was wrong. Usually `cordova platform remove ios && cordova platform add ios` fixed it. There is a ton of state in there and it's never been clear to me how to make it reproducible from the configs.
Many plugins simply don't work as they are outdated and not compatible with new iOS/Android versions. Using Firebase for notifications is one example.
Of course, I greatly appreciate the open-source authors who built all this and I don't expect them to solve my problems for free. I'm just pointing out my own mistake in choosing to use this tool, which doesn't solve as many problems as I thought it did.
Can any developers here say whether they've had a smooth experience using React Native? I'll definitely be trying it out soon...
You are right about that one... more of a "glamour" metric than something very useful (like when longest streak equals current streak which is the case for our internal dashboard [1]). In this case you know you've been very consistent over that time period. We will probably remove that one soon.
We do believe that at least with our product this kind of information it will inspire more confidence in our users when we publicize this information more (vs. lots of products that end up stagnating over time).
Excellent news. I've had the opportunity to work with the framework while mentoring a customer and the experience has been pretty enjoyable. Hopefully these upcoming improvements will be backed by better documentation—that's the only area that really felt lacking.
@hiram112. React native works in a 'conceptually' similar way as wxWidgets (if you are familiar with with that). It uses platform's native APIs. It does not rely on a web browser on your mobile device. The integration is also not just for widgets, but underneath it abstracts out Image, network api, basic storage/preference primitives, screen rotation, etc.
For the things that it does not abstract, it let's you write a native module, that you register with RN runtime, and then the APIs for your native module will be avialable to your RN java script code.
There is an active opensource ecosystem of RN-modules that you can leverage, that will work on Android and IoS , abstracting the platform specific things that RN does not do yet themselves. Everything from non trivial camera interactions to bluetooth specific things. Eg
In the simplest terms, it renders native UI (the JSX part maps to UI components that the iOS and Android frameworks provide) but it maintains a bridge so that you can write your business logic in JS and have it work against those native components (as far as I understand it).
It's not the same as using a web widget as your main interface and having it render the same kind of HTML and CSS you deploy on the web.
they also mention async rendering. cool.
but they also did in ways that breaks the Detox e2e testing framework ,if i am not mistaken, in a way that is difficult to fix without proper support from RN code itself.
this kind of stuff is awkward. do something new cool, but break major functionality for some users of RN.
I have very positive experience with React native, and also with React Native Web. Being able to share source of full pages/activities/forms across both Mobile platform + Web browsers, while having Native look and feel -- is incredible.
Very rewarding not just being able to use the same 'code base', but also leverage same paradigms to manage UI Layouts between native and web (with flux).
As a side note, I absolutely despair when I have to fall back to CSS or even bootstrap.
Once I, finally, 'groked' flux -- it was huge productivity booster and I can rely on that learn-once-use-in-many-places knowledge across not just my app, but also when building small web-sites (in web tech only).
My approach for the app, is of a 'hybrid'. That is, my app starts out as Native, and then, for some 'activities' (in Android-speak) -- I use react-native.
I have implemented native modules to get access to platform specific elements from React native code (eg networking apis, security, hardware device access, device-preference/database stores) -- while basic forms/widgets and navigation logic for some pieces are in React, leveraging React-native and react-native-web underneath.
I think the UI paradigm introduced by React is a sweet spot for UI development (concentrating on state as first-class-citizen).
I am hoping same paradigm (and similar abstractions) are adapted by MS toolchain for desktop and console UI in .NET-based solutions.
Another side note (not RN specific) :
C# is really a much better language than JavaScript, but until browsers can supports C#-subset, JavaScript is the only game in town for the 'modern' cross-platform dev efforts (eg. cross mobile, desktop and web-browsers) ).
In terms of some challenges I have experienced with RN:
a) build system. Creating a release build is a major undertaking. As the solution has to merge the 2 worlds: native and JavaScript-specific asset management pipelines.
Error messages are obscure (eg I ran into issues, for example, where a path for an Icon file was too deep, moving it to shorter path, solved that one).
Guides are for primitive (and non-hybrid) approaches.
b) Lack of standard (RN and RNWeb ) support navigation component.
c) Small things like: no Checkbox component for IoS..
d) Cross-platform app-store compatible icon management is not built in. I use react-native-vector-icons -- so that solves that problem for me. But app-store compliancy like this should, ideally be part of such platform.
e) As the article points out, the integration bridge between RN and native is not efficient for 'constant interaction'. Because it requires you to serialize data structures back and forth.
So impossible to write 'hybrid' apps where small parts are in RN -- instead it has to be 'bigger things' that would not require too much back-and-forth.
f) the Debugging with Chrome over TCP bridge -- is basically a horrible/slow/barely working. Navigations from one screen to another take like 2 seconds, while the debug mode.
Because my components work on web browsers, thanks to React-native-web - I end up, most of the time, debugging my RN logic using React-native-web within browser debugging tools (rather than starting up the native app and then spawning the debugger with Chrome bridge).
There was never a concept of State-as-first-class citizen for UIs.
And there as never a cohesive multi-screen layout engine story, like we have now with flexbox (via RN and RNW).
So in my view, the data binding via explicit state-management paradigm that React introduced -- will survive for decades, and will be copied to other programming environments.
Same, probably for flexbox as a layout management model...
Although, there, I wish that it would be more 'typefull' where various incompatible layouts could be flagged as errors or warnings at compile time.
Perhaps (and may be this is is far fetched) with the advancements in practical category theory, compute power (including at compile time) -- we should be able to do 'shape' management as algebraic concepts -- where layout engines, should be able to treat layout definitions as composeable, multi-variable functions.
WRT javascript vs C#, I was just noting, that, in my view C# is just a much better language, and I wish it would have been a de-facto web-standard and not javascript.
This way something like React, would not have been conceived in javascript.
That's the regular RN documentation - which is of ZERO help here. Please check the topic of this sub-conversation - you missed it.
Hint: The parent mentions the "JSC C API". You point to Java and Objective-C - that alone should give you a hint that something is wrong with your links, that they don't quite fit into the conversation. That's the equivalent of a physics question where you want Watts and get Newtons - a unit mismatch as an indicator that you solved the wrong problem or the problem wrong.
And just to say that too, I'm the co-maintainer of a popular native package for RN, so I'm already quite familiar with the RN native API for both Android and iOS.
Facebook can make software great because they have great engineers, but they've suffered a major case of scope creep, which leads to more than a few loose ends as the company assigns their best engineers to [choose your own adventure]:
- maximum profits (woohoo!)
- reaction to potential regulation
- unwanted press attention
- wanted press attention
- the shiny new thing
That's why I never switched to React. It's a good way to organize things and was clearly well engineered from the start, but there are other choices besides React (and RN) where leaders have demonstrated their willingness to stick with it through thick and thin because...it's all they do.
This is a pretty unrealistic view of how big companies work. Engineers aren't fungible, and no one has been "pulled off" of React or React Native to anything like you suggest.
React is my full time job (I was also the #1 committer before joining FB) and no one is planning to abandon it. Even if Facebook company leadership decided for some reason to divest, React would live on with the support of its community similar to other projects without corporate backing.
While it may be your full-time job, you're still participating in a larger mission, right?
Take the case of the legal problems with the React license that eventually were ironed out or the privacy issues facing the company more recently.
Neither of those would have been a factor in your day to day life if React was its own thing, right?
If no engineer has left the team, through their own will or through enticement, you have my apologies.
I'm not arguing that you're not committed. I'm arguing that working for a large company is a distraction, which is true of all large companies. Would you agree that the licensing issue was unnecessary and distracting?
Don't get me wrong, I think you're doing great work and React isn't going anywhere, but there's a broader mission there that is distracting from doing that one thing. Do you ever wish it were it's own thing (if money weren't involved)?
Certainly there are downsides to any setup, but due to React Native's large ambitions I'm unsure if it could have ever been created by an independent community. There is a lot of work that goes into it and the abundant availability of complex real-world problems (to a greater extent than I've seen anywhere else) spurred by this setup pushes React Native to be a more capable project.
Thanks for the insight. I can tell from how you write about React, you're very dedicated, and I feel your passion.
Upper-level managers at the large companies I've worked for universally saw these types of projects as "cost centers" and tended to interfere in ways that demonstrated a basic misunderstanding of the value. I hope that's not true in your case.
Scope creep? Is that a nice way of adding shitty useless features and dark patterns? Because Facebook wins the gold medal there. Marketplace and their garbage message app for instance.
So then you start this goose chase of hunting down the current issue since it starts getting into this loop of closed, open a new issue, closed, open a new issue, closed, open a new issue, etc. And everytime this happens relevant information gets lots because its not transferred to the new issue.
And then you finally find the newest, currently active iteration of the issue and find out that its still not fixed and the workaround is to stop using the React Native version and re-implement the feature yourself natively on both ios and android.