State of React Native 2018
facebook.github.io
facebook.github.io
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.
Ironically if you wrote this up as an issue in their tracker, I would surely have one more such experience when they closed it shortly after.
That said I complain out of love, because React Native is just awesome when it works.
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...
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.
edit: Just realized which Dan you are. Thanks for the insights. Your team does good work.
These issues are extremely costly to teams using React and they absolutely need much faster resolution.
Pay $$$ or €€€ to get enterprise support, promissing to fix your issue with a Pull Request in the mainstream repository
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.
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.
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.
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).
> 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.
[1] https://ps.reddit.com/r/reactnative/comments/7wqxjy/why_are_...
This sounds totally backwards.
It is. It's the result of low level managers using issue counts as KPI: now it's a metric that must be gamed.
The explanation is more prosaic: https://news.ycombinator.com/item?id=17316150
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.
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.
It's not the only factor, it's highly product dependent, but it is very relevant to most outward facing activity...
This is the problem. Why not close them when they are fixed?!?
In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
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
As an aside, who's really the man child? Hacker News users, or the ~50 year old man insulting/trolling them with that image?
I'm not unsympathetic to your claim but context matters. This is an enthusiasm problem. Not a community one
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.
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.
PS: If you would like to learn more about how we prepare each release, please visit https://github.com/react-native-community/react-native-relea...
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)
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.
Last year I rewrote my game Falcross in RN and I’m so happy with my choice. Seriously, check it out and see if you can tell it’s a “hybrid” app: [App Store]: https://itunes.apple.com/in/app/falcross-logic-puzzles/id500... [Google Play]: https://play.google.com/store/apps/details?id=com.rawrmaan.f...
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'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.
Consider your DAU +1
Glad you’re enjoying the game :)
I do see that the buttons don't align with what the OS displays but that's ok for a game.
What I do see however is that it performs VERY poorly on my Pixel 2. Which is pretty surprising considering there is not much going on on the screen.
Not a major hindrance for this kind of game, but still very noticeable.
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.
That's the unfortunate toll you have to pay when you add another layer of abstraction like this.
It is sad .. a crosplatform solution that performs horribly on one of its two targets is not a great one :/
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.
BTW, here is our RN app. https://itunes.apple.com/us/app/bunch-group-video-chat-games...
I (we) also love RN (most of the time :P ).
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.
Your app looks fantastic, by the way!
How well does it run on an intermittent network connection with poor bandwidth?
How well does it support key native features of both operating systems?
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.
Anyhow, the game is pretty fun!
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.
Forms: tcomb-form-native Recording: react-native-audio GPS: react-native-background-geolocation Camera: react-native-camera
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.
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!)
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.
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.
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!).
I've honestly never encountered an error with a message telling me to blindly run npm update. What's a package that does this?
So maybe some library ecosystems are worse than others.
Could be time to switch from Gradle to Bazel. It would also be nice to see the last of Apache Groovy, don't you think?
Why not just pin your dependencies to specific versions, ie - “somepackage”: “4.2.9” ?
But I'm a crusty almost-30 .Net developer used to Nuget.
There really is no reason to be encountering surprise sub-dependency changes with npm.
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.
Npm is more fragile than it should be.
I've been planning to switch to V2 in our starter kit for the next major release.
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.
Can you not use yarn?
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.
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.
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.
In fact, I learned iOS app development using Swift & Xcode just to not work with React Native anymore.
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 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.
It felt to me like I was fighting with the framework every step of the way, swift on the other hand is an absolute joy to work with.
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.
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.
> 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.
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.
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.
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.
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.
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 :)
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?
Will React Native finally support exchanging BINARY data (ArrayBuffer, TypedArray) across the bridge?
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.
[1]: https://itunes.apple.com/us/app/bunch-group-video-chat-games...
(Cross-posted this question to: https://stackoverflow.com/q/50873408)
(I've already asked this in a post on the parent thread, but I let myself copy it here in hope there may be higher chance you'll read it that way...)
(Cross-posted this question to: https://stackoverflow.com/q/50873408)
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.
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.
> 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.
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.
That would also be the day that I stop using MS Office as my go-to.
Because the performance was just not good enough.
They had custom, native UI while the backend was running in Java.
And it just wasn't fast enough. Even when hot, throughput and latency weren't good enough.
So, they started moving to C++ as much as possible, as fast as possible. By now you can run Writer without Java at all.
Current JS runtimes are all slower than HotSpot.
Yet somehow we're to believe that doing the exact same mistake again will work better this time?
It'll still end up being slow and a memory hog.
Moore's law is dead. RAM is more expensive than at any other point in almost 10 years.
You can't just throw abstractions at everything at the cost of performance anymore, expecting the hardware to catch up.
Somehow I got the feeling that MSFT has been invaded by JavaScript developers.
Working in C# on .net 4.5-4.7 is such a tremendously productive platform.
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.
Microsoft is as relevant as ever outside SV coffee shops.
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've love a JSX like tool for Flutter, especially since JSX is just syntactic sugar over a c-like syntax.
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)
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.
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.
https://harveynick.com/2018/05/21/an-ios-developers-opinions...
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...
I have built couple of native like applications with react native, and my only recomendation is using native navigation, it is key.
https://loremipsum.ueno.co/using-react-native-to-build-a-pro...
Project is definitely healthy in terms of activity both in terms of commits and contributors. Here is the dashboard:
https://chart.ly/github-dashboard/facebook/react-native
Would love some feedback on our dev dashboards if anyone here is interested!
Also great for just seeing activity in one place. GitHub's website is great, but not really geared to providing much of this information in one place.
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).
[1] https://www.dropbox.com/s/86jik7dvxwzdddd/Screenshot%202018-...
and the fact that the opensource build is RED for roughly a year now ?
My initial guess is that it is basically running the same JS in a browser wrapped into a native GUI widget (win32, X, Cocoa, etc).
Maybe I'm getting long in the years, but seems like we've played this game many times.
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.
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
this kind of stuff is awkward. do something new cool, but break major functionality for some users of RN.
Either you find an native module like this: https://github.com/Polidea/react-native-ble-plx
Or implement a Native Module yourself(https://facebook.github.io/react-native/docs/native-modules-...), then you can use any native frameworks available.
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).
You're at least a couple of decades late, there, and the other way around: instead of `Winuser.h`, it's `react.js`.
I programmed MFC, Delphi, YACL (if folks remember..), wxWidgets, Borland OWL, Dojo toolkits.
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.
Thus far I have to send binary data as base64 encoded strings! See react-native-fetch-blob for an example, when I read a file.
Current state:
Example, issue: https://github.com/facebook/react-native/issues/1424 (closed but not solved, quote: "We are trying to keep issues focused on bugs and this is more of a feature request")
Documentation for native modules, which kinds of data can be sent back to Javascript: https://facebook.github.io/react-native/docs/native-modules-... (here the iOS docs, but it's the exact same for Android/Java)
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.
- 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.
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.
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)?
When I worked at an airline working on their websites, I wasn't privy to, or bothered by their flight scheduling or workplace relationship dramas.
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.