91–100 of 136 posts
> 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.
Earlier quoted context omitted.
> 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 (an…
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 l…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 a…
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.
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 e…
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 e…
> 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 (an…
Earlier quoted context omitted.
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 a…
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.
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 e…
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 thi…
Earlier quoted context omitted.
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.
Where would you host them?
> 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 licensi…