3 ms·

I'm very much in the cross platform is a bad idea camp. It's fine for sharing business logic and other non-UI code, but having tried several cross platform UI k

I'm very much in the cross platform is a bad idea camp. It's fine for sharing business logic and other non-UI code, but having tried several cross platform UI kits I've never found it to work well. Cross platform UI always ends up compromising on the native UIs strengths and uniqueness resulting in poor UX, poor accessibility, unaccceptable resource usage, bloated binary size etc. Just a few concrete examples: - Non standard UI/UX is super common because cross platform UI targets the lowest common denominator. Flutter is the quintessential example of this, it throws away all native UI support and renders everything from scratch with low level graphics. In React Native I've observed several cases where iOS UI has been re-implemented, poorly, in Javascript and shipped on Android and iOS. - Poor accessibility. Native iOS apps get a lot of accessibility for free because Apple has done a great job, with RN and especially Flutter you don't get this benefit. - Resource consumption. Electron is terrible in this regard as is the common meme. React Native runs a JS VM for every app which surely has a negative impact on both battery and performance. - Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB. It's certainly possible to build great UX with cross platform UI frameworks, but the amount of work required to do it well starts to get into the territory where you are better of just doing it natively in the first place.

s_y_n_t_a_x 7y ago
React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times. - React Native you most certainly do get accessibility. - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth it to prevent having to learn X different languages for each platform. - The app size evens out, but yes the minimal is higher. However many apps are much larger than 20MB, it's better than other cross platform solutions In no way are any of these things so bad where I would duplicate my code 6 times and then maintain them throughout the life of the project. That's just crazy.
- K0nserv 7y ago
  > React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times. Yes a great strength of React Native is that it still leverages the native UI kits and makes it possible to do so when building custom components. My comment wasn't about my experience, in fact I've built numerous bridged components in RN, but and observation about the react native community. In fact one of the most crucial lessons I've gathered when working with RN is that you must have both iOS and Android experts in your team to build good apps with RN successfully. Here's just a few examples of popular 3rd party components(from awesome-react-native[0]) that are problematic in my eyes: - react-native-swiper[1]. Completely custom JS implementation with a "iOS"y look. 8k stars - react-native-gifted-chat[2]. Large completely custom JS implementation of chat UI. 8k stars - react-native-slider[3]: A pure JS implementation of a slider. 1k stars > - React Native you most certainly do get accessibility. My point wasn't that it can't be done, but that it requires significantly more work that, let's face it, most developers will not do. With native UI you get a lot more for free which results in a better user experience for everyone. See https://news.ycombinator.com/item?id=20709259 https://news.ycombinator.com/item?id=20709259 > - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth it to prevent having to learn X different languages for each platform. I agree it's a tradeoff and to be fair I don't have more than a hunch that running a JS VM is bad for energy and resource usage. The tradeoff is distinctively on the user's expense in favour of the developers. As developers shouldn't we be making tradeoffs that benefit our users instead? > - The app size evens out, but yes the minimal is higher. However many apps are much larger than 20MB, it's better than other cross platform solutions Yes many native apps do grow quite large too, my point is the default. The most basic RN, but especially Flutter, app is much larger than the native counterpart. Again a distinct tradeoff on the user's experience in favour of the developer. 0: https://github.com/jondot/awesome-react-native#components https://github.com/jondot/awesome-react-native#components 1: https://github.com/leecade/react-native-swiper https://github.com/leecade/react-native-swiper 2: https://github.com/FaridSafi/react-native-gifted-chat https://github.com/FaridSafi/react-native-gifted-chat 3: https://github.com/jeanregisser/react-native-slider https://github.com/jeanregisser/react-native-slider
scarlac 7y ago
Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them: > - Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB. I have working examples of fairly complex production applications that are <=10 MB on iOS. > - Poor accessibility. Native iOS apps get a lot of accessibility for free because Apple has done a great job, with RN and especially Flutter you don't get this benefit. False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available.
- K0nserv 7y ago
  > I have working examples of fairly complex production applications that are <=10 MB on iOS. Fair, the problem isn't as bad for RN, for Flutter it's still very bad though. > False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available. The ability to tag elements is only a very simple basic requirment to get accessibility right. My point was more that if you use UIKit you get significant levels of accessibility for free. Just as a quick example I did a quick ddg search for "react native how to create custom button" and all 5-7 top results that I looked at failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader. Yes you can still do accessibility right with RN, but it's not the easy to get it right be default and most app developers will not do this on their own.
  - scarlac 7y ago
    > failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader Appreciate that you looked into it. On iOS and you do not need to set anything to become screen reader friendly _in React Native_. The default TouchableOpacity with a simple piece of text inside of it will become focusable and iOS will read the text aloud for you. This works because RN uses native elements unlike Flutter, Electron, and others. In fact, I took you up on the claim that it wouldn't read correctly. I used my app just now which has never been tested or optimized for accessibility. Covered my eyes and began navigating. It works just fine! All tappable elements are indeed read aloud. I was able to navigate through the app settings, change them, go back, and reload other screens, navigate to the updated content, and perform actions on the new content. Please do not put RN in the same bucket as Flutter or Electron. They are fundamentally differently.

s_y_n_t_a_x 7y ago

React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times. - React Native you most certainly do get accessibility. - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth it to prevent having to learn X different languages for each platform. - The app size evens out, but yes the minimal is higher. However many apps are much larger than 20MB, it's better than other cross platform solutions In no way are any of these things so bad where I would duplicate my code 6 times and then maintain them throughout the life of the project. That's just crazy.

K0nserv 7y ago
> React Native can wrap any native component and bridge it into your app. If you had bad experience with a 3rd party component, that's not RN's fault, build your own extensions you need, but for the most part you just need the core. It's still easier than rebuilding your app X times. Yes a great strength of React Native is that it still leverages the native UI kits and makes it possible to do so when building custom components. My comment wasn't about my experience, in fact I've built numerous bridged components in RN, but and observation about the react native community. In fact one of the most crucial lessons I've gathered when working with RN is that you must have both iOS and Android experts in your team to build good apps with RN successfully. Here's just a few examples of popular 3rd party components(from awesome-react-native[0]) that are problematic in my eyes: - react-native-swiper[1]. Completely custom JS implementation with a "iOS"y look. 8k stars - react-native-gifted-chat[2]. Large completely custom JS implementation of chat UI. 8k stars - react-native-slider[3]: A pure JS implementation of a slider. 1k stars > - React Native you most certainly do get accessibility. My point wasn't that it can't be done, but that it requires significantly more work that, let's face it, most developers will not do. With native UI you get a lot more for free which results in a better user experience for everyone. See https://news.ycombinator.com/item?id=20709259 https://news.ycombinator.com/item?id=20709259 > - Running a JS VM isn't that bad, but it is a tradeoff. Imo it's completely worth it to prevent having to learn X different languages for each platform. I agree it's a tradeoff and to be fair I don't have more than a hunch that running a JS VM is bad for energy and resource usage. The tradeoff is distinctively on the user's expense in favour of the developers. As developers shouldn't we be making tradeoffs that benefit our users instead? > - The app size evens out, but yes the minimal is higher. However many apps are much larger than 20MB, it's better than other cross platform solutions Yes many native apps do grow quite large too, my point is the default. The most basic RN, but especially Flutter, app is much larger than the native counterpart. Again a distinct tradeoff on the user's experience in favour of the developer. 0: https://github.com/jondot/awesome-react-native#components https://github.com/jondot/awesome-react-native#components 1: https://github.com/leecade/react-native-swiper https://github.com/leecade/react-native-swiper 2: https://github.com/FaridSafi/react-native-gifted-chat https://github.com/FaridSafi/react-native-gifted-chat 3: https://github.com/jeanregisser/react-native-slider https://github.com/jeanregisser/react-native-slider

scarlac 7y ago

Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them: > - Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB. I have working examples of fairly complex production applications that are <=10 MB on iOS. > - Poor accessibility. Native iOS apps get a lot of accessibility for free because Apple has done a great job, with RN and especially Flutter you don't get this benefit. False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available.

K0nserv 7y ago
> I have working examples of fairly complex production applications that are <=10 MB on iOS. Fair, the problem isn't as bad for RN, for Flutter it's still very bad though. > False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available. The ability to tag elements is only a very simple basic requirment to get accessibility right. My point was more that if you use UIKit you get significant levels of accessibility for free. Just as a quick example I did a quick ddg search for "react native how to create custom button" and all 5-7 top results that I looked at failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader. Yes you can still do accessibility right with RN, but it's not the easy to get it right be default and most app developers will not do this on their own.
- scarlac 7y ago
  > failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader Appreciate that you looked into it. On iOS and you do not need to set anything to become screen reader friendly _in React Native_. The default TouchableOpacity with a simple piece of text inside of it will become focusable and iOS will read the text aloud for you. This works because RN uses native elements unlike Flutter, Electron, and others. In fact, I took you up on the claim that it wouldn't read correctly. I used my app just now which has never been tested or optimized for accessibility. Covered my eyes and began navigating. It works just fine! All tappable elements are indeed read aloud. I was able to navigate through the app settings, change them, go back, and reload other screens, navigate to the updated content, and perform actions on the new content. Please do not put RN in the same bucket as Flutter or Electron. They are fundamentally differently.