Why did Airbnb dump React Native? (2021)(theimmigrantprogrammers.com)
theimmigrantprogrammers.com
Why did Airbnb dump React Native? (2021)
https://www.theimmigrantprogrammers.com/p/why-airbnb-dumped-react-native
135 comments
YouTube is in danger of becoming the video site of last resort if they keep allowing SEO engineers to drive good content down and instead drive garbage to the top
Also, I got my first DMCA takedown the other day. They said I'm allowed 3 before they delete my site. All my videos passed the copyright check when I uploaded them so I relied on that as fair use. It occurred to me that my site will inevitably be taken down if 3 is the limit so I've lost all motivation to use it for anything.
Also, I got my first DMCA takedown the other day. They said I'm allowed 3 before they delete my site. All my videos passed the copyright check when I uploaded them so I relied on that as fair use. It occurred to me that my site will inevitably be taken down if 3 is the limit so I've lost all motivation to use it for anything.
I'm sure you've thought about this already, but you might want to `yt-dlp` your videos now if you care about preserving them.
I've been on YouTube since the beginning. In the early days I uploaded a short clip from a favorite movie but YouTube removed it. A bunch of other people downloaded it and kept re-uploading it until YouTube finally gave up. I guess their new tact is tougher. They threaten to delete your account now.
Not new at all. This 3 strike system has been in place since pretty much the beginning of the Content ID system.
Where would you host them?
Not perfect for everyone but for my commercial content, Vimeo has been a good choice in terms of presentation, storage, and cost.
Open, pro user platform? 1)
1) https://odysee.com/
1) https://odysee.com/
why I'm suing youtube
https://news.ycombinator.com/item?id=32488049
This is very inaccurate in many aspects, not sure if actually anything accurate in this except the fact that Airbnb did use and eventually dumped RN (source: I worked at Airbnb 2015-2019 on the platform team).
As others have linked, Airbnb actually did write a summary about this.
Basically what went down: For years Airbnb had actually pretty strong native mobile engineering both on iOS and Android (some of the best engineers I’ve worked with) there was no issue investing more in to it. The had the resources, platforms were working well.
The main challenge however was that anything the company needed to launch, needed to be built on 3 platforms at the same time (4 if you count tablet). Timelines were often tight which made the overall coordination between the platforms tough.
One the main examples of this was when 2015-2016 team I was part of basically redesigned and rebuilt the mobile apps, and created a design system/component/layout library at the same time for each platform. It was a huge effort.
At the same time, there was one guy basically hacking on React Native and ended he built the whole component system by himself in few weeks, compared to the months it took in native platforms. This was obviously impressive and company decided to experiment if we could use RN more to speed up development. I think the idea was never to fully replace the native platforms or even core flows, but there were lot of random flows and screens in guest and host apps which only minority of the users see.
So 2016-2019 there was a core team working on a RN adoption, and different people and teams used it in different projects. There were some technical issues at times with performance and navigation that got eventually solved.
However where it all came down was there wasn’t that much adoption and there wasn’t clear group who would actually use RN. Mobile engineers didn’t want to write RN code and web engineers didn’t want to build on mobile. RN also requires understanding of the native platforms, and if the point is build both for iOS and Android, then you need to understand both platforms which is a rare skill set.
So in the end it was just more complicated than it was worth.
I think new company/product can build the team and culture around RN will have better success.
I’d still think if it’s the right choice given what you are building. No matter how good you are I think the RN/Flutter apps can be ok it’s really hard to make them feel fully native.
As others have linked, Airbnb actually did write a summary about this.
Basically what went down: For years Airbnb had actually pretty strong native mobile engineering both on iOS and Android (some of the best engineers I’ve worked with) there was no issue investing more in to it. The had the resources, platforms were working well.
The main challenge however was that anything the company needed to launch, needed to be built on 3 platforms at the same time (4 if you count tablet). Timelines were often tight which made the overall coordination between the platforms tough.
One the main examples of this was when 2015-2016 team I was part of basically redesigned and rebuilt the mobile apps, and created a design system/component/layout library at the same time for each platform. It was a huge effort.
At the same time, there was one guy basically hacking on React Native and ended he built the whole component system by himself in few weeks, compared to the months it took in native platforms. This was obviously impressive and company decided to experiment if we could use RN more to speed up development. I think the idea was never to fully replace the native platforms or even core flows, but there were lot of random flows and screens in guest and host apps which only minority of the users see.
So 2016-2019 there was a core team working on a RN adoption, and different people and teams used it in different projects. There were some technical issues at times with performance and navigation that got eventually solved.
However where it all came down was there wasn’t that much adoption and there wasn’t clear group who would actually use RN. Mobile engineers didn’t want to write RN code and web engineers didn’t want to build on mobile. RN also requires understanding of the native platforms, and if the point is build both for iOS and Android, then you need to understand both platforms which is a rare skill set.
So in the end it was just more complicated than it was worth.
I think new company/product can build the team and culture around RN will have better success.
I’d still think if it’s the right choice given what you are building. No matter how good you are I think the RN/Flutter apps can be ok it’s really hard to make them feel fully native.
I have never seen cross-platform UI that would work and/or look close enough to native. It has always been classic "choose any two": cross-platform, UI, great.
There were many people who claimed they have achieved all three, but at the close examination all of them, 100% without exception, were missing many little things like standard shortcuts, respecting color preference in user settings, or just couldn't see the difference between 11pt and 13pt fonts while looking directly at them.
10 years ago I worked on rewriting Qt interface of a desktop app back to native for a similar reason, and now I am reading all the same story except it's about React Native in mobile apps.
There were many people who claimed they have achieved all three, but at the close examination all of them, 100% without exception, were missing many little things like standard shortcuts, respecting color preference in user settings, or just couldn't see the difference between 11pt and 13pt fonts while looking directly at them.
10 years ago I worked on rewriting Qt interface of a desktop app back to native for a similar reason, and now I am reading all the same story except it's about React Native in mobile apps.
> I have never seen cross-platform UI that would work and/or look close enough to native.
But wouldn't knowing that require that you investigated the tech choices of all the apps you are using? If not, there's a slight fallacy in that you only _know_ that the app is cross platform when you can see that it is. So then obviously all the apps you know is cross platform will look out of place, because that's how you know they are cross platform. Not sure I'm making the argument very well.
For instance, I'm don't think that the Discord app for iOS and Android looks out of place [0].
> Switching to React Native for the Android app means an experience that is ever-improving at a more rapid pace across every platform Discord is available on, while still retaining Android and iOS specific patterns in the UI.
[0]: https://discord.com/blog/android-react-native-framework-upda...
But wouldn't knowing that require that you investigated the tech choices of all the apps you are using? If not, there's a slight fallacy in that you only _know_ that the app is cross platform when you can see that it is. So then obviously all the apps you know is cross platform will look out of place, because that's how you know they are cross platform. Not sure I'm making the argument very well.
For instance, I'm don't think that the Discord app for iOS and Android looks out of place [0].
> Switching to React Native for the Android app means an experience that is ever-improving at a more rapid pace across every platform Discord is available on, while still retaining Android and iOS specific patterns in the UI.
[0]: https://discord.com/blog/android-react-native-framework-upda...
The discord user complaints rose exponentially after the switch to RN, and almost all users felt a perceivable difference in the quality of the new apps.
Hehe, I guess I was too late to party to experience the good ol' days.
It has a good rating in app store today. Better than Slack, even. And although there are probably many reasons for that, atleast RN hasn't killed the ratings.
It has a good rating in app store today. Better than Slack, even. And although there are probably many reasons for that, atleast RN hasn't killed the ratings.
this is quite normal when you do a full codebase refactor, even if you didn't switch technologies
it is like comparing a 5 year old codebase with 1000s of man-months ironing bugs out with a 1 year old codebase with 500 man-months of work
Seems like the bigger problem is their QA department than their engineering decisions
Seems like the bigger problem is their QA department than their engineering decisions
> But wouldn't knowing that require that you investigated the tech choices of all the apps you are using?
I did investigate every app I ran, because I was programming UIs and was interested in all tech that was there. To the point of being able to tell whether the app was written with Delphi or Qt or MFC/ATL by just playing with it.
Qt apps on Mac always stand out, being "OK" is the top they achieve.
Windows is less offended because it has never had a stable style, but still, there are always tiny details like context menus or not responding to Ctrl+Arrows that give non-native away.
I did investigate every app I ran, because I was programming UIs and was interested in all tech that was there. To the point of being able to tell whether the app was written with Delphi or Qt or MFC/ATL by just playing with it.
Qt apps on Mac always stand out, being "OK" is the top they achieve.
Windows is less offended because it has never had a stable style, but still, there are always tiny details like context menus or not responding to Ctrl+Arrows that give non-native away.
I shipped consumer software with Qt in the 2000's. It was nicer to work in than MFC. It looked and worked great on Windows 98/2000/XP. Qt's Windows XP renderer called Windows' own uxtheme.dll to draw everything.
Mac OS X looked a little off, especially the spacing.
Mac OS X looked a little off, especially the spacing.
Is the point of React Native to use native GUI elements and not to emulate the platform look and feel?
A few years ago I worked on Java application using SWT. It looked very OK on Linux/Mac/Windows. Even original AWT in Java was cross-platform an native. The problem with Java was GC pauses, but this is a solved problem now.
A few years ago I worked on Java application using SWT. It looked very OK on Linux/Mac/Windows. Even original AWT in Java was cross-platform an native. The problem with Java was GC pauses, but this is a solved problem now.
20 years ago I worked on some Java applications as a college student curious to compare AWT/Swing to other options, and I found that the cross-platform rendering worked decently well, but that the underlying architecture and algorithms were hot garbage. For instance, if you had a full-screen panel nested in a full screen panel, and you put the CPU under heavy load, you could watch it fill both background colors despite the front panel completely obscuring the back panel. Using Windows native API "windows" the paint events would only happen for the un-obscured components and only for the regions exposed. Java advocates advertised how "lightweight" their components were because they "didn't depend on a heavy-weight operating system window object" when in fact those "heavyweight" window objects were part of an algorithm that performed much better. Another big annoyance was that every UI event was delivered in its own thread, so you had to deal with all the complexities of multithreading just trying to write simple user interfaces. I had a whole blog-sized article I wrote once about all the design deficiencies; I've forgotten most of the rest of those details.
Java actually succeeded quite well at being cross-platform, it just wasn't a design worth being cross-platform in the first place.
Hopefully they fixed some of this in 20 years.
Java actually succeeded quite well at being cross-platform, it just wasn't a design worth being cross-platform in the first place.
Hopefully they fixed some of this in 20 years.
> Timelines were often tight
I wonder if those tight timelines seem justified in retrospect. The stress. Missed social events.
I wonder if those tight timelines seem justified in retrospect. The stress. Missed social events.
> Mobile engineers didn’t want to write RN code and web engineers didn’t want to build on mobile
That's interesting. In our experience, we're having a difficult time hiring folks that want to write native (including UI) in antiquated languages and frameworks - but it's much easier to hire JavaScript folks that just hack at RN.
Of course, someone still needs to stand up the actual platform, as well as write shared (and sometimes platform specific) pieces of functionality mostly in C++ so for now I guess us oldtimers still have some job security :)
That's interesting. In our experience, we're having a difficult time hiring folks that want to write native (including UI) in antiquated languages and frameworks - but it's much easier to hire JavaScript folks that just hack at RN.
Of course, someone still needs to stand up the actual platform, as well as write shared (and sometimes platform specific) pieces of functionality mostly in C++ so for now I guess us oldtimers still have some job security :)
This is an iOS only perspective, but it sounds like you are not actually looking too hard for iOS developers?.
No iOS developer considers Swift antiquated (because it isn't). I'd argue no one even considers UIKit antiquated (middle aged, maybe). Maybe with the exception of brand new iOS developers who has jumped on the SwiftUI-only bandwagon. SwiftUI itself is so new that it barely is production ready.
Sounds to me like you are actually looking for web developers who doesn't want to start learning native, but are OK to do the work in JS.
No iOS developer considers Swift antiquated (because it isn't). I'd argue no one even considers UIKit antiquated (middle aged, maybe). Maybe with the exception of brand new iOS developers who has jumped on the SwiftUI-only bandwagon. SwiftUI itself is so new that it barely is production ready.
Sounds to me like you are actually looking for web developers who doesn't want to start learning native, but are OK to do the work in JS.
Sorry, just realized most folks associate React Native with mobile. We target that too, but we're mostly targeting desktop platforms (via React Native Windows and React Native macOS) - and in our case antiquated really means antiquated (think old-school custom XML-based UI framework).
How are you finding using RN on desktop? When I last looked into it (more than a year ago) RN Mac felt a bit lacking. There was no way to do drawing of custom paths (eg SVG) for example.
Ended up using react-native-web in an Electron container to make a desktop version of an RN app, which worked surprisingly well.
Ended up using react-native-web in an Electron container to make a desktop version of an RN app, which worked surprisingly well.
I see, in that case I understand it more.
Yeah they think they know React Native until they have to debug something that is outside the happy path that is provided to them.
These people probably have never worked on a production RN app or done upgrades and maintenance for one.
These people probably have never worked on a production RN app or done upgrades and maintenance for one.
I want to clarify since this is getting upvoted, I still think RN is a better option than maintaining two separate apps in the vast majority of cases.
It just suffers because everybody "knows React" so how hard could it really be and people get hired into roles working on RN with very little understanding of how it's different from a web based React project.
It just suffers because everybody "knows React" so how hard could it really be and people get hired into roles working on RN with very little understanding of how it's different from a web based React project.
The promise of achievable unification with high-quality polished UX ends up being empty. React is complex.
> folks that want to write native (including UI) in antiquated languages and frameworks
I’m which land is Kotlin and Swift antiquated? Both a modern and cutting edge technologies with stellar toolchain and 1st class IDE and platform support.
I’m which land is Kotlin and Swift antiquated? Both a modern and cutting edge technologies with stellar toolchain and 1st class IDE and platform support.
I wouldn’t call Swift (or Kotlin) antiquated. I’m sure it’s easier to hire JavaScript developers to hack on React Native because the talent pool is larger, but I’d wager your app quality will suffer. Depending on the app, sometimes a first class user experience just isn’t a high priority, in which case native-focused developers aren’t going to be attracted to working on it.
>I’d wager your app quality will suffer.
I really dislike this argument, and it comes up every time React Native is discussed. I think it's a holdover from Ionic style mobile applications that simply emulated native UI in a webview. It was awful - especially when the native UI changed and the Ionic apps didn't. It's likely you use RN apps every day and don't even notice because they're indistinguishable from native apps.
React Native is designed to compile down to native code and it uses native UI frameworks. The documentation on how it does this is very thorough. The problem is not React Native in my opinion. It's the native UI frameworks for iOS and Android. These frameworks have a lot of issues and taming them often requires developers with a lot of time and experience in that specific domain. Which is stupid and wasteful.
Here's a story from yesterday of how Apple's SwiftUI (their much vaunted successor to UIKit, a very flawed framework itself) is struggling to construct basic settings views in the new version of MacOS: https://daringfireball.net/linked/2022/08/15/ventura-system-...
Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving. And how complicated doing a fucking substring is: https://stackoverflow.com/questions/39677330/how-does-string...
In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
I really dislike this argument, and it comes up every time React Native is discussed. I think it's a holdover from Ionic style mobile applications that simply emulated native UI in a webview. It was awful - especially when the native UI changed and the Ionic apps didn't. It's likely you use RN apps every day and don't even notice because they're indistinguishable from native apps.
React Native is designed to compile down to native code and it uses native UI frameworks. The documentation on how it does this is very thorough. The problem is not React Native in my opinion. It's the native UI frameworks for iOS and Android. These frameworks have a lot of issues and taming them often requires developers with a lot of time and experience in that specific domain. Which is stupid and wasteful.
Here's a story from yesterday of how Apple's SwiftUI (their much vaunted successor to UIKit, a very flawed framework itself) is struggling to construct basic settings views in the new version of MacOS: https://daringfireball.net/linked/2022/08/15/ventura-system-...
Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving. And how complicated doing a fucking substring is: https://stackoverflow.com/questions/39677330/how-does-string...
In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
There’s always going to be a performance penalty for React Native applications because of the JavaScript bridge, and on iOS you’re giving up ARC memory management for your app logic. For basic stuff you can write it off, but doing anything cutting edge like AR, custom graphics drawing, custom text layout and input, etc. is off the table. Even picking up a new iOS feature (e.g. focus filters) is a pain because you need to maintain a layer of bridge code, or wait for a third party module to catch up.
One somewhat direct comparison is Discord (RN) vs Telegram (Swift) on iOS. Discord has put a massive engineering effort into their app but switching channels still often feels glitchy and sluggish whereas Telegram’s layouts snap into place instantly. Telegram feels more solid, and it also properly wires up all the little iOS features like haptic feedback, pull to refresh, etc. whereas Discord mutes all of that and feels less lively.
Regarding constraint-based layouts, they can actually be much simpler in many cases because they help you avoid deep layers of nesting. They also ensure consistency (leading and trailing margins, safe areas, etc.) Again, trade-offs that deal in performance and uniformity with the platform.
For CRUD type apps, it probably doesn’t matter. But like I said those probably aren’t the types of apps native developers would be most interested in building.
One somewhat direct comparison is Discord (RN) vs Telegram (Swift) on iOS. Discord has put a massive engineering effort into their app but switching channels still often feels glitchy and sluggish whereas Telegram’s layouts snap into place instantly. Telegram feels more solid, and it also properly wires up all the little iOS features like haptic feedback, pull to refresh, etc. whereas Discord mutes all of that and feels less lively.
Regarding constraint-based layouts, they can actually be much simpler in many cases because they help you avoid deep layers of nesting. They also ensure consistency (leading and trailing margins, safe areas, etc.) Again, trade-offs that deal in performance and uniformity with the platform.
For CRUD type apps, it probably doesn’t matter. But like I said those probably aren’t the types of apps native developers would be most interested in building.
Look at the new Discord app. It's significantly slower than previously ever since the switch to react native, and has significantly more hangups.
React native works maybe fine if your target device is the highest end iPhone, but if your users are on Android One devices, it's not going to work nearly as well.
That's aside from the layouting being obviously off compared to the native layout engines.
React native works maybe fine if your target device is the highest end iPhone, but if your users are on Android One devices, it's not going to work nearly as well.
That's aside from the layouting being obviously off compared to the native layout engines.
It works just fine if you actually profile and see what are the bottlenecks.
I'd love to, sadly it doesn't appear to be open source ;)
I can say from comparing pre-RN and post-RN apps side-by-side on a Nokia 6.2 it's definitely much slower (scrolling immediately drops frames, opening/closing the keyboard and other reflows e.g. multiwindow cause the app to hang for seconds).
I can say from comparing pre-RN and post-RN apps side-by-side on a Nokia 6.2 it's definitely much slower (scrolling immediately drops frames, opening/closing the keyboard and other reflows e.g. multiwindow cause the app to hang for seconds).
> Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem
Don't know what your problem is, Kotlin and Swift are both superior to JS
> Here's a story from yesterday of how Apple's SwiftUI (their much vaunted successor to UIKit, a very flawed framework itself) is struggling to construct basic settings views in the new version of MacOS:
A journalist who is not an iOS developer saying something 'feels wrong' doesn't mean much in terms of quantitative evaluation of SwiftUI.
Others have already commented elsewhere on the source material (a list of UX nits) was based on a one month old beta release, and many had already been fixed at the time the list was published - something the author of that list neglected to point out at first.
> Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving.
People leave. Rob Pike has mostly stopped working on Go. Graydon Hoare left Mozilla - and worked on Swift for a time.
> And how complicated doing a fucking substring is:
I don't understand your reference. String manipulation on Swift has gotten markedly easier since Swift 3 (when that page was created), but it is still meant to be correct/safe unicode grapheme manipulations at its core. Swift's character type is essentially a variable length, special-case of string.
Most Swift string criticisms come down to - if you want to treat text as offsets into a (mutable) binary buffer, work with binary buffers and not unicode strings.
> In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
AppKit and UIKit's original constraint system was simple, even simplistic.
The constraint system that was built on top was sophisticated, but is generally too fiddly. You pretty much need training in the interface builder to understand how to get constraints to apply and stick.
This was quite simply because it was a bolt-on constraint solver over a layout engine with multiple decades of legacy. No layout options went away when constraints were added - instead, the system had to adapt to having (workarounds) for all the different approaches to operate concurrently.
I don't quite understand what technical complaints if any you have of Kotlin DSL or of SwiftUI's layout systems, so I can't speak to that.
> Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
I'm curious what makes something a 'standard UI' when doing native cross-platform development.
A journalist who is not an iOS developer saying something 'feels wrong' doesn't mean much in terms of quantitative evaluation of SwiftUI.
Others have already commented elsewhere on the source material (a list of UX nits) was based on a one month old beta release, and many had already been fixed at the time the list was published - something the author of that list neglected to point out at first.
> Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving.
People leave. Rob Pike has mostly stopped working on Go. Graydon Hoare left Mozilla - and worked on Swift for a time.
> And how complicated doing a fucking substring is:
I don't understand your reference. String manipulation on Swift has gotten markedly easier since Swift 3 (when that page was created), but it is still meant to be correct/safe unicode grapheme manipulations at its core. Swift's character type is essentially a variable length, special-case of string.
Most Swift string criticisms come down to - if you want to treat text as offsets into a (mutable) binary buffer, work with binary buffers and not unicode strings.
> In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
AppKit and UIKit's original constraint system was simple, even simplistic.
The constraint system that was built on top was sophisticated, but is generally too fiddly. You pretty much need training in the interface builder to understand how to get constraints to apply and stick.
This was quite simply because it was a bolt-on constraint solver over a layout engine with multiple decades of legacy. No layout options went away when constraints were added - instead, the system had to adapt to having (workarounds) for all the different approaches to operate concurrently.
I don't quite understand what technical complaints if any you have of Kotlin DSL or of SwiftUI's layout systems, so I can't speak to that.
> Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
I'm curious what makes something a 'standard UI' when doing native cross-platform development.
>A journalist who is not an iOS developer saying something 'feels wrong' doesn't mean much in terms of quantitative evaluation of SwiftUI.
Calling John Gruber a "journalist" is reductive. He is the inventor of markdown and has a history as a software engineer himself. He is also one of the most notable people who tracks things that many would consider obscure like Apple UI frameworks.
>I don't understand your reference https://news.ycombinator.com/item?id=32325511
The standard library and API surface of Swift has changed dramatically every release. They don't have a real problem to solve, and they know they have a guaranteed userbase of their language, so it's gotten progressively weirder and shittier over the years.
>I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Not that curious, because it's pretty easy to look up what React Native offers: https://reactnative.dev/docs/components-and-apis. Things like text inputs, buttons but also bigger conceptual stuff like list views and app navigation: https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.
Calling John Gruber a "journalist" is reductive. He is the inventor of markdown and has a history as a software engineer himself. He is also one of the most notable people who tracks things that many would consider obscure like Apple UI frameworks.
>I don't understand your reference https://news.ycombinator.com/item?id=32325511
The standard library and API surface of Swift has changed dramatically every release. They don't have a real problem to solve, and they know they have a guaranteed userbase of their language, so it's gotten progressively weirder and shittier over the years.
>I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Not that curious, because it's pretty easy to look up what React Native offers: https://reactnative.dev/docs/components-and-apis. Things like text inputs, buttons but also bigger conceptual stuff like list views and app navigation: https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.
I like Gruber, he has a CS degree and had a brief career as a web developer (which certainly helps him write about technology as well as keep his site operational), but he has been a full-time columnist for his own tech blog for 16 years. As far as I know, he does not have experience writing client side code, either using AppKit/UIKit or using a tool like React Native.
He has plenty of people in his network who are professional developers with SwiftUI experience. However, he was talking about his gut feel from a core system service having so many UI nits from Apple, likely associating that with issues he has heard of from developers who have tried to adopt SwiftUI in their existing and/or new projects.
So thats the basis of my opinion - a quote or two from those full-time developers would added greatly to the article, significantly more his personal reaction.
As a developer with some client-side experience, I'd say the nits speak far more to Apple's MacOS development process these days than to the quality of SwiftUI. A decision was made to add it to the 13 beta and commit to shipping it, rather than hold it back for macOS 14.
He has plenty of people in his network who are professional developers with SwiftUI experience. However, he was talking about his gut feel from a core system service having so many UI nits from Apple, likely associating that with issues he has heard of from developers who have tried to adopt SwiftUI in their existing and/or new projects.
So thats the basis of my opinion - a quote or two from those full-time developers would added greatly to the article, significantly more his personal reaction.
As a developer with some client-side experience, I'd say the nits speak far more to Apple's MacOS development process these days than to the quality of SwiftUI. A decision was made to add it to the 13 beta and commit to shipping it, rather than hold it back for macOS 14.
> antiquated languages and frameworks
Yikes, I hope you're not calling Kotlin or Swift antiquated. That's utterly false.
Yikes, I hope you're not calling Kotlin or Swift antiquated. That's utterly false.
Some people think only javascript/typescript is modern. The javascript cult hopes everything to be written in js.
Yeah the frameworks are painful to work with and require extremely powerful (and expensive) systems to develop with while js can be learned on any old low end chromebook.
One more thing covered in AirBnB’s blog posts is that they did eventually create a framework to make it easy to launch new experiences across platforms (versus the old way of needing to coordinate across 4). They just built it themselves and customized it to their needs versus using RN.
This is what u get for jumping on a bandwagon, instead I got my company to invest in a Software companies tech.
The same Xamarin app i built in 2014, still runs, on .net7. MS nailed crossplatform in a way that an ad company is never going to invest in. They needed to nail cross-platform to keep themselves as a company relevant; they lost the platform war, then redefined it.
Just launched more apps on the platform this year, love it to death. SAme skills i learnt in silverlight, still relevant 10yrs later. Share 90% of code across every platform; and that 10% is built on native wrapped libraries which are generated off every release. MS has the infrastructure and investment like no ad or book store would ever.
The same Xamarin app i built in 2014, still runs, on .net7. MS nailed crossplatform in a way that an ad company is never going to invest in. They needed to nail cross-platform to keep themselves as a company relevant; they lost the platform war, then redefined it.
Just launched more apps on the platform this year, love it to death. SAme skills i learnt in silverlight, still relevant 10yrs later. Share 90% of code across every platform; and that 10% is built on native wrapped libraries which are generated off every release. MS has the infrastructure and investment like no ad or book store would ever.
Xamarin/MAUI doesn’t get the buzz/love from HN audience that React Native and Flutter get. I think there is a lot of historical bias here.
My company has found success with the dotnet stack. We are able to keep a small team of 5 developers that maintain 3 mobile apps (Xamarin), 2 desktop apps (WPF transitioning MAUI), and 1 web app (Blazor) all sharing about 50-80% of the code base. These are apps that bring our company about $7+mil in annual revenue if you include the associated hardware which dotnet/C# is well suited to interact “natively” with.
You’re on to something. I did a stint at a .NET shop and C# is still my favorite language. Dabbled with a Xamarin project a few years ago, and although it seemed like it would be fragile, it actually “just worked”.
Right. They also extend, embrace, extinguish. They also make very clunky tools for people that like to click to code.
Airbnb switched away from React Native at a time when a lot of other high-profile companies did as well and wrote technical blog articles about it. Discord was one of the few dissenters:
https://news.ycombinator.com/item?id=17619609
Looks like they're doubling-down further still:
https://news.ycombinator.com/item?id=32310392
Looks like Shopify also picked up RN:
https://news.ycombinator.com/item?id=22181873
https://news.ycombinator.com/item?id=17619609
Looks like they're doubling-down further still:
https://news.ycombinator.com/item?id=32310392
Looks like Shopify also picked up RN:
https://news.ycombinator.com/item?id=22181873
The way Discord tamed React Native was writing its chat view entirely native. This is the area in which users probably spend 99% of their time. Similarly, in the Facebook and Instagram apps, React Native is banned from the home timelines and other areas where performance matters.
Recently Discord finally ported their Android app over. Even if you separate the "change is bad" factor, many users report it's quite laggy and a major regression from their previous native version.
I find it funny when people cite high profile companies as success stories without having a benchmark for failure. "The users didn't abandon the product in droves" is a very low bar when you have externalities that would prevent them from leaving even if they wanted to. You could find the Amazon app total garbage, but just how bad does it have to be to pass on free two day shipping?
Recently Discord finally ported their Android app over. Even if you separate the "change is bad" factor, many users report it's quite laggy and a major regression from their previous native version.
I find it funny when people cite high profile companies as success stories without having a benchmark for failure. "The users didn't abandon the product in droves" is a very low bar when you have externalities that would prevent them from leaving even if they wanted to. You could find the Amazon app total garbage, but just how bad does it have to be to pass on free two day shipping?
Discord on Android has absolutely taken a step backward since the shift. Just a little bit in UX/I (text input is larger than it used to be and doesn't scale with any appearance settings), but significantly in assigning messages to the correct person. Many a time in the past few weeks where a chunk of my messages in a DM get attributed to the other person after a minute or two, presumably due to some sync issue. I ain't impressed.
React Native has two kinds of proponents: managers who don't want to deal with expensive mobile engineers and frontend web developers who don't want to learn mobile engineering.
It's labor-saving and over-engineering combined into one seemingly respectable package. And I'm saying this as a manager and a former web developer.
Flutter seems to have more respect for the craft of mobile engineering, which alienates managers and developers looking for an easy fix for their jobs and their careers.
It's labor-saving and over-engineering combined into one seemingly respectable package. And I'm saying this as a manager and a former web developer.
Flutter seems to have more respect for the craft of mobile engineering, which alienates managers and developers looking for an easy fix for their jobs and their careers.
I sometimes wonder if all these independent companies who appear to make coordinated technical decisions are just hitting the same frustrations at the same time, or if engineers just read each other's blogs and and then pitch the blog ideas at their meetings. And then write a blog about it, which other engineers at other companies read and pitch at their meeting. So basically it becomes a self-perpetuating meme.
> So basically it becomes a self-perpetuating meme.
Sometimes many people in different places have had concerns, or ideas for a better way forward, for some time but have either but spoken up or have had the "everyone else seems to be dealing with it" reaction.
In such cases it takes a certain critical mass of information supporting the change to get movement, that critical mass builds slowly but once it is reached the immediate reaction can appear explosive, and there are sometimes aftershocks back & forth, much like an earthquake caused by plate movement.
So while there is some self fulfilling chain reaction feeding into it, there is usually some true need involved for a lot of the teams concerned.
Sometimes many people in different places have had concerns, or ideas for a better way forward, for some time but have either but spoken up or have had the "everyone else seems to be dealing with it" reaction.
In such cases it takes a certain critical mass of information supporting the change to get movement, that critical mass builds slowly but once it is reached the immediate reaction can appear explosive, and there are sometimes aftershocks back & forth, much like an earthquake caused by plate movement.
So while there is some self fulfilling chain reaction feeding into it, there is usually some true need involved for a lot of the teams concerned.
I’ve worked on several projects with relatively new web/mobile tech and the line: “Here’s how we solved it at my previous company” or “Here’s how [similar size, well marketed company] is doing it” is extremely persuasive to management and fellow engineers as it de-risks the situation.
By the time the new idea has its new problems, the company you followed (or one similar) has probably already posted about solving it, or shared a newer new idea you can try.
By the time the new idea has its new problems, the company you followed (or one similar) has probably already posted about solving it, or shared a newer new idea you can try.
I thought I was going to be an egnineer, and my decisions would be based on physics.
But I am more of a writer and decisions are driven by fashion
But I am more of a writer and decisions are driven by fashion
The intersection of technology and liberal arts, baby
Most companies tend to have some development "thought leaders" that propose big shifts like this (and use some politicking to advocate their views), and sometimes the "big thing" ends up working, and sometimes it ends up being a disaster.
Does anyone know if Facebook is written in React Native? Also what's the role of React Native in Oculus/AI/AR apps?
Its a bit disingenuous of the author, who didn't even work @ AirBnb to speculate about their tech decisions. While not citing AirBnBs blog (https://medium.com/airbnb-engineering/sunsetting-react-nativ...) on sunsetting react native.
Weird to see this poorly-written blog post make it to the front page. It misses so many details that the official blog post includes https://medium.com/airbnb-engineering/react-native-at-airbnb...
One of the conclusion from the article: is React Native bad, No. It depends on the type of app your are developing...
Of course!, since the day 1 of any web framework running as a native one. A post without any contribution
Right near the beginning:
> Till the year 2012, Airbnb was just a React website.
React wasn't released until 2013.
> Till the year 2012, Airbnb was just a React website.
React wasn't released until 2013.
First thing I noticed as well! I think nowadays younger developers mostly simply equate "web frontend" with "React" subconsciously. :)
Poor things, they missed the glorious Macromedia Flash days...
I do miss the games from shockwave.com in its heyday
Was the same way in the jQuery days with equating it to JavaScript.
It's a compliment to the tech of how useful and prevalent it is.
It's a compliment to the tech of how useful and prevalent it is.
It was Rails and React was maybe adopted more broadly after 2016
[deleted]
> Till the year 2012, Airbnb was just a React website
I stopped reading after this.
Websites released in 2012 were typically PHP, server-rendered, written with jQuery. Angular JS was considered cutting edge and go-to option for SPA projects. React was released later and only popularised around 2017-2018, and even at that time I remember most frontend developers were hesitant to use it in production due to the licensing ambiguity at that time (It wasn't MIT).
I stopped reading after this.
Websites released in 2012 were typically PHP, server-rendered, written with jQuery. Angular JS was considered cutting edge and go-to option for SPA projects. React was released later and only popularised around 2017-2018, and even at that time I remember most frontend developers were hesitant to use it in production due to the licensing ambiguity at that time (It wasn't MIT).
I’ve been writing React since 2015 and it was already gaining some decent momentum then
noo, can't have been that late?? i quit my last job in 2018 and we had already been using it for a couple years by then
I helped introduce React at UXPin, and that was in Q4 2015. By that point it had already been broadly hyped for at least a year.
The parent comment is broadly correct though. AirBnB couldn't have been a React website in 2012 if React's initial release was May 29th, 2013.
The parent comment is broadly correct though. AirBnB couldn't have been a React website in 2012 if React's initial release was May 29th, 2013.
0.14.x was when I adopted React. And yeah, I think it was getting quite popular already. That was released in 29/10/2015, so that matches what you said.
Weird title. The correct English would be "Why did Airbnb dump React Native?". All of the sub-headings have this strange construction as well. Is this 'correct' in some other country and I'm just not aware of it?
I was gonna say, it's also weird because the text of the article seems nearly-native quality.. but actually when I went back and looked more closely it's semi-broken English as well. I guess it's in big wordy paragraphs that you skim and don't notice the grammar of.
I was gonna say, it's also weird because the text of the article seems nearly-native quality.. but actually when I went back and looked more closely it's semi-broken English as well. I guess it's in big wordy paragraphs that you skim and don't notice the grammar of.
Looks like the author is Indian or more generally South Asian based on the video and profile picture, and in that English dialect, it's more expected to write statements as questions like the title rather than "Why did Airbnb dump React Native?"
I often see similar formations in casual translations from other languages. The blog is from "the immigrant programmers", so I guess that'd make sense. I am not a linguist but maybe this particular phenomenon is related to subject-verb inversion in a question sentence clause? Something like the stuff they're talking about on page 5 of this paper, maybe: https://www.researchgate.net/publication/265785678_Embedded_... (over my head)
Like the examples they give include:
> "What this is made from?"
> "Who you have come to see?"
> "I asked him where does he work."
> "I wonder where is he."
They all sound strange to me but are apparently common in some Englishes.
There were many other giveaways in the article that you'd never see in everyday American English usage:
"Oh yes, it happened!" (who says that)
"giant Online American Vacation Rental Business" (...it's just a vacation rental website)
"the, excessive use, of commas, everywhere"
Like the examples they give include:
> "What this is made from?"
> "Who you have come to see?"
> "I asked him where does he work."
> "I wonder where is he."
They all sound strange to me but are apparently common in some Englishes.
There were many other giveaways in the article that you'd never see in everyday American English usage:
"Oh yes, it happened!" (who says that)
"giant Online American Vacation Rental Business" (...it's just a vacation rental website)
"the, excessive use, of commas, everywhere"
It may be a form of "Euro English" [1].
[1] https://en.wikipedia.org/wiki/Euro_English
[1] https://en.wikipedia.org/wiki/Euro_English
Is it strange that it seems less wrong to me without the question mark?
No, in American (and I think British) English, it's common to add a word before the subject in a question. "Why Airbnb dumped RN" does not have to be a question. But when it is, American and British speakers expects an "auxiliary", I think it's called... from wikipedia: https://en.wikipedia.org/wiki/Subject%E2%80%93auxiliary_inve...
"Sam enjoys the paper" is fine.
"Sam enjoys the paper?" sounds weird, like you're questioning the sentence itself rather than asking Sam if they enjoyed the paper.
"DOES Sam enjoy the paper?" adds an auxiliary (does) and makes it more natural sounding, I guess, to our ears.
"Sam enjoys the paper" is fine.
"Sam enjoys the paper?" sounds weird, like you're questioning the sentence itself rather than asking Sam if they enjoyed the paper.
"DOES Sam enjoy the paper?" adds an auxiliary (does) and makes it more natural sounding, I guess, to our ears.
To me it sounds like this:
"Sam enjoys the paper?" could have emphasis on "Sam" and sound fine - it is asking if it is Sam or someone else who enjoys the paper.
"Sam enjoys the paper?" could have emphasis on "enjoys" and sounds fine - it is asking if Sam enjoys the paper or feels some other way.
"Sam enjoys the paper?" could have emphasis on "paper" and sounds fine - it is asking if Sam enjoys the paper or something else.
And "Does Sam enjoy the paper?" sounds fine too - it is asking a more specific yes/no question.
"Sam enjoys the paper?" could have emphasis on "Sam" and sound fine - it is asking if it is Sam or someone else who enjoys the paper.
"Sam enjoys the paper?" could have emphasis on "enjoys" and sounds fine - it is asking if Sam enjoys the paper or feels some other way.
"Sam enjoys the paper?" could have emphasis on "paper" and sounds fine - it is asking if Sam enjoys the paper or something else.
And "Does Sam enjoy the paper?" sounds fine too - it is asking a more specific yes/no question.
Right, but in all the "Sam enjoys the paper?" uses, you'd normally only do that if you were repeating something already said, and questioning a specific part of it. Like your friend said, "Sam enjoys the paper" and you're asking for a clarification by repeating and emphasizing a part of the statement.
Otherwise, it's just easier/clearer to phrase it like "Who was enjoying the paper?" or "How does Sam feel about the paper?" or "What does Sam like to read?"
But those constructions don't necessarily apply to other regional variants of English (especially if English is a second language for them). In that case they may be adapting their English grammar to be closer to the syntax of another language they speak.
Several of us here, including myself, are guessing that the blog author may be Indian (I'm not sure, it's just a guess). If so, there are papers studying this phenomenon or something close to it (I'm not really sure... I'm interested in languages, but I'm not at all a linguist and this is way over my head...). I'll quote (emphasis added) one paper: https://www.researchgate.net/publication/265785678_Embedded_...
> The corpus study reported here challenges a conventional assumption in the World Englishes literature concerning the grammar of L2 English in India: that auxiliary inversion with wh -movement (henceforth wh -inversion) is exactly the opposite of standard U.S. and U.K. English, being impossible in main clauses yet obligatory in embedded clauses (Bhatt, 2000 ; Mesthrie & Bhatt, 2008 ; Trudgill & Hannah, 2008 ). 2 If the prevailing account were valid, this language variety would constitute a rogue grammar in the sense of Thomas ( 1991 ). However, the results suggest that, in this respect, the grammars of L2 users of English in mul-tilingual societies, just like those of monolingual speakers of standard varieties, fall within the compass of Universal Grammar (UG).
In other words... what you're saying makes perfect sense to me and presumably other speakers of some broad "American English" because we're used to those formulations. English elsewhere in the world, possibly including wherever the blog author came from, does not necessarily follow the same rules all the time, especially if English is just one of a matrix of languages they use throughout a week, mixing and matching languages and grammars according to who and what they need to communicate.
As an aside... if stuff like this interests you, the movie Arrival might be interesting? It's that rare pop-sci movie that tries to actually deal with alien linguistics instead of hand-waving it away with a universal translator/babelfish.
Otherwise, it's just easier/clearer to phrase it like "Who was enjoying the paper?" or "How does Sam feel about the paper?" or "What does Sam like to read?"
But those constructions don't necessarily apply to other regional variants of English (especially if English is a second language for them). In that case they may be adapting their English grammar to be closer to the syntax of another language they speak.
Several of us here, including myself, are guessing that the blog author may be Indian (I'm not sure, it's just a guess). If so, there are papers studying this phenomenon or something close to it (I'm not really sure... I'm interested in languages, but I'm not at all a linguist and this is way over my head...). I'll quote (emphasis added) one paper: https://www.researchgate.net/publication/265785678_Embedded_...
> The corpus study reported here challenges a conventional assumption in the World Englishes literature concerning the grammar of L2 English in India: that auxiliary inversion with wh -movement (henceforth wh -inversion) is exactly the opposite of standard U.S. and U.K. English, being impossible in main clauses yet obligatory in embedded clauses (Bhatt, 2000 ; Mesthrie & Bhatt, 2008 ; Trudgill & Hannah, 2008 ). 2 If the prevailing account were valid, this language variety would constitute a rogue grammar in the sense of Thomas ( 1991 ). However, the results suggest that, in this respect, the grammars of L2 users of English in mul-tilingual societies, just like those of monolingual speakers of standard varieties, fall within the compass of Universal Grammar (UG).
In other words... what you're saying makes perfect sense to me and presumably other speakers of some broad "American English" because we're used to those formulations. English elsewhere in the world, possibly including wherever the blog author came from, does not necessarily follow the same rules all the time, especially if English is just one of a matrix of languages they use throughout a week, mixing and matching languages and grammars according to who and what they need to communicate.
As an aside... if stuff like this interests you, the movie Arrival might be interesting? It's that rare pop-sci movie that tries to actually deal with alien linguistics instead of hand-waving it away with a universal translator/babelfish.
Merriam-Webster shows plenty of examples of usage at the top
https://www.merriam-webster.com/dictionary/dump
"He dumped his clothes on the bed. She dumped the contents of her purse on the table. I dumped the old coffee down the drain."
https://www.merriam-webster.com/dictionary/dump
"He dumped his clothes on the bed. She dumped the contents of her purse on the table. I dumped the old coffee down the drain."
Dumped as word isn't the incorrect English. The formation of the question is the incorrect English.
Correct: He dumped his clothes on the bed.
Incorrect: Why he dumped his clothes on the bed?
Correct: Why did he dump his clothes on the bed?
Correct: He dumped his clothes on the bed.
Incorrect: Why he dumped his clothes on the bed?
Correct: Why did he dump his clothes on the bed?
Minor nitpick, I don't know if there really is such a thing as a singular "correct English", especially when you're comparing across cultural groups (but even within). There are so many variations between American English (and its various subgroupings), British English, Indian English, Singaporean English, etc.
It's a widely-used living language, and one without a central authority (language regulator, unlike many other languages: https://en.wikipedia.org/wiki/List_of_language_regulators)
So English just kinda grows and grows haphazardly. There are more people in India who speak English (Wikipedia estimates 30% of 1.38 billion, which is 400 million) than there are Americans or UK residents. IMO their particular usage isn't any more or less correct, any more than American English is more or less correct than British English.
It's not a matter of being politically correct or anti-racist or whatever, just the observation that English has always been a hodgepodge of regionalisms and will continue to be for the foreseeable future, and by speakers/population alone, probably the American and British varieties will continue to shrink as other Englishes take over. Probably it's us Westerners that will need to adopt to the new Englishes rather than the other way around.
Grammar prescriptivists and grade school teachers might disagree, but well, they are overwhelmingly in the minority already and will become increasingly more so.
It's a widely-used living language, and one without a central authority (language regulator, unlike many other languages: https://en.wikipedia.org/wiki/List_of_language_regulators)
So English just kinda grows and grows haphazardly. There are more people in India who speak English (Wikipedia estimates 30% of 1.38 billion, which is 400 million) than there are Americans or UK residents. IMO their particular usage isn't any more or less correct, any more than American English is more or less correct than British English.
It's not a matter of being politically correct or anti-racist or whatever, just the observation that English has always been a hodgepodge of regionalisms and will continue to be for the foreseeable future, and by speakers/population alone, probably the American and British varieties will continue to shrink as other Englishes take over. Probably it's us Westerners that will need to adopt to the new Englishes rather than the other way around.
Grammar prescriptivists and grade school teachers might disagree, but well, they are overwhelmingly in the minority already and will become increasingly more so.
Syntax affects semantics.
Seeing "Why he dumped his clothes on the bed?" you can guess that they MEANT to say was "Why did he dump his clothes on the bed?"
But there's a bit of uncertainty there, was that really what they meant to say? Or did they mean to say something like "Why did he dump his clothes on the bed IS MY QUESTION" but somehow the rest of the sentence got lost.
Syntactically correct sentences have typically a much more precise semantics than syntactically incorrect ones. One could argue that incorrect syntax means the meaning is anybody's guess.
Point is when we read or hear language we must interpret it by assuming what we think the speaker wants to say. But if syntax is incorrect that becomes much more difficult. Therefor correct syntax is a god-send for getting your point across.
Think about the way browsers interpret HTML. They allow you to deviate from the standard somewhat. But that causes different browsers to produce different visible output. Not a good thing. Maybe the coder thinks they are getting their point across, but depending on the audience, what browser they are using, the "point" can get lost. Best bet is to use standard syntax.
Seeing "Why he dumped his clothes on the bed?" you can guess that they MEANT to say was "Why did he dump his clothes on the bed?"
But there's a bit of uncertainty there, was that really what they meant to say? Or did they mean to say something like "Why did he dump his clothes on the bed IS MY QUESTION" but somehow the rest of the sentence got lost.
Syntactically correct sentences have typically a much more precise semantics than syntactically incorrect ones. One could argue that incorrect syntax means the meaning is anybody's guess.
Point is when we read or hear language we must interpret it by assuming what we think the speaker wants to say. But if syntax is incorrect that becomes much more difficult. Therefor correct syntax is a god-send for getting your point across.
Think about the way browsers interpret HTML. They allow you to deviate from the standard somewhat. But that causes different browsers to produce different visible output. Not a good thing. Maybe the coder thinks they are getting their point across, but depending on the audience, what browser they are using, the "point" can get lost. Best bet is to use standard syntax.
I think this is kinda missing the point: that what might look "incorrect" in one version of English is perfectly common and acceptable, maybe even "correct", in another. There is no one universal definition of "correct English". There is no one single English, even more so than in languages that at least have regulatory agencies (language academies).
Each English-speaking region comes up with their own rules, perhaps initially descended from a group of British or American emigrants, but evolving over time to form their own variants. It happened from the slave trade, it happened from the age of sail, it happened in Hawaii, in the American South, in the American West, in the Philippines, in India, in South Africa... they all speak subtly different variants, with different rules.
There is no universally correct use of English. There are various rules documented in various dictionaries and grammar/style guides, and reinforced by teachers and higher-class people of various societies, but those are descriptive, after-the-fact illustrations that follow the evolving language, not the other way around.
It's one thing to say that a child's usage of language is incorrect because they haven't learned it yet, within a certain cultural context. It's another thing entirely to presume that your region's usage of English is the only "correct" one. There's no such thing.
Examples (American vs British):
"Data is" vs "data are"
"Do you have a car?" vs "Have you got a car?"
"I already saw that film" vs "I've already seen that film" etc.
color vs colour, trunk vs boot, etc. more examples here: https://www.thoughtco.com/differences-between-american-and-b...
For the blog title in question (which isn't an American vs British difference, to be clear, but possibly an Indian English construction -- not sure), the sentence is perfectly clear, with or without the "did". There isn't some weird ambiguity about it, especially in the context of a tech blog. I agree that it sounds strange to American/British ears, but it's not really "incorrect", it's just a regional stylistic difference -- or so we surmise. Give it 50 years' worth of population growth and migrations, and that construction might very well become the more common one, leaving the American and British versions sounding quaint and foreign.
Now, maybe a related question is whether the writer should've written in the American style, kinda like how many foreign English singers will emulate an American accent. In that case it's not a question of correctness anymore, but of adapting your communications for a cross-cultural context and targeting a specific group of English users and their traditions. I'm not arguing that the author should or should not have done that, just that their choice wasn't "incorrect". Just different from what we're used to.
Each English-speaking region comes up with their own rules, perhaps initially descended from a group of British or American emigrants, but evolving over time to form their own variants. It happened from the slave trade, it happened from the age of sail, it happened in Hawaii, in the American South, in the American West, in the Philippines, in India, in South Africa... they all speak subtly different variants, with different rules.
There is no universally correct use of English. There are various rules documented in various dictionaries and grammar/style guides, and reinforced by teachers and higher-class people of various societies, but those are descriptive, after-the-fact illustrations that follow the evolving language, not the other way around.
It's one thing to say that a child's usage of language is incorrect because they haven't learned it yet, within a certain cultural context. It's another thing entirely to presume that your region's usage of English is the only "correct" one. There's no such thing.
Examples (American vs British):
"Data is" vs "data are"
"Do you have a car?" vs "Have you got a car?"
"I already saw that film" vs "I've already seen that film" etc.
color vs colour, trunk vs boot, etc. more examples here: https://www.thoughtco.com/differences-between-american-and-b...
For the blog title in question (which isn't an American vs British difference, to be clear, but possibly an Indian English construction -- not sure), the sentence is perfectly clear, with or without the "did". There isn't some weird ambiguity about it, especially in the context of a tech blog. I agree that it sounds strange to American/British ears, but it's not really "incorrect", it's just a regional stylistic difference -- or so we surmise. Give it 50 years' worth of population growth and migrations, and that construction might very well become the more common one, leaving the American and British versions sounding quaint and foreign.
Now, maybe a related question is whether the writer should've written in the American style, kinda like how many foreign English singers will emulate an American accent. In that case it's not a question of correctness anymore, but of adapting your communications for a cross-cultural context and targeting a specific group of English users and their traditions. I'm not arguing that the author should or should not have done that, just that their choice wasn't "incorrect". Just different from what we're used to.
We get it languages diverge and branch into different languages, that's how they have evolved. French English and German and Spanish all have common ancestry (right?).
Problem is if it's not clear (to your audience) which language you are using. I'm not saying that is what happened here. I'm concerned about the general principle "it does not matter really". Yes it doesn't, so much that we should nitpick about it. But it does in giving us guidance as to what we should strive towards. If the audience is international it is best to not use use a specific dialect from a specific region of the world.
It's not "incorrect" or "correct". The question is would it be easier to transfer the information you are trying to transfer by using the most common, most shared dialect of English.
Problem is if it's not clear (to your audience) which language you are using. I'm not saying that is what happened here. I'm concerned about the general principle "it does not matter really". Yes it doesn't, so much that we should nitpick about it. But it does in giving us guidance as to what we should strive towards. If the audience is international it is best to not use use a specific dialect from a specific region of the world.
It's not "incorrect" or "correct". The question is would it be easier to transfer the information you are trying to transfer by using the most common, most shared dialect of English.
There isn't a strict "most common" dialect of English, it just depends on audience and context. Wikipedia deals with this all the time when articles are written in a mix of Britishisms and American English and some later editor tries to normalize it to one or the other, but then some other English user adds another construction that's in neither, and so forth.
It maybe used to be the case that the internet was primarily American English, but that can't be assumed anymore.
When a British person writes "colour", it looks wrong to me but it's not my place to "correct" them. That would be rude, dumb, arrogant, and ignorant all at once. "Two countries divided by a common language", so they say, except now there are far more than two. Blame colonialism, I guess?
As for the blog audience, maybe they were targeting an international viewership, or even a primarily Indian one (their immigrant tech peers)? In that case, it would be weird to speak American instead of their native English. Like whatever the Indian version of an Uncle Tom would be.
In this case I think this construction is both common enough and clear enough that maybe it's the Americans who should get used to it, rather than demanding that a country five times bigger change their habits to meet our preferences...
It maybe used to be the case that the internet was primarily American English, but that can't be assumed anymore.
When a British person writes "colour", it looks wrong to me but it's not my place to "correct" them. That would be rude, dumb, arrogant, and ignorant all at once. "Two countries divided by a common language", so they say, except now there are far more than two. Blame colonialism, I guess?
As for the blog audience, maybe they were targeting an international viewership, or even a primarily Indian one (their immigrant tech peers)? In that case, it would be weird to speak American instead of their native English. Like whatever the Indian version of an Uncle Tom would be.
In this case I think this construction is both common enough and clear enough that maybe it's the Americans who should get used to it, rather than demanding that a country five times bigger change their habits to meet our preferences...
I don't know what's even considered correct in Indian English, but it tracks with some of the non-standard word ordering I see working with folks from the subcontinent.
This seems to mostly rephrase things from Airbnbs engineering blog at the time? https://medium.com/airbnb-engineering/react-native-at-airbnb... (part 1 of 5)
Thank you! The linked article explains their problems with RN much better.
Seems strange to write an article about why they switched without mentioning one of the main technical reasons Airbnb said themselves:
> Many of the difficulties we encountered were due to the hybrid model approach we took
They had about 220 screens in RN, 880 native screens total. They found it difficult to juggle that, essentially developing 3 platforms instead of 2.
Personally I prefer to do pure RN, with native extensions. Not a lot of native screens, because yes, you then are developing your targets plus RN.
Also keep in mind they were early adopters and they probably had to do a lot of heavy lifting. RN has matured a lot since then, both thanks to Airbnb and to the rest of the community.
> Many of the difficulties we encountered were due to the hybrid model approach we took
They had about 220 screens in RN, 880 native screens total. They found it difficult to juggle that, essentially developing 3 platforms instead of 2.
Personally I prefer to do pure RN, with native extensions. Not a lot of native screens, because yes, you then are developing your targets plus RN.
Also keep in mind they were early adopters and they probably had to do a lot of heavy lifting. RN has matured a lot since then, both thanks to Airbnb and to the rest of the community.
That always surprised me a bit, because part of the initial intent of react native was to be hybrid. Facebook had a lot of php developers that they wanted to enable to be able to write mobile screens. Not the core experiences, which you wanted dedicated mobile folks to write native for performance/transitions, but secondary things like the reporting flow.
But it probably takes a dedicated developer focused team to manage hybrid. And in terms of pure react native…I don’t know if react native is now able to feel as good as a native app, but even for a few years after Airbnb’s post react native would not have been up to the task of rendering all the little animations and transitions that Airbnb had in their mobile app.
(Though these days I would 100% write a new, less fancy mobile app in react native/expo - it’s constantly improved throughout the years)
But it probably takes a dedicated developer focused team to manage hybrid. And in terms of pure react native…I don’t know if react native is now able to feel as good as a native app, but even for a few years after Airbnb’s post react native would not have been up to the task of rendering all the little animations and transitions that Airbnb had in their mobile app.
(Though these days I would 100% write a new, less fancy mobile app in react native/expo - it’s constantly improved throughout the years)
I think it depends on how you structure your code and your team. RN is mixed into the Facebook apps and they do quite well.
Generally a small team is going to do pure RN, with limited extensions and views. A larger team you really have to know how to split everyone up while still being able to bridge views simply.
JS triggered animations and other native features are performant now via JSI, nowadays most people use react-native-reanimated to achieve this.
I think most of the issues Airbnb had were growing pains of RN and have long been resolved.
Generally a small team is going to do pure RN, with limited extensions and views. A larger team you really have to know how to split everyone up while still being able to bridge views simply.
JS triggered animations and other native features are performant now via JSI, nowadays most people use react-native-reanimated to achieve this.
I think most of the issues Airbnb had were growing pains of RN and have long been resolved.
Assimilating something native into a serviceable React Native component isn't particularly difficult, but reimplementing that component from scratch on one or two other unfamiliar platforms (otherwise, why are you using React Native?) might be expensive.
Related:
Airbnb Is Moving Off of React Native (2018) - https://news.ycombinator.com/item?id=23558730 - June 2020 (61 comments)
Airbnb is 'sunsetting' React Native, reinvesting all efforts back into native - https://news.ycombinator.com/item?id=17365451 - June 2018 (20 comments)
React Native at Airbnb - https://news.ycombinator.com/item?id=17348215 - June 2018 (248 comments)
Airbnb Is Moving Off of React Native (2018) - https://news.ycombinator.com/item?id=23558730 - June 2020 (61 comments)
Airbnb is 'sunsetting' React Native, reinvesting all efforts back into native - https://news.ycombinator.com/item?id=17365451 - June 2018 (20 comments)
React Native at Airbnb - https://news.ycombinator.com/item?id=17348215 - June 2018 (248 comments)
Made a relatively complex React Native app last year, and gained a lot of perspective on it.
I don't think Airbnb made a bad choice at the time they did it. They tried embracing a technology that was at the time half baked. When you are operating at the scale of Airbnb where there are lots of engineering hurdles and a high quality bar, it's challenging to absorb nascent tech.
Since then a couple things have happened:
- Devices have gotten much faster and this has covered up a nice chunk of the performance tax that existed previously
- The framework has gotten more mature and performant
Having said that, there are still a number of rough patches so it really depends on what you need. Shopify, for example, seems to be quite happy with it. But as usual, it depends on what you're making. If you want something with heavy animations, lots of gestures / high touch responsiveness, really fast startup time, etc. - RN might not be the best choice (but still way better than it was before because of lots of great work). If you're creating something that is more on the CRUD side, RN is more than suitable and a great choice.
I don't think Airbnb made a bad choice at the time they did it. They tried embracing a technology that was at the time half baked. When you are operating at the scale of Airbnb where there are lots of engineering hurdles and a high quality bar, it's challenging to absorb nascent tech.
Since then a couple things have happened:
- Devices have gotten much faster and this has covered up a nice chunk of the performance tax that existed previously
- The framework has gotten more mature and performant
Having said that, there are still a number of rough patches so it really depends on what you need. Shopify, for example, seems to be quite happy with it. But as usual, it depends on what you're making. If you want something with heavy animations, lots of gestures / high touch responsiveness, really fast startup time, etc. - RN might not be the best choice (but still way better than it was before because of lots of great work). If you're creating something that is more on the CRUD side, RN is more than suitable and a great choice.
[deleted]
I am not a front end developer, but when reading about these kinds of switches in front end frameworks... isn't that an incredible amount of work? How could it be justified? It must have created some really serious unsolvable problems in order to switch right? You would think it would be easier to improve the existing one instead of switching, but who knows. Either that or the amount of front end code really isn't as much as I imagine.
Probably not “unsolvable” but I imagine not well documented and a million footguns to make RN work in the scenarios described in the article.
This would entail working in a new fork of React Native to add implementations for the underlying Android and iOS SDKs where the native functionality exists. That might include language bindings at multiple levels, e.g. from JS to Java, and potentially Java to C if NDK is required (and that’s just for android)
In my experience, writing those bindings is very bug-prone and user-friendly documentation can be hard to come by.
We wrote some Python extensions in C for a very simple functionality where we wanted native speed. Could definitely see it having been easier to just write the dang program in C, since you had to understand C as well as some fundamentals about how the Python runtime works in C along with its special data types and execution patterns. And if they mainly hire app developers and not interpreter/OS developers that could become entirely untenable
This would entail working in a new fork of React Native to add implementations for the underlying Android and iOS SDKs where the native functionality exists. That might include language bindings at multiple levels, e.g. from JS to Java, and potentially Java to C if NDK is required (and that’s just for android)
In my experience, writing those bindings is very bug-prone and user-friendly documentation can be hard to come by.
We wrote some Python extensions in C for a very simple functionality where we wanted native speed. Could definitely see it having been easier to just write the dang program in C, since you had to understand C as well as some fundamentals about how the Python runtime works in C along with its special data types and execution patterns. And if they mainly hire app developers and not interpreter/OS developers that could become entirely untenable
The front-end should be just the (user-) interface. The main logic is best kept on the server.
In the early days of the web there was such a thing as "text-based browser". (Don't recall its name right now). You could interface with the WWW via a text-console. The point was user-interface shouldn't be the main thing of the application, it should be just a shell around it.
In the early days of the web there was such a thing as "text-based browser". (Don't recall its name right now). You could interface with the WWW via a text-console. The point was user-interface shouldn't be the main thing of the application, it should be just a shell around it.
Most of these stories of companies dumping react native are from apps that didn't start out as react native. Adding react native to an existing app and organisation is MUCH harder than using react-native or full-native from scratch
Not only on the engineering aspects, but on the people as well. You will have a lot of attrition with devs not wanting to switch
I would say that the only 100% safe way to succeed in this endeavour is to fire ALL your native developers and rewrite the app from scratch instead of introducing RN gradually. Obviously that is impossible for any app that is already big
So unless you are willing to do a full rewrite and fire all your native developers and hire some people with RN knowledge (you need at least a few people with RN specific knowledge even if you have web-only devs) you will most likely fail
Also if you DO want to share code between your RN apps and your web app that is ALSO somewhat harder and might need significant rewrites of your web codebase
So in short, DONT DO IT, it is very unlikely you have the in-house experience and political will within your company to pull it off
Not only on the engineering aspects, but on the people as well. You will have a lot of attrition with devs not wanting to switch
I would say that the only 100% safe way to succeed in this endeavour is to fire ALL your native developers and rewrite the app from scratch instead of introducing RN gradually. Obviously that is impossible for any app that is already big
So unless you are willing to do a full rewrite and fire all your native developers and hire some people with RN knowledge (you need at least a few people with RN specific knowledge even if you have web-only devs) you will most likely fail
Also if you DO want to share code between your RN apps and your web app that is ALSO somewhat harder and might need significant rewrites of your web codebase
So in short, DONT DO IT, it is very unlikely you have the in-house experience and political will within your company to pull it off
I have personally made an ios+android react native app that used native maps functionality (google maps from google cloud services in android and apple maps in ios). Not even using expo
all the app was 100% react native EXCEPT the maps
it was a bit awkward, but not really a HUGE issue (note this was in 2016, it seems it is easier now to integrate native code and expo today exposes a lot more functionality without needing native code). The main problem is that, for the very specific parts you need to do native you do need native developers (I did the android native part as I was a bit experienced with android native, but we had to get help for the ios part)
Honestly the hard part was making ios and android maps feature-compatible. We wanted heatmaps and apple maps and google maps have completely different algorithms to render heatmaps
Honestly the hard part was making ios and android maps feature-compatible. We wanted heatmaps and apple maps and google maps have completely different algorithms to render heatmaps
> Now, one resort for them would be to use Airbnb’s web application on the web browsers of their phones, which doesn’t make much sense.
I never understood why one needs 20 separate apps (100 Mb each) instead of just using a single standard pre-installed web browser. Mobile UI everywhere is fine and functionality is the same.
I never understood why one needs 20 separate apps (100 Mb each) instead of just using a single standard pre-installed web browser. Mobile UI everywhere is fine and functionality is the same.
Web browsers don’t let you track users the way mobile apps do.
Did they actually dump it in the end though or just announce it?
Appbrain still lists React Native in the list of SDKs for the current version.
https://www.appbrain.com/app/airbnb/com.airbnb.android
Seems if it was all that bad it would be gone by now.
Appbrain still lists React Native in the list of SDKs for the current version.
https://www.appbrain.com/app/airbnb/com.airbnb.android
Seems if it was all that bad it would be gone by now.
TL;DR:
* React Native caused problems for AirBnB because they needed more complete and efficient support for native geolocation/mapping features than RN provides
* More generally, frameworks like RN and Flutter are a good choice if your app doesn't need extensive/precise/efficient access to native platform features and a bad choice if it does
* React Native caused problems for AirBnB because they needed more complete and efficient support for native geolocation/mapping features than RN provides
* More generally, frameworks like RN and Flutter are a good choice if your app doesn't need extensive/precise/efficient access to native platform features and a bad choice if it does
That's accurate to the article but not accurate to modern RN or even most of Airbnb's reasoning when they switched.
With JSI now you can get efficient access to native platform features. Before you were able to bridge pretty much any native feature with a native view or extension, but you were bottlenecked by the JS bridge. Nowadays you can use JSI for anything intensive.
As far as Airbnb, it was more they were trying to mix 80% native views with 20% RN views and they found they were doing more work than pure native. If you do mostly RN though you don't have that problem.
With JSI now you can get efficient access to native platform features. Before you were able to bridge pretty much any native feature with a native view or extension, but you were bottlenecked by the JS bridge. Nowadays you can use JSI for anything intensive.
As far as Airbnb, it was more they were trying to mix 80% native views with 20% RN views and they found they were doing more work than pure native. If you do mostly RN though you don't have that problem.
> With JSI now you can get efficient access to native platform features. Before you were able to bridge pretty much any native feature with a native view or extension, but you were bottlenecked by the JS bridge. Nowadays you can use JSI for anything intensive.
JSI indeed makes things more efficient, but you still have to maintain code to translate between native and JS.
JSI indeed makes things more efficient, but you still have to maintain code to translate between native and JS.
Yes, but only the minimal to provide that specific native functionality, instead of a full blown native app.
Unless you're doing something uncommon, there's most likely a 3rd party lib for that functionality.
But yes, if you want to use a native platform feature that the standard lib doesn't expose of course you need native code either by you or someone else, that's the flexibility of React Native.
Unless you're doing something uncommon, there's most likely a 3rd party lib for that functionality.
But yes, if you want to use a native platform feature that the standard lib doesn't expose of course you need native code either by you or someone else, that's the flexibility of React Native.
* More generally, frameworks like RN and Flutter are a good choice if your app doesn't need extensive/precise/efficient access to native platform features and a bad choice if it does
+1, if you only ever do superficial platform features RN isn't a problem. However if you want to implement the platform features, like Widgets, Siri/Shortcuts support, Apple Watch support, Spotlight search integration now you're going to start having to maintain extensive bridges to communicate between native and JS.
+1, if you only ever do superficial platform features RN isn't a problem. However if you want to implement the platform features, like Widgets, Siri/Shortcuts support, Apple Watch support, Spotlight search integration now you're going to start having to maintain extensive bridges to communicate between native and JS.
I’m not familiar with RN ecosystem specifically but in the Flutter universe at least getting down deep into native code is built in with well defined and first class extension points. Not sure the point you’re making actually applies unless maybe I misunderstand something.
When your company is making billions of dollars a year from mobile apps it makes sense to have native teams. React Native is for development efforts with fewer resources.
> Now, one resort for them would be to use Airbnb’s web application on the web browsers of their phones, which doesn’t make much sense.
Why?
A proper web app would be sufficient.
Why?
A proper web app would be sufficient.
[deleted]
I don't mean to be too edgy here, but it has to be said.
Why does anyone care what technology AirBnB uses for their mobile apps or websites?
AirBnB is an incredibly successful company because of their marketing, ability to scale, and the fact they offered the right thing at the right time.
Their website however, is slow and clunky. Their apps are slow and clunky.
What about that side of their company is worth emulating?
Why does anyone care what technology AirBnB uses for their mobile apps or websites?
AirBnB is an incredibly successful company because of their marketing, ability to scale, and the fact they offered the right thing at the right time.
Their website however, is slow and clunky. Their apps are slow and clunky.
What about that side of their company is worth emulating?
I mean you've made the fantastic point for why people care already.
People care especially if they feel a very successful business has slow and clunky apps. It's research.
How did they end up in the position they're in? What good/bad decisions do they feel they made?
Obviously it's interesting to people in the space. Where is anyone saying it's because they want to emulate it?
People care especially if they feel a very successful business has slow and clunky apps. It's research.
How did they end up in the position they're in? What good/bad decisions do they feel they made?
Obviously it's interesting to people in the space. Where is anyone saying it's because they want to emulate it?
But my point is the success of airbnb clearly had very little to do with the quality of their mobile and web apps. It borders on irrelevant.
It'd be a bit like customer service people diving into how google does it because they're so successful. They are. But not because of their customer service.
It'd be a bit like customer service people diving into how google does it because they're so successful. They are. But not because of their customer service.
[deleted]
That said, I find it perfectly represents about 90% of React Native evangelism: someone who has never shipped an app copying and pasting talking points to shill their YouTube channel.