If their Lacinia GraphQL library for Clojure [1] is any indication of code quality, this should be very useful. I’m very impressed with the former, and I’ll be sure to look this new one over.
Why a company the size of Walmart does this cross platform crap is beyond me. Do they not have the resources to actually write real native apps in actual Swift? Why is it desirable to code to the the worst common denominators for devices? Cross platform is just lazy. And React “Native” is inferior to actual native.
Absolutely agree, I avoid react / JavaScript ‘apps’ at all cost, they perform poorly, use excessive resources and seem to discourage an engineering mindset when writing code.
Out of curiousity, how are you able to detect React Native apps so you can avoid them? Facebook introduced React Native to their main app months before anyone noticed. Airbnb also was using it for a while before they publicly announced the fact.
At Airbnb, most core flows (search, home booking, map, trips/itinerary, inbox / messaging, the signup/login screen, profile, settings, and the hosting flow for listing your place) are all native. Most screens are built using a declarative abstraction on top of UICollectionView and UITableView.
The Trips tab in the app (itinerary) was actually rewritten in native after originally being implemented using RN.
It’s really too bad that people have this perception of RN’s use at Airbnb. I feel like people assume the whole thing is RN, which couldn’t be more wrong.
Yeah it's pretty easy to tell, even if they've been modified to not look like a browser frame if you notice poor performance or increased memory usage you just have a look in activity monitor or ps and you'll quickly see the javascript web workers etc...
Ultimately the declarative way of writing apps is objectively better and more predictable than the old mutable way :)
Now that said, I agree on the performance costs, and too wonder why Walmart is hellbent on this strategy, given the endless resources they have.
But at the end of the day, they have a head of engineering and need to make their lives simpler just like everyone else. If you know how to squeeze the performance out of RN/React, developing apps in the semi-FP declarative sate-driven way is a dream compared to all the old ways of client app development. People who's views are so against React/ReactNative usually haven't experienced it for themselves. I suggest really giving it try before making these comments which usually serve just to validate decisions already made. I.e. to make one's self feel better about sticking to the old ways. However, I totally understand what it feels like for new tools to pop up that put into question old ways I've invested a lot into. That said, don't you think you'd be better off fully exploring these ways before shooting them down? Don't tell me you have--zero people that have grokked the effectiveness of declarative state-driven programming make these remarks. They usually leave some hint at their experience with React. In short, it's only you left in the dust :)
Give the tools a try, which I know will likely be hard for you because you are likely coming from the Native world. I will say this: it's a lot more than just one language to make hybrid apps (i.e. like past tools such as Titanium). And, of course perf will be a challenge. That said, the perf is amazing given what it is. But more importantly, the style of development is what it's all about. It's so different and so much more predictable/debuggable than the old mutable ways. To me, it matters not that it's in JS. What matters is the declarative state driven way of development. If you can do that in native code, you're basically doing the most important aspect--and basically there's no argument from me there. There are some libraries that allow for that, but it's nowhere near the extent of what you can do in React/JS, given its ecosystem. I lot of work is being put in here to make this the best of breed future of application development. If you can't see it, you're missing out. Do your homework on React once and for all. You can thank me later.
Last point: Walmart's tool here is specifically meant for making apps where some of it you want in "actual native" and other parts in "react native." Without a doubt coding the React style is the best DX for UI development. AND without a doubt, "actual native" performs far FAR better. So what they have here is a toolbox for those with an "engineering mindset" to pick the best tool for the job. Everything that's happening is just getting better and better for all parties involved, no matter where your experience lies.
I’ve done both native (Mac, Windows, iOS, Android, Gtk+, Tizen) and React.
Your post comes off as condescending fanboy hype. I understand you want to promote React, but this approach does more damage than good.
My personal experience is that “declarative” in this industry is a perennial silver bullet. What often goes unnoticed is that declarative languages are not very future-proof, as extensions are constrained by the originally chosen primitives. Pathological examples are enterprise Java+XML and CSS — both of these were hailed as declarative breakthroughs originally, and today they are the stuff of “TheDailyWTF” nightmares.
Surely that will not happen to React, you say, because it gets so many things right? Well, as a thought exercise, imagine what things could be like in 2027 and then imagine you’re stuck working in a 15-year-old patched up JavaScript/HTML hybrid. That is the endgame. I like React, but it’s subject to the same market forces as every other technology in this space.
My point was that the world around will change, and at some point the declarative language that seemed so succinct will become clunky and inadequate to express the new requirements.
Java+XML really is the poster child for this. There was a time when it was the fresh declarative kid. React will most likely follow a similar path, not through any fault of its own.
Same will happen to your Swift or Android-Java codebases though. Go try to build and run on your 2015-17 machine+OS+devenv any just-slightly-real-world-beyond-hello-world run-off-the-mill 15-year old Visual Studio 6 line-of-biz (or other) codebase right now.. or whatever they used on Macs back then (I'd imagine the compatibility story for pre-OSX stuff is maybe even slightly worse than in MS land). Software that's meant to survive is meant to be maintained, I guess.
Or the server side of a web app? What's it gonna be, CGI or ASP 3 or PHP 3.. always the same story.
Bringing up HTML/JS/CSS from those days to function (though not shine) for today's requirements might prove comparatively tame by comparison =)
I can’t speak much for the rest, but old Mac codebases in particular hold up better than you might think. You can write an application that runs on every version of Mac OS from 1.0 (circa 1985) up to High Sierra with just a handful of conditionals through the use of Carbon [0]. Porting pre-OS X software should be similarly simple, given that it’s written in C or C++ (Pascal was somewhat popular for classic Mac apps, not sure what getting that code running on modern machines would look like).
When it comes to “new world” Mac stuff, the things keeping something written for OS X 10.0 from running on modern macOS have more to do with API deprecations than anything else. Objective-C is still widely used and is well supported (even with Swift’s growing popularity), so usually getting an old codebase of this nature running just means fixing a couple of deprecation errors, fixing a bunch of warnings, and hitting compile. The nature of change in the native sphere has largely been evolutionary, not revolutionary, so it’s largely stayed the same with new things being added. It’s not like the web where wheel reinvention and fads are a constant.
> Java+XML and CSS — both of these were hailed as declarative breakthroughs originally, and today they are the stuff of “TheDailyWTF” nightmares.
Java+XML isn't declarative, XSLT was. XSLT declined when XML declined. CSS works quite well even today and is still widely used.
Declarative coding style is in many ways resistant to obsolescence since you're just declaring what you want than how to do it. The best example is SQL; mostly unchanged in decades.
As far as CSS goes — ask any front-end web developer if they would like all programming to be more like CSS...? It is a collection of thousands of properties, often overlapping or contradictory, some with their own sublanguages for further specification, and many features are defined as hidden side effects of one property when nested inside another. A total mess.
You can only declare what you want if the language lets you say it. (Think of Wittgenstein’s famous maxim.) SQL was a great design informed by decades of research. Most software designs are not like that, unfortunately.
I'm a fan of declarative (eg. logic) programming but how is XSLT declarative when Java and XML isn't? XSLT has been proven Turing-complete a long time ago (eg. [1]), and if anything, is functional, being derived from DSSSL/Scheme up to the XML syntax.
> What often goes unnoticed is that declarative languages are not very future-proof [...] Surely that will not happen to React, you say, because it gets so many things right? Surely that will not happen to React, you say, because it gets so many things right?
It is often not appreciated how simple React really is. Its simplicity is actually well suited to survive a long, long time. Forget classes, lifecycles, schedulers and all this stuff for a moment. If you boil it down what you're left with is but a single signature: `createElement(name, props, chilren)`. That's what JSX transpiles into.
With that you can map pretty much every visual-oriented api on earth and as we can plainly see it goes further than that and starts rendering flat out everything that can be rendered in the same friendly manner we're used to:
It's always the simple, almost trivial ideas that seem to survive and spread. React was released 4 years ago and has kept to a stable api. 16 was a rewrite, and it's a drop in replacement.
Forget classes, lifecycles, schedulers and all this stuff for a moment. If you boil it down what you're left with is but a single signature: `createElement(name, props, chilren)`.
When you pare it down to that, you're merely saying that GUIs are trees of configured objects. It's not a great revelation because the very first production GUI (Smalltalk 1972) already worked like that.
To get React from that idea, you need to add back all the stuff that you left out in the previous sentence. You add JavaScript, HTML-like syntax for defining trees and object attributes, component lifecycles and all that. And then it's not a generic idea anymore but a fairly specific implementation that will be superseded by something else eventually.
Declarative way of thinking is closer to how humans think while imperative code is closer to how machine works. That is why declarative way is objectively better and more predictable to model human behaviors, not necessarily the more efficient for machines.
Performance will improve due to Moore's law and optimizations.
The big picture is with more and more companies open source their technologies, software development is becoming a more and more social activity and Darwinian.
The mindshare winners are the survivors in technology (and talent) market.
> while imperative code is closer to how machine works
somewhat. less so these days than say back in the 8086 era.
cpu's these days do all kinds of wild stuff, with their long pipelines, staged execution, executing multiple instructions simultaneously, and other interesting behavior.
combine that with smarter compilers that can transform code in various ways to capitalize upon cpu developments, and you might be slightly surprised how some ostensibly boring and linear imperative code actually behaves on a present day cpu.
I already did give these tools a try and first rat out of the trap the sample code generated by React Native had build errors in production XCode8. I will confess that it did confirm my bias against bringing in any 3rd party dependency at all unless there is absolutely no choice in the matter and it also confirmed my practice of structuring my code so that any dependencies I'm forced to bring into a project (either by time crunch or clueless management) can be removed as soon as possible.
Also, coding in the React style is the "best DX for UI development" mainly if you're a web developer who doesn't want to learn the platform or the native tools but still wants to have "mobile developer" on your resume. (IMO)
I never coded native apps so forget my ignorance but how would you build an UI declaratively with swift? The turorial shows very imperative/mutative code indeed:
No need to apologize for asking an honest question :)
By combining a good databinding framework and reactive extension
so Bond & RxSwift or DataBinding (from google) & RxJava (or RxKotlin if/when it becomes a thing).
Of course, behind the scenes, this accesses the platform widgets in an imperative way (but that's also what RN has to do when it manipulates the same widgets). What matters is the API surface you interact with.
It's this assumption that "same experience on all platforms" (aka "branding") is desirable to "native experience on all platforms".
Facebook wants facebook to feel like facebook whether you're on an iPhone or an Android or your PC. Same with Chrome - it eschews native platform UI on all devices in favor of looking the same everywhere.
Good UI - by definition - doesn't get in your way. But "good UI" may not be "good marketing" or "good branding" and these companies are placing a premium on their brand at the cost of the user experience.
Good apps should _embrace_ rather than eschew the platforms they run on and their windowing toolkits so that their users can focus on the content rather than the presentation.
Think about it - how many people (as a percentage of users of an app) will use it on multiple platforms? (Windows and Mac or iPhone and Android?) How many people use facebook _both_ in the mobile browser _and_ via the app on the same device? (Especially given the obnoxious trend to block access to the website if a native app is available cough reddit cough pinterest cough messenger cough). Not many at all.
Hubris also comes into play. Obviously the UI models used in xxx platform are not perfect, but every app designer thinks "users will prefer this over xxxx's default, no question about it" because they view their layout/navigation/ui/style to be the greatest thing since sliced bread and cannot fathom that users might actually prefer the device's native windowing/widget toolkits to their abomination.
I use OS X (laptop), Windows (VM), Android (phone), and iOS (iPad). It's not at all unusual for me to have apps installed on at least three of those platforms, and I really appreciate it when the UI is the same across platforms.
> But "good UI" may not be "good marketing" or "good branding" and these companies are placing a premium on their brand at the cost of the user experience.
it's unclear where 'at the cost of the user experience' comes in.
you say that good ui "doesn't get in the way", and later that platform windowing toolkits should be used to avoid distraction. this seems to suggest that platform toolkits are "good ui".
aside from branding, one driving force for cross-platform ui is that some don't agree with the premise of platform uis being "good ui".
> Think about it - how many people (as a percentage of users of an app) will use it on multiple platforms?
depending on the region, i'd wager a lot, actually.
> Hubris also comes into play. Obviously the UI models used in xxx platform are not perfect, but every app designer thinks "users will prefer this over xxxx's default, no question about it" (...)
do any compare various options and using their reason, experience and advice, and then conclude a particular choice is preferable because of it's properties and characteristics?
> (...) because they view their layout/navigation/ui/style to be the greatest thing since sliced bread and cannot fathom that users might actually prefer the device's native windowing/widget toolkits to their abomination.
how many people are we talking about?
truly it is terrible for the fascist designer to impose their design abomination upon the beleaguered users.
...but what about the liberated users no longer under the savage yoke of the gross and repellent 'native widget toolkit'?
More than once I have encountered product people looking at the app on iOS in one hand & Android in the other and explaining that they should be the same.
99.9% of the time, normal users don't do that. What they do is switching from one app of the OS they are using to yours.
Using the same idioms as other apps of the OS is more useful because this is what users will have been trained to use.
Apple fans like to see apple UI guidelines followed on Apple devices, and Android fans like to see Android design guidelines followed on Android, but the normal non-technical users who don't really care expect facebook to work the same way on their android phone and their iPad and their work computer. People don't want to have to re-learn how to use the wal-mart app after their grandson convinces them to give up their old Galaxy S3 and buy the new iPhone. Expecting all apps to obey the platform guidelines is just as much hubris as ignoring the platform guidelines is.
Likely Walmart feels this costs them less in the long run. The goal here is not to develop the highest quality software possible, it's to engage and capture customers as quickly and cheaply as possible, and to keep the cost of maintaining, updating and deploying that code as low as possible.
it's interesting to see the react-native detractors in this thread vs an Ask HN thread we had about react-native a couple of weeks ago. I wonder how many people could really determine an app's usage of RN in a blind taste test. could the disdain for js the language and bad memories of wrapped webviews be bleeding over? in our experience RN has offered a ton of leverage for a small team, and js makes a fine target to transpile to (we use cljs).
From the testing we've done internally, not much difference between React Native, Xamarin, Native and Cordova. Was it scientific? Nope. But most couldn't tell.
We are in the process of rebuilding our app in react native. As a test, we created a portion of it in react native and did a side by side.
Our app is your basic slide out navigation with pages and forms and some animation. There is literally no detectable difference.
The only thing that I am still not sure of is performance on older devices. But on iPhone 6 and Galaxy S7... I wish we had started with react native from the beginning.
46 comments
[ 2.4 ms ] story [ 106 ms ] thread1: https://github.com/walmartlabs/lacinia
The Trips tab in the app (itinerary) was actually rewritten in native after originally being implemented using RN.
It’s really too bad that people have this perception of RN’s use at Airbnb. I feel like people assume the whole thing is RN, which couldn’t be more wrong.
Now that said, I agree on the performance costs, and too wonder why Walmart is hellbent on this strategy, given the endless resources they have.
But at the end of the day, they have a head of engineering and need to make their lives simpler just like everyone else. If you know how to squeeze the performance out of RN/React, developing apps in the semi-FP declarative sate-driven way is a dream compared to all the old ways of client app development. People who's views are so against React/ReactNative usually haven't experienced it for themselves. I suggest really giving it try before making these comments which usually serve just to validate decisions already made. I.e. to make one's self feel better about sticking to the old ways. However, I totally understand what it feels like for new tools to pop up that put into question old ways I've invested a lot into. That said, don't you think you'd be better off fully exploring these ways before shooting them down? Don't tell me you have--zero people that have grokked the effectiveness of declarative state-driven programming make these remarks. They usually leave some hint at their experience with React. In short, it's only you left in the dust :)
Give the tools a try, which I know will likely be hard for you because you are likely coming from the Native world. I will say this: it's a lot more than just one language to make hybrid apps (i.e. like past tools such as Titanium). And, of course perf will be a challenge. That said, the perf is amazing given what it is. But more importantly, the style of development is what it's all about. It's so different and so much more predictable/debuggable than the old mutable ways. To me, it matters not that it's in JS. What matters is the declarative state driven way of development. If you can do that in native code, you're basically doing the most important aspect--and basically there's no argument from me there. There are some libraries that allow for that, but it's nowhere near the extent of what you can do in React/JS, given its ecosystem. I lot of work is being put in here to make this the best of breed future of application development. If you can't see it, you're missing out. Do your homework on React once and for all. You can thank me later.
Last point: Walmart's tool here is specifically meant for making apps where some of it you want in "actual native" and other parts in "react native." Without a doubt coding the React style is the best DX for UI development. AND without a doubt, "actual native" performs far FAR better. So what they have here is a toolbox for those with an "engineering mindset" to pick the best tool for the job. Everything that's happening is just getting better and better for all parties involved, no matter where your experience lies.
Your post comes off as condescending fanboy hype. I understand you want to promote React, but this approach does more damage than good.
My personal experience is that “declarative” in this industry is a perennial silver bullet. What often goes unnoticed is that declarative languages are not very future-proof, as extensions are constrained by the originally chosen primitives. Pathological examples are enterprise Java+XML and CSS — both of these were hailed as declarative breakthroughs originally, and today they are the stuff of “TheDailyWTF” nightmares.
Surely that will not happen to React, you say, because it gets so many things right? Well, as a thought exercise, imagine what things could be like in 2027 and then imagine you’re stuck working in a 15-year-old patched up JavaScript/HTML hybrid. That is the endgame. I like React, but it’s subject to the same market forces as every other technology in this space.
That should be quite a powerful language by then, if it's not already.
Java+XML really is the poster child for this. There was a time when it was the fresh declarative kid. React will most likely follow a similar path, not through any fault of its own.
Same will happen to your Swift or Android-Java codebases though. Go try to build and run on your 2015-17 machine+OS+devenv any just-slightly-real-world-beyond-hello-world run-off-the-mill 15-year old Visual Studio 6 line-of-biz (or other) codebase right now.. or whatever they used on Macs back then (I'd imagine the compatibility story for pre-OSX stuff is maybe even slightly worse than in MS land). Software that's meant to survive is meant to be maintained, I guess.
Or the server side of a web app? What's it gonna be, CGI or ASP 3 or PHP 3.. always the same story.
Bringing up HTML/JS/CSS from those days to function (though not shine) for today's requirements might prove comparatively tame by comparison =)
When it comes to “new world” Mac stuff, the things keeping something written for OS X 10.0 from running on modern macOS have more to do with API deprecations than anything else. Objective-C is still widely used and is well supported (even with Swift’s growing popularity), so usually getting an old codebase of this nature running just means fixing a couple of deprecation errors, fixing a bunch of warnings, and hitting compile. The nature of change in the native sphere has largely been evolutionary, not revolutionary, so it’s largely stayed the same with new things being added. It’s not like the web where wheel reinvention and fads are a constant.
[0] http://blog.steventroughtonsmith.com/post/109040361205/mpw-c...
Java+XML isn't declarative, XSLT was. XSLT declined when XML declined. CSS works quite well even today and is still widely used.
Declarative coding style is in many ways resistant to obsolescence since you're just declaring what you want than how to do it. The best example is SQL; mostly unchanged in decades.
As far as CSS goes — ask any front-end web developer if they would like all programming to be more like CSS...? It is a collection of thousands of properties, often overlapping or contradictory, some with their own sublanguages for further specification, and many features are defined as hidden side effects of one property when nested inside another. A total mess.
You can only declare what you want if the language lets you say it. (Think of Wittgenstein’s famous maxim.) SQL was a great design informed by decades of research. Most software designs are not like that, unfortunately.
[1]: http://conferences.idealliance.org/extreme/html/2004/Kepser0...).
It is often not appreciated how simple React really is. Its simplicity is actually well suited to survive a long, long time. Forget classes, lifecycles, schedulers and all this stuff for a moment. If you boil it down what you're left with is but a single signature: `createElement(name, props, chilren)`. That's what JSX transpiles into.
With that you can map pretty much every visual-oriented api on earth and as we can plainly see it goes further than that and starts rendering flat out everything that can be rendered in the same friendly manner we're used to:
shell consoles: https://github.com/Yomguithereal/react-blessed
word: https://github.com/nitin42/redocx
pdf: https://github.com/diegomura/react-pdf
samplers: https://twitter.com/GabeRicard/status/911989894267973633
mobile: https://facebook.github.io/react-native/
3d: https://github.com/Izzimach/react-three
windows: https://github.com/Microsoft/react-native-windows
macos: https://github.com/ptmt/react-native-macos
sketchapp: http://airbnb.io/react-sketchapp/
keynote: https://twitter.com/nishb1/status/913744410537537536
VR: https://facebook.github.io/react-vr/
hardware: https://github.com/iamdustan/react-hardware
What's even crazier is that everyday eco-system packages can be applied to the wildest targets. For instance animations via react-motion on shell consoles: https://github.com/gaearon/react-blessed-hot-motion or react-router on VR: https://youtu.be/Mf0Fy8iHp8k?t=12m25s
It's always the simple, almost trivial ideas that seem to survive and spread. React was released 4 years ago and has kept to a stable api. 16 was a rewrite, and it's a drop in replacement.
When you pare it down to that, you're merely saying that GUIs are trees of configured objects. It's not a great revelation because the very first production GUI (Smalltalk 1972) already worked like that.
To get React from that idea, you need to add back all the stuff that you left out in the previous sentence. You add JavaScript, HTML-like syntax for defining trees and object attributes, component lifecycles and all that. And then it's not a generic idea anymore but a fairly specific implementation that will be superseded by something else eventually.
Performance will improve due to Moore's law and optimizations.
The big picture is with more and more companies open source their technologies, software development is becoming a more and more social activity and Darwinian.
The mindshare winners are the survivors in technology (and talent) market.
somewhat. less so these days than say back in the 8086 era.
cpu's these days do all kinds of wild stuff, with their long pipelines, staged execution, executing multiple instructions simultaneously, and other interesting behavior.
combine that with smarter compilers that can transform code in various ways to capitalize upon cpu developments, and you might be slightly surprised how some ostensibly boring and linear imperative code actually behaves on a present day cpu.
how has this anything to do with RN ?
You can write declarative codebases in swift or kotlin, no need for RN to achieve this.
@IBAction func setDefaultLabelText(_ sender: UIButton) { mealNameLabel.text = "Default Text" }
By combining a good databinding framework and reactive extension
so Bond & RxSwift or DataBinding (from google) & RxJava (or RxKotlin if/when it becomes a thing).
Of course, behind the scenes, this accesses the platform widgets in an imperative way (but that's also what RN has to do when it manipulates the same widgets). What matters is the API surface you interact with.
Facebook wants facebook to feel like facebook whether you're on an iPhone or an Android or your PC. Same with Chrome - it eschews native platform UI on all devices in favor of looking the same everywhere.
Good UI - by definition - doesn't get in your way. But "good UI" may not be "good marketing" or "good branding" and these companies are placing a premium on their brand at the cost of the user experience.
Good apps should _embrace_ rather than eschew the platforms they run on and their windowing toolkits so that their users can focus on the content rather than the presentation.
Think about it - how many people (as a percentage of users of an app) will use it on multiple platforms? (Windows and Mac or iPhone and Android?) How many people use facebook _both_ in the mobile browser _and_ via the app on the same device? (Especially given the obnoxious trend to block access to the website if a native app is available cough reddit cough pinterest cough messenger cough). Not many at all.
Hubris also comes into play. Obviously the UI models used in xxx platform are not perfect, but every app designer thinks "users will prefer this over xxxx's default, no question about it" because they view their layout/navigation/ui/style to be the greatest thing since sliced bread and cannot fathom that users might actually prefer the device's native windowing/widget toolkits to their abomination.
it's unclear where 'at the cost of the user experience' comes in.
you say that good ui "doesn't get in the way", and later that platform windowing toolkits should be used to avoid distraction. this seems to suggest that platform toolkits are "good ui".
aside from branding, one driving force for cross-platform ui is that some don't agree with the premise of platform uis being "good ui".
> Think about it - how many people (as a percentage of users of an app) will use it on multiple platforms?
depending on the region, i'd wager a lot, actually.
> Hubris also comes into play. Obviously the UI models used in xxx platform are not perfect, but every app designer thinks "users will prefer this over xxxx's default, no question about it" (...)
do any compare various options and using their reason, experience and advice, and then conclude a particular choice is preferable because of it's properties and characteristics?
> (...) because they view their layout/navigation/ui/style to be the greatest thing since sliced bread and cannot fathom that users might actually prefer the device's native windowing/widget toolkits to their abomination.
how many people are we talking about?
truly it is terrible for the fascist designer to impose their design abomination upon the beleaguered users.
...but what about the liberated users no longer under the savage yoke of the gross and repellent 'native widget toolkit'?
More than once I have encountered product people looking at the app on iOS in one hand & Android in the other and explaining that they should be the same.
99.9% of the time, normal users don't do that. What they do is switching from one app of the OS they are using to yours.
Using the same idioms as other apps of the OS is more useful because this is what users will have been trained to use.
Apple fans like to see apple UI guidelines followed on Apple devices, and Android fans like to see Android design guidelines followed on Android, but the normal non-technical users who don't really care expect facebook to work the same way on their android phone and their iPad and their work computer. People don't want to have to re-learn how to use the wal-mart app after their grandson convinces them to give up their old Galaxy S3 and buy the new iPhone. Expecting all apps to obey the platform guidelines is just as much hubris as ignoring the platform guidelines is.
Why "integrate" React into a native app? So you can just have a native shell of sorts, with the business logic written in React so it's portable?
Jet.com is a NY based startup. They use F#.
They have quite separate code bases, and as far as I can tell no plans to merge them.
Walmart acquired the online retailer, Jet.com in late 2016 which still has their own engineering team (using a lot of F#)
Stuff coming from @WalmartLabs is almost always real stuff that Walmart is using in production (website, apps, etc.)
[1] https://en.wikipedia.org/wiki/@WalmartLabs
Our app is your basic slide out navigation with pages and forms and some animation. There is literally no detectable difference.
The only thing that I am still not sure of is performance on older devices. But on iPhone 6 and Galaxy S7... I wish we had started with react native from the beginning.