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.
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.
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.
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.
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...).
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...
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.
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.
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.
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.