3 ms·

>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 Ion

by dimmke 4y ago

>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-settings-tonsky 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-substring-work-in-swift 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.

kuschku 4y ago
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.
- wiseowise 4y ago
  It works just fine if you actually profile and see what are the bottlenecks.
  - kuschku 4y ago
    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).
programmarchy 4y ago
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.
dwaite 4y ago
> 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.
- dimmke 4y ago
  >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 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 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 https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.
tled 4y ago
> 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

by dimmke 4y ago

kuschku 4y ago

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.

wiseowise 4y ago
It works just fine if you actually profile and see what are the bottlenecks.
- kuschku 4y ago
  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).

programmarchy 4y ago

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.

dwaite 4y ago

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

dimmke 4y ago
>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 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 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 https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.

tled 4y ago

> 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