React Native at Airbnb
medium.com
medium.com
Wow, I can't imagine how frustrating this must have been to debug.
Close debugging? It broke again.
Maddening.
That has to be the strangest combination of terms I've seen this month.
What was your point again?
It turned out that in that version of IE, the console object only existed when the devtools were open. So a stray console.log call was causing an exception because console was undefined. But when I opened the devtools to see what was going on, console existed and so everything ran just fine.
I suppose that's the kind of error that only bites you once. When you know about it, you tend to never make that mistake again. But that first time you run into it can cause a painful few hours of head scratching and attempted debugging.
Funnily enough, I ran into a React Native error like the one described in the article, where something worked only while debugging. My previous experience with the heisenbug in IE led me to immediately dig into what was different in RN with the devtools open vs without them. So in a way, those hours I wasted in IE back in 2010 prevented me from potentially wasting hours debugging RN in 2017.
In older Android versions, warnings in modern versions actually crash React Native apps. Can be very frustrating.
Flashbacks commencing.
gRPC is just a modern SOAP. There, I said it.
I might have been lucky, though. Every time I had to use SOAP, it was just a matter of auto generating a client interface in whatever language I happened to be working in and then proceeding from there. I suppose not everyone was so fortunate.
The monstrous flexibility of xml and soap meant that in practice every soap server interface I had to consume had some quirk or incompatibility with the client I was trying to use.
The worst offender was security extensions.
In this case I had some kind of progress bar that was updated while a report is being generated. When the report is completely generated, the progress bar is replaced by a button.
Except in IE11. At some point the progress bar stopped updating and it never turned into a button. Until you opened the developer tools and IE11 "flushes" the DOM and paints the new situation. So, never having found the cause, we recommended that (internal) customer to use F12 regularly on that page.
(or vice versa? i forget)
It really shows how hard it is for RN to work cross platform. Each abstraction layer can bring in some new problems.
How long did it take for the Aha! moment?
I ended up pairing with another developer, who rewrote the test from scratch and didn't have the issue. I think I know what the problem was, though - the test code called the route in question on one line, then the next line retrieved an object that was modified during the request. The line after that asserted that an attribute of that object had been changed. Most of the time, it hadn't changed; sometimes it had. To make matters work, any time the file was modified it seemed to work once or twice then begin failing again.
I'm 99% sure what was happening is that by the time the object retrieval happened in the test code, PostgreSQL hadn't fully committed the changes to the DB that were made during the request and the object returned was unmodified. Why was that happening? No idea. I suspect it was something to do with connection pooling or the way we were using gevent monkeypatching elsewhere, even though the tests themselves weren't using gevent.
Things like this are both the most frustrating and most fulfilling part of development :)
Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools...
But business always wants the Ferrari solution at the cost of a Fiat panda.
[0] - http://bit.ly/buymyapp
For the iOS and Android side, that's a constant between the two possibilities.
It's better because now your iOS and Android experts can concentrate much more on what they do best and your React experts can keep working on your UI like they always did.
Isn’t that the promise of computers and technology? What would you suggest that business want?
The plot twist with software is that the overall cost (including running costs) of buying the ferarri is often lower than the cost of the Fiat panda.
Also don't underestimate a possibility to update app without those pesky moderators. It's awesome, push button and all users are updated.
Works across both platforms, does not require additional SDKs and has all the debugging tools and API available without any additional FFI work.
In my opinion, 2 of the reasons Airbnb had more and more issues with React Native are:
1. They don’t adopt type checking for JavaScript.
“We explored adopting flow but cryptic error messages led to a frustrating developer experience. We also explored TypeScript but integrating it into our existing infrastructure such as babel and metro bundler proved to be problematic.”
“A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.”
This is absolutely not just "a side-effect". In a real project, many developers modify the same code base, and the interfaces (Classes, function paramenters, props, etc) are changed frequently. I think type checking system, e.g. Flow, is a must for writing JavaScript code for either backend or frontend. My team is using Flow, and I ask my team members to adopt type checking as much as possible. When I see something like this funcA(a, b), I always ask the developer to change it to funcA(a: TypeA, b: TypeB): TypeC. It is really very helpful, especailly when we need to change code.
2. They don’t ask engineers to keep most code in JavaScript.
“Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable which can lead to unideal code.”
All logic and UI should be written in JavaScript. Native code should only be used when we cannot do in JavaScript or the performance is very bad.
When I am using React Native, I do miss the simplicity of writing and debugging native code. But when you need to support both iOS and Android, it's great to just keep one code base in JavaScript. Again, espeically when you need to change the code frequently, you don't need to do the some thing twice. (One for iOS, the other for Android.)
It took me 5 minutes to find a map view the other day because they've buried it so much and floated their "experiences" stuff up top.
That is no minimalism in my hand book
When searching for a listing, finding the map should be easy.
On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire.
I guess people don't scale well.
These teams are probably constantly testing and iterating the final design based on user research and testing.
At least that was my experience working at Facebook on their iOS app.
Please note that this isn't a "I could build twitter in a weekend, why do they even have so many people" comment. I am not privy to the scope of work inside of AirBnB and can't really comment whether a large amount of inefficiency exists - but if it does, perhaps this is a plausible explanation as to how that can be.
For an earlier stage company some mental gymnastics can justify the statement that in the event the startup doesn't become a unicorn 100 engineers are still "worth $100m" to big corporate buyers as a sort of big acquihire. This provides a hedge against failure.
It also provides arguably necessary redundancy during a volatile growth stage. A higher bus factor if you will. https://en.wikipedia.org/wiki/Bus_factor
And so a slightly inflated head count early on based on the above principals ensures that bureaucracy, having reached critical mass, keeps on expanding.
At the present point, there's no plausible scenario for 100 to be reduced to 25 when the company is growing and doing well.
If AirBnB suffers a calamity and its network effects somehow start disintegrating, holding on to these people could ultimately increase the sale price - the brand would have suffered, the apartment inventory is reduced, but you're still left with IP and engineers to hawk.
In the event there are no buyers you could significantly stretch out the runway by multiple rounds of layoffs from this group, claim a successful turn around with the fat trimmed, and raise a new round of financing.
However, a simple 80kloc system (simple as in no critical safety requirements, very complex algorithms or heavy regulation) is perfectly manageable for a four person team.
A lot of that head count is likely required because they need a large number of employees to attract investment, because scaling start ups are bad at processes (resulting in inefficiencies) and possibly because early employees want to move up the ladder, so they need someone to manage.
It sounds like in total they have nearly 1m lines and 800 "screens". Between 100 devs that sounds about right.
For comparison, Uber have 400 devs working on 3m lines across iOS and Android.
I just don't understand where they must be spending their time for an application of that size / complexity.
- 1 dev, 9 months project, 16k LoC excluding comments, including UT.
- 16 devs, 2 years project, 200k LoC excluding comments, including UT.
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.
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.
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.
I hope RN is going to stop relying on beta code for releases too.
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.
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.
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.
Thanks for the additional insight here.
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.
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 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..)
For sharing presentation, I'm hopeful for solutions like react-native-web.
I have successfully used this approach to develop applications for both Android and iOS.
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.
Interesting to see even Airbnb struggles with Redux
That's just one example, but I generally spent a ton of time writing complex shouldComponentUpdate functions and therefore making lots of mistakes with Redux. I've found MobX much more suited to building complex UIs with deep hierarchies and tens to hundreds of total elements on the screen at once, where updating only exactly when necessary is critical.
I use MobX for my game Falcross, which I wrote about in the State of React Native 2018 thread from a few days ago: https://news.ycombinator.com/item?id=17316877
I initially used Redux, and I found it actually technically impossible to get the game to perform well using Redux. I tried everything.
One of the keys to good Redux performance is to connect more components, and have each component only extract a small piece of the state [0]. Using memoized selector functions also helps in most situations [1].
FWIW, there was a really good discussion on the relative strengths and weaknesses of Redux and MobX in regards to performance a while back [2].
[0] https://blog.isquaredsoftware.com/2017/01/practical-redux-pa...
[1] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...
[2] https://www.reddit.com/r/reactjs/comments/5hf4d4/an_artifici... (see the linked article, the Reddit comments, and the links in the comments).
I think, a number of challenges that Redux and MobX are intended to address, can potentially be resolved in more elegant and easy manner with the new (16.3.1 and above) Context APIs. ReactNative 55.+ works with 16.3.x and 16.4.0 so these APIs are available to your react native apps now.
For example making available global stores to all the components that need them, being able to invoke 'render' on the interested components, when a particular store is being updated -- all of that is being supported. All that without passing the store as property through the hierarchy depth.
for the cases where your component relation is 'horizontal', rather than hierarchical. I recommend simply to use pubsub.js. It is a library that has 0 dependencies (rarity in JavaScript ecosystem :-) ). and has both Sync and Async publishing via channels. So that you can pause your publishing to the horizontally-connected components, if you need to, and then resume -- when the publishing is done.
(I'll throw out my obligatory comment that you are always welcome to use as much or as little abstraction as you want on top of Redux, and there's plenty of options available to trim down "boilerplate" depending on your situation.)
For example, we specifically have a "Reducing Boilerplate" docs page [0] that talks about writing reusable logic for reducers and action creators, like "higher order reducers" or a `createReducer()` util that accepts a lookup table of action types to handler functions. There's many existing libs that implement this kind of pattern [1].
Beyond that, there's other libraries that provide a higher level of abstraction, like automatically generating logic to handle common use cases (normalizing data, updating certain fields, etc) [2].
Updating data immutably can become complex [3], so there's a lot of immutable update utility libraries out there [4]. I recommend Immer [5], which lets you write normal mutative code but then applies the updates immutably.
Finally, there's frameworks built on top of Redux, like Kea and Rematch [6].
So, plenty of options available, depending on what you're comfortable with.
[0] https://redux.js.org/recipes/reducing-boilerplate
[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[2] https://github.com/TheComfyChair/redux-scc , https://github.com/Bloomca/redux-tiles
[3] https://redux.js.org/recipes/structuring-reducers/immutable-...
[4] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[5] https://github.com/mweststrate/immer
[6] https://github.com/keajs/kea , https://github.com/rematch/rematch
Just saying "well you don't need to use it" means that Redux maintains all that crust and cruft of boilerplate which remains a huge cognitive impact not only on beginners but also possibly experienced Redux users.
Redux is magnificent, but it should take a lesson from create-react-app which did the job of getting rid of all the crap that webpack and babel disastrously imposed on all JavaScript developers with their "maximum config" approach as opposed to zero config.
The message to JavaScript library and tools developers is "get rid of your config or some other tool will come along and do it for you". Redux's boilerplate is just config. If you apply every brain cell you have to the task of getting rid of boilerplate, what would Redux be left with? That's what it should be.
I think the success of VueJS can be laid squarely at the feet of the complexity of the ReactJS ecosystem - not even necessarily React itself. Every part of the larger React ecosystem needs to reduce the cognitive load it imposes and the primary task there is getting rid of configuration/boilerplate.
My theory is that "all software that CAN BE more simple is replaced by some other good enough solution that IS more simple". Thus VueJS, which whilst I wouldn't use it, is certainly simpler for beginners to grasp.
So, legit question: what do _you_ mean by that term? Use of actions? Action creators? `connect()`? Immutable update logic in a reducer? Store setup?
I honestly get frustrated that people keep throwing around that term, but few people seem to point to a specific _thing_ that can be improved. (People also don't seem to understand the context that Redux came from and the intent behind its original design, something that I tried to capture in an extended blog post a while back [0]).
Early last year, I filed an issue asking for discussion of ways we can improve the learning / getting started experience, and resolve some of these "boilerplate" complaints [1]. There were a bunch of comments and some decent ideas, but I already have a lot on my plate, and no one from the community really stepped up to help push any of the ideas forward.
I do have a small "redux-starter-kit" lib [2] prototype that I've put together as a tool that can help simplify the store setup process and reducer logic. Again, though, I haven't had time to do much more with it myself since I first threw it together.
I am _always_ open to legit suggestions on ways we can improve the docs or find ways to make using Redux easier. Unfortunately, it seems like very few people are interested in actually getting in touch with us and offering assistance in doing so.
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
Here is a class:
import React from 'react'
export default class class ChooseFontLevel1 extends React.Component {
constructor(props) {
super(props)
}
render = () => <span>foo</span>
}
import React from 'react'
import {connect} from 'react-redux'
class ChooseFontLevel1 extends React.Component {
constructor(props) {
super(props)
}
render = () => <span>foo</span>
}
function mapStateToProps(store, ownProps) {
return {
fontPreviewsCache: get(store, `fontPreviewsCache`),
}
}
function mapDispatchToProps(dispatch) {
return {
onTodoClick: id => {
dispatch(toggleTodo(id))
}
}
}
export default connect(mapStateToProps, mapDispatchToProps)(ChooseFontLevel1)
And if the comment is "You don't need all that stuff", then why is it an option at all?
Also mapStateToProps is poorly named and confusing because it isn't talking about anything to do with ReactJS component state, although it's a reasonable assumption, it's talking about the Redux state... there's a bag of confusion for you and enough to make a beginners head spin because their head was already spinning about what ReactJS state is.
I'd also suggest that Redux has made a rod for its own back by calling "the thing that gets data out" as "reducers", instead of something like "getters". "Reducers".... argh we're now in computer science land and not the land of the practical programmer. A reducer, what is that? Beginners certainly don't know and you have to learn and become experienced with Redux to come to understand that in fact a Reducer is
Equally, cognitive load would have been reduced if actions were named "setters" or something familiar and similar to the actual functionality.
Redux itself isn't that hard once you understand it, but it's put up big cognitive barriers around itself so that you need to be an expert to eventually discover that you don;t need to be an expert.
const actions = {onTodoClick : toggleTodo};
export default connect(mapState, actions)(ChooseFontLevel1);
Is that truly too much to write? Also, how does that qualify as "entirely restructuring your code"? Your component is still the same - it's getting data as props. It's just now getting them from a component that was generated by `connect`.
The alternative is to write the store subscription code yourself, by hand, in every component that needs to access the store. I've got some slides at https://blog.isquaredsoftware.com/presentations/workshops/re... that show what that would look like, and THAT would truly become tedious and painful.
The point of `connect` is to abstract out the process of subscribing to the store, extracting the data your component needs, and only re-rendering your real component when that data changes.
As for the naming of `mapState`: the word "state", in general, means "data that represents what's going on in my application". So, there's the generic aspect of "state", there's "state that is being stored in my React component", and there's "state that is being kept inside my Redux store". Those are all valid uses of the word "state" (and especially given that the Redux core is entirely independent of React).
The term "action" comes from its original design as an implementation of the Flux architecture (which is part of my point of people not being familiar with where it came from). "Reducers" comes from the `someArray.reduce()` method.
(Also, note that in both of your examples, the constructor isn't actually needed because you're not doing anything meaningful in there, and your `mapState` example isn't making use of the `ownProps` argument and therefore shouldn't declare it for performance reasons.)
What is simple for any Redux-experienced person is a gigantic cognitive cliff for people who are not experts. I can still remember trying to learn ReactJS and Redux and bailing out on Redux while I tried to make sense of mapping dispatch to props. Redux should not be losing users at that point.
Your earlier post expressed frustration at not being able to get people to be specific about what boilerplate is.... well this is it (or my definition anyway).
IMO, ideally Redux would be nothing more than an object that I instantiate and then call methods and properties on - including defining my reducers and actions. A single object for Redux leaves the question of how to ensure that changes to the Redux store result in a props refresh being pushed down through the component hierarchy, but surely the big brains on the ReactJS project can come up with some other way to handle that behind the scenes rather than me needing to change my code structure.
And may I say I love your work and I'm a big fan of Redux!
Although if I found something that operated like I say - a single object to be instantiated and driven via methods and properties with total immutability, with changes resulting in a props refresh on update, then I'd switch.
Not quite sure what that "single object" sentence is trying to say, but that also sorta sounds like MobX's wrapping up of components with `observe()` (which ultimately does the same kind of thing `connect` is doing, just in a rather different way).
(Also, fwiw, Redux is completely separate from the React team. Dan Abramov and Andrew Clark, the creators of Redux, _do_ work on React at Facebook now, but Redux is not a Facebook project, and Dan and Andrew are no longer active maintainers. We talk with them a lot, and they obviously have a vested interest in Redux, but it's separate.)
And thanks, appreciate the compliment.
...which is ironic, considering the fact that Dan Abramov (co-)created them both.
The main point of Redux is to make your state updates predictable and traceable throughout the codebase.
Sure, you can create a global object and stuff your data in there. But, if any random part of the app is allowed to modify that object at any time, then it's a lot harder to understand how your app got into a particular end situation.
Redux is based on the "Flux Architecture" concept, and asks you to follow restrictions on how you structure your logic. Only certain functions are allowed to update the state, and in order to run that logic, you create plain JS objects called "actions" that describe some event or update that needs to occur, and ask the update logic to determine the new state values in response.
This adds a level of indirection to your code, but it provides a way to log and trace when, where, why, and how a given piece of state got updated.
If you've got about 45 minutes, I did a "Redux Fundamentals" presentation at Reactathon a few months ago that walks through the basic principles of Redux. Here's a link to the video and the slides:
https://blog.isquaredsoftware.com/2018/03/presentation-react...
Redux definitely has too much boilerplate, but it does an excellent job of keeping functionality decoupled, and on a big project this ends up being way more important. When you do it right, you rarely introduce regressions when working on new features, because almost everything you do is additive: you're adding new state, new actions, new selectors, new sagas, etc., without touching any pre-existing functionality or anything that pre-existing functionality depends on.
The alternative is playing an endless game of whack-a-mole as an app gets too large for anyone to keep track of what depends on what.
An alternative is another state management library.
I imagine their thought process went like this:
Types: People like strongly typed languages, maybe if we call our events "types", they will like Redux more?
Reducers: Switch statements are so boring and uncool. Lets call this "reducer" instead of "events switch statement".
Store: Lets call the state tree "store". The term "State tree" is too explicit and a core principle of Redux is misdirection.
Actions: Mere mortals will associate the term "action" with functions and procedures, but Redux is not for mortals. "Action" will be our term for payload.
https://facebook.github.io/flux/docs/in-depth-overview.html#...
I covered a lot of the history and thought behind Redux's design in my post "The Tao of Redux, Part 1: Implementation and Intent" [0] .
Sure, I'd agree that the terms are a lot to take in for a new learner, but claiming these were chosen or made up to make things more confusing is ridiculous. There was a lot of debate over exactly what terms to use during the development process [1] [2] [3], and it was ultimately decided that keeping the Flux-based terminology made the most sense at the time, because most people coming to Redux were familiar with Flux already. Obviously the dev landscape has changed since then, since nobody seems to remember that the original Flux concept existed, but the terms are now set in stone because we've been using them since the beginning.
[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[1] "reducers": https://github.com/reduxjs/redux/issues/137
[2] "state", "store", "dispatch" : https://github.com/reduxjs/redux/issues/113 , https://github.com/reduxjs/redux/issues/137
[3] "actions" vs "events": https://github.com/reduxjs/redux/issues/384 , https://github.com/reduxjs/redux/issues/377 , https://github.com/reduxjs/redux/issues/891
The "store" is the object returned from `createStore()`, which has the `dispatch`, `getState`, and `subscribe` methods.
The store object contains your "state" value, which could be a simple number by itself, an array, an object, or whatever else you return.
Typically that top level value _is_ an object with other values nested inside of it, and _that_ is your "state tree". So, the "store" contains the "state tree", and they are not the same thing.
I mean even the creator of Redux says you probably don't need to use it or if you do not all of it. It's overly complex for what it is meant to do, IMO. I had issues figuring it out initially and now if I don't touch it for a few months I feel like I have to re-learn how parts of it work because I forget and it doesn't feel intuitive to me.
The Elm architecture is so simple you could write the API on a business card, and it fundamentally does the same thing, and solves the same problem. There's almost no accidental complexity, only essential complexity.
Redux on the other hand feels like there's so much accidental complexity, but it's not even obvious, it's masquerading as essential complexity.
Buried lede. Why not just say it outright?
Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though.
It would be interesting to know why some of the infra layers that the article mentions (i18n, networking) were behind bridge when they seem like prime candidates for js implementation.
What I'd really like to know though is how other teams are managing the design pipeline (getting from psd/sketchapp to code without hand coding flexbox styles). We've looked at some tools like supernova.studio and BuilderX, and while showing promise these seem like they have a long road ahead.
I also noticed Framer announced an upcoming tool 'Framer X' with React support -- not sure if that includes RN either.
pretty early still, but the idea is that short-term it generates assets that fit into our existing Figma / Sketch product design workflows for consumption. having a cross-platform source of truth for _components_ is higher impact than outputting their _consumption_. this was mostly the reason we first did the things we wrote about here - they laid the groundwork for Lona and a more component-centric design process. https://airbnb.design/painting-with-code/ https://airbnb.design/sketching-interfaces/ https://airbnb.design/the-evolution-of-tools/
A couple of days after I posted that I started thinking about whether it would be possible to develop a sketch plugin to render react components onto artboards, then I googled my way into your react-sketchapp and a talk you delivered at ZEIT. You guys are doing some really cool and useful work. Thanks!
Person sally, I don’t want to use products where the developer prioritizes their problems over my experiencs but YMMV. Some will argue that an Electron dumpster fire is superior to nothing. I consider that debatable.
Modern day software applications are far more accessible and usable on average than those of the 90s and 00s. And that's the metric that actually matters. More people are able to do more things with software.
However, React itself (not the javascript engine) brings in additional dimensions, that are somewhat unique to react.
For example, React's (and therefore ReactNative) TextInput control, essentially (in my understanding) encourages you to update a state variable, every single time type a letter into that control
(because the values displayed in the control are coming from the state, so the only way to display the character you typed, is via updating the state).
So that round trip of the character update, to updating the object with state variable, calling .setState, forcing the re-rendering, will consume more battery power. In my view
(I know textinput in particular has the 'uncontrolled model').
My point, that the constant 'create new object', update the state with it, and Re-render -- could be slower (and less battery efficient), than doing may be something similar (or more efficient) in Native Code.
It seems there are sites that uses Rails, including AirBnB. But I have yet to seen a site that uses Turbolink apart from Bassecamp, even Github uses its own version of pjax rather then Turbolink.
But TurboLinks 5? None, not even a mention or beep. As if no one is using it. While we are happily using it someone else may be running into issues we haven't yet doubt with.
It is pretty much like Startup news, I don't want to read about how you succeed this just once. I want to read about your thousands other failure, what works, what not, and what you ( Or I could ) learned from it. By stating your problem, your intended solution, and the results I could make a better informed decision somewhere down the line. And all the time we got on the internet is everyone cheer leading mindlessly.
Say what you like but this is a very mature move from a young engineering organization.
I get that it’ll have native performance and responsiveness, but still maybe just touch up your website and call it a day?
like HTML?
> which the client then renders into a native view.
A WebView?
RN isn’t just “HTML in a webview” like PhoneGap or Cordova: elements are actually rendered as native UI components. E.g., a <Text> element becomes a native UILabel on iOS and a TextView on Android.
Airbnb is ten years old at this point, I'm not sure that really counts as young!
On Windows they have access to the native APIs if signed and delivered via the store, as Microsoft is building on JavaScript development story they introduced with WinRT.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
> Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.
The whole 10 years there were people that think that they can just get "web" technology and speedup mobile development.
Almost always this companies had no mobile engineers that know how this stuff works. Developers that know that you just can't listen to scroll and update animations by sending messages to background js thread. This just completely wrong on mobile. Most mobile devs spend months to make it fast and easy to use. There are no way to do this in most cases on RN. AirBNB's app is a perfect example of this. Trying to deliver "better" experience they completely kill scrolling performance. Even top level iPhones feels laggy. But yay! We have animations! AirBNB's app is barely usable on two-year-old androids. This is just simply wrong, this is not how you can achieve good performance and nice animations on such small devices. In most cases this is a kind of art and a lot of testing and tweaking for every device. This can be done by only ONE talented developer per platform per year. Surely AirBNB has resources. Just take specific screen and tweak it to hell. On the other side, react and declarative kind of state is really doesn't work well for non-page oriented apps. Mapping history of navigation via redux store is just an awful and useless idea that helps with nothing. Right now there are still no navigation library.
Every time i tried to start something in React Native i failed since i wasn't able to apply my skills to make it behave fast there are just no easy way to do this.
React Native for sure is a good thing, but it's evolution shaped by web devs that try to reflect their experience from web development, but building a good mobile app is completely different from web one. For example, there are no dom, UI manipulation is not slow, navigation between pages and keeping it's state is not a problem most of the time (there are no real "back" button that you have to handle somehow). UI frameworks are more mature (while have less API than HTML).
React Navigation and React Native Navigation are both viable options with their own pros and cons. Been using them successfully in different projects.
I built a bunch of apps with JS navs and nobody ever complained...
That's just the scenario I'm aware of. I haven't done any real projects with React Native, so there may be other pitfalls.
E.g. react router on web has gone through many versions and there are several community libraries for doing web navigation and how you want to track that application state.
RN isn't really web technology. It is a JS engine along side a cross platform API translates API calls to the appropriate underlying native platform code. UI components rendered by RN do not use web tech at all.
It is no different than Xamarine in that regard, and has many of the same drawbacks.
> AirBNB's app is barely usable on two-year-old androids.
I never had problems with it on my Nexus 5x, and everything was a lag fest on that phone. (Lag in daily use got so bad after moving to Android 8 that I had to get a new phone just for my sanity.)
For a large # of apps, RN works just fine. Its real promise is not "web technology", so far as it is 99% code sharing across platforms.
The other players in this market don't have the same community drive that RN does, so people gravitate towards RN.
It’s not easy to debug at all. The problem they mentioned where your stack traces just end at layer transitions is a real problem. Even if the server side isn’t involved in the bit you’re working on.
Often they were confused about native vs RN approach and had to write native libraries and integrated them with RN which requires 3 different teams to write & test and integrate their code. I can see that if one of the teams is either slow or run into strange bugs, they will be the bottleneck and slow down all of them.
From this perspective, similar to why Netflix or other large organization choose micro-services rather than monoliths, it would be better for Airbnb to develop 2 different native apps separately rather than having 3 different teams depending on each other.
I would though love react jsx syntax for building native views in swift/Kotilin.
[1] http://kotlinlang.org/docs/reference/type-safe-builders.html
Anyway, I'd love to know how it would work for an Airbnb-like org.
C# isn't that popular from a silicon valley engineering perspective, since the first class C# implementation wasn't open source until very recently. Yes mono has always be OSS, but it has also been a second class citizen too.
I am aware of why C# isn't popular among startups. It is sad because C# is a great language that has amazing tooling support. It runs everywhere - Xamarin for apps, ASP.NET for servers, Blazor for browsers, and it is getting only better, and I cannot imagine how awesome it would be if other companies helped Microsoft. But I can only dream.
It's a problem with the entire design type, which has been shown throughout computing history to not work that well.
And why use C# when the Java ecosystem is pretty much the same tooling wise? C# feels like a 1.2x better Java, which isn't enough.
Also Sun really bombed their Java Gaming initiative (who remembers that JavaONE?) with C# becoming the C++'s complement in most studios.
Even basic stuff like switching to the native L&F theme on startup.
Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?
For example their answer to RN’s one second rebuilds is a custom Android build configuration that eliminates most of their 5 minute builds. They are proposing a custom server rendering setup and don’t know how to solve the hardest problems like wiring up events (HTML anyone?).
But for big companies java/kotlin or/and Objective-C/swift native apps will be more efficient.
Not sure what the issue is except that it is yet another language to learn.
Google designed it to be easy to learn for other devs. I am mainly only experienced in Java and some Kotlin, and I found Dart easy to pick up.
Could it be true? Does AirBNB see the writing on the wall somehow?
I know that RN is open source and people will continue to support it and everything will be great, but without Facebook behind it, I wonder how much traction it’ll have.
Where are you getting that from? The React Native team at Facebook just put out a roadmap that seemed to indicate they were still very committed to the project and investing in it:
http://facebook.github.io/react-native/blog/2018/06/14/state...
"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. Since its creation in 2015, all of Marketplace has been built with React Native, including over a hundred full-screen views throughout different parts of the app."
Please don't repeat and spread false rumors. It cheapens discussion about legitimate technical choices that organizations make.
I think React Native is in legacy support mode rather than active innovation.
- https://twitter.com/sandofsky/status/1002637340291018754
Responses from someone at FB:
- https://twitter.com/sophiebits/status/1003101478427357184 - https://twitter.com/sandofsky/status/1003104331833532416
[0] http://facebook.github.io/react-native/blog/2018/06/14/state...
We're working on a large-scale rearchitecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps.
http://facebook.github.io/react-native/blog/2018/06/14/state...