Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently:
The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can.
For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript.
I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.
>The common thread I see is that mixing native and react-native is hard.
We've experienced some of the difficulties in this area at Facebook as well. If you're curious, making native <-> JS integration more seamless is a big motivation for the ongoing architectural revamp that we've recently posted about: http://facebook.github.io/react-native/blog/2018/06/14/state...
It's a shame we weren't fast enough to help Airbnb in these areas, but the native interop will get better when the revamp is finished.
I did find it ironic while reading it that most of their pain was related to mixing React Native with a large, existing native app, yet that's exactly how you're using it at Facebook. I'm interested to watch how you get on in fixing this.
In my use we've hardly met any of those problems. I work for an agency, and the apps we've used it for are small or medium sized. All are new apps without legacy native components, and none of them mix RN with native outside of plugins. We also use 100% TypeScript now, which fixes a lot of their error-checking issues. Perhaps most importantly, I'm one of the few developers with significant native experience, so we're not encountering the cultural problems that they describe in the posts, of developers resistant to using the tech.
Interested to see what developments occur in this area, it’s a part of React Native I’m very familiar with as the product we are building has a native (C++) audio engine with a React Native GUI. Would be more than happy to discuss what we are doing, our experiences so far, and how we are planning to improve the integration on our end if it might be relevant to what the RN team are looking at.
That said, the experience we’ve had has largely been positive and I don’t think we could have achieved what we have so far given team size and time constraints without React Native. I suspect it gets more painful if you try to combine native and RN GUI elements - our UI is purely RN so there is a fairly clear separation of concerns.
I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target.
You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.
To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN commit) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something.
The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don’t really see a way around it for an actively developed library--which might be your point.
Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to “follow” it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.
I love that development model for internal platforms, but it sounds like you are isolating yourself from the pain points that your customers often face.
My current company casts a weary eye at third party software so the import process is slow and involved. This means we only take major versions, and usually not very quickly. When those versions then introduce regressions in our own products and in dependent libraries it only serves to strengthen the voices calling to ditch the external solution entirely. It'd be a different story if a major version seemed to be of consistent quality to squat on for a while, but each new version brings its own challenges.
To be clear this is all involved in life as a dev in a large software company. For my own personal use I'd rather see RN move as fast as possible. I'm fighting the good fight to keep up (and increase) adoption at work so I just hope that FB and the RN team keeps these things in mind.
Wow thanks, that explains a lot. So Facebook basically treats RN as an internal library, a single commit can change the framework API and the implementation at the same time so the constant API churn is not a problem.
I'm talking about mostly mechanical changes (think find-and-replace or slightly more involved). Those are easier to do because they can be done on both RN and products at once.
This doesn't work for any larger changes because nobody is able to rewrite a ton of files by hand just to change some API. So this is why we can't make big changes to the API without a gradual adoption strategy, even internally.
That's interesting. Do you think there are situations where it would be beneficial for third parties to use RN from master rather than waiting for releases?
I invested a lot into a full React webapp - it would be great to share some of that code with mobile apps. I have an iOS background but was intending to make a RN app so that I could share the bulk of the React webapp code and get Android support as well.
I have separation of container components and presentational SFCs so I’m thinking I could easily re-implement UI layers in RN if I wanted to without sacrificing the shared code. Do you think this is a reasonable approach? Or should I ditch RN completely and build native...?
It would be nice if there was a way I could pull that shared JS logic (which really doesn’t have much dependencies) into mostly-native apps without having to adopt RN... maybe I could just repurpose the JS bridge and be aware of its limitations (a sync/serialized/batched..)
Look into Cordova. It can wrap your static frontend in a multiplatform app that runs inside a chromeless web browser. Super easy to set up and use. Adobe even offers an online build service, PhoneGap Build, which can build Corodva applications for iOS without needing a Mac!
I have successfully used this approach to develop applications for both Android and iOS.
Thanks. I think I might try this out first since there isn't much overhead. What's the performance like for you? Any advice you have on mitigating possible perf issues?
The Cordova browser view is almost as fast as mobile Chrome/Safari. Debugging can be tricky, as in all mobile development, but I was overall satisfied with the available tooling. If your code is performant in the browser it should fare well in Cordova.
That was my take away as well, which makes sense. I think trying to seamlessly merge functionality across any two paradigms is going to be tougher than sticking with just one or the other. But for any company with an existing app, mixing in is the most likely first baby step into react native.
It's not just a baby step. For lots of people who are doing more involved work than a thin, straightforward frontend for a server, there are things that are just worse or practically impossible to implement with React Native/JS alone, meaning you'll have to keep falling back on native code. A 100% RN app is simply not feasible for a lot of teams.
Yup it's the classic double layer issue. I think the only way to do it right is to go full 'game engine' style, like flutter or unity. With these you have a very small GL library surface area and one platform stack to actually understand for most of your engineers. Maybe something like WebAssembly will be similar.
You often don't hear about these kinds of issues out of game engine makers. I could be totally wrong although since I haven't worked on games.
Udacity is a bit strange example. This means that they have what? triple size of react native in their main app? That's weird because on android react native blows APK to much larger percentage.
> If there's a place that has sucked up most of the conversation, it would be Twitter.
The conversations on Twitter are unfortunately not of the same fidelity as the ones on a traditional forum where you can actually compose full thoughts.
Perhaps it's better to say that Twitter has sucked up most of the attention of those same people.
Subtle distinction but huge difference imo because I can't go follow those same people on Twitter and expect the same type of conversation as they would have made on HN.
Perhaps it's better to say that Twitter has sucked up most of the attention of those same people.
I suspect the cause and effect relationship runs the other way: Most likely, people are going to Twitter because HN does not have the same quality of atmosphere it had when I joined.
Yeah for me it was not worth it at all. I was prescribed in High School through College but I stopped taking them in College because I turned into a irritable zombie. No amount of productivity boost is worth the emotional and physical damage that stuff does to you.
Also Exercise and Diet helped far more in the long run.
Maybe they could Google it :). I don't think Alphabet will ever be as popular as Google. That's like knowing that Comedy Central is owned by Viacom. Yes, that's true, but you probably don't care and don't really think about Viacom at all.
But does it handle "Google Chrome" and "Google+" correctly? Clearly, these should be written as "Alphabet Inc's Google's Chrome"† and "Alphabet Inc's Google's Google+", respectively.
Awkward, if you're not considering it as a technical source (and it is, in its field). If your primary concern, as a reader, was monitoring potentially important information as it pertained to your investments, would you not prefer that they lead with the actual thing in which you may be invested? Is it not a lot easier to scan for "News Corp" than to have to make the associations in your head that "Wall Street Journal" is something that one of your investments owns?
IMO it's just "consider your audience" writ large.
Actually, I applaud the WSJ's bold new vision of fully revealing the full chain of ownership of all corporate subsidiaries, components, shell companies, and other mechanisms and methods for hiding true oligarchic control.
While it looks odd in a technology context, for investors it makes sense because Google is listed officially listed as Alphabet. Therefore, the association between the two concerns is useful for less technically savvy business and investment readers which represent WSJ's primary audience.
Consider that the target audience of the WSJ is much more "investor" than "technologist". You really think investors wouldn't want mention of a company that might be in their portfolio? 'Cause that company isn't "Google", it's "Alphabet".
If you've invested in Alphabet without knowing that it's the company formerly known as Google you probably aren't someone who reads many articles about them.
If you thought Alphabet is the company formerly known as Google, you would be wrong. Alphabet is a conglomerate created to hold Google and was created first as a subsidiary of Google, to which a separate dummy subsidiary was created with which Google merged to convert Google stock into Alphabet stock.
Alphabet is not Google. Alphabet never was Google. Alphabet owns Google, and the performance of Google is tracked under Alphabet's own stock (which still uses GOOG, but is a concretely different stock). There is a difference, and these are people to whom it matters.
And what "everyone knows" is not relevant to WSJ's audience. The company is Alphabet. It is not Google. I don't think this can be stated in simpler terms.
The WSJ's news section can be considered jargon of its own. I'm sure you would not react in the same way if a "business guy" criticized a piece of technical reporting for things you expected to be in it.
> The company is Alphabet. It is not Google. I don't think this can be stated in simpler terms.
Those terms are simple, but not accurate. The company this story is about is Google. Alphabet is the public traded corporation in whom WSJ readers may wish to invest (or disinvest) that owns the company the story is about. (Google and Alphabet are both companies, but Alphabet isn't taking any action that is being reported in this story.)
Sure, you are that most important kind of correct: technically so. And so I'll amend it: "the company that matters to the WSJ's audience is Alphabet because they're where the money is."
The mixture of pedantry and willful vagueness in this thread is weird.
If your point is "that's the same thing", it's not, see elsewhere in this subtree. If your point is "that would be clearer", I agree; if the WSJ's standards for prose in reporting meant that they put stock ticker names in the headline, I'd guess that they would have (I don't recall ever seeing them do so before). But consistency, in technical publications, is generally valued. The name of the company in which readers hold stock is "Alphabet"--therefore, call it Alphabet.
Offices, on the other hand? Marginally more competitive. My last office had a Google Mini lying around! Not nailed to a wall, though I suppose it could have been and provided the same utility.
No, that's not true. I was using it to shim a monitor for a while. Nest still reigns supreme.
It's especially funny considering they confuse/conflate Chrome (a web browser), ChromeOS (an operating system where all apps run in Chrome) and Chromebook (laptop running ChromeOS).
Yeah. You're not going to get quite the same flavor as if you had fried the meat in butter or whatever, but it's still pretty good, especially if afterwards you add some rice seasoning or nutritional yeast.
