Hacker News Reader

Comment by s_y_n_t_a_x | Hacker News Reader

It baffles me that people think duplicating application code for every device is the way to go. Cross platform can be done correctly. I'm working on a stack that can natively target Windows, Mac, Linux, Android, iOS, MacOS, and Web. I couldn't imagine duplicating my code for each one of these devices. If something special needs to be done, I write an extension.

I have a feeling posts like these get upvoted because developers who make the native apps want to keep their jobs. But those developers will always be needed for the native bridges, just not as many of them.

View on HN

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.

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.

> 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

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

1: https://github.com/leecade/react-native-swiper

2: https://github.com/FaridSafi/react-native-gifted-chat

3: https://github.com/jeanregisser/react-native-slider

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.

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

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

There's a lot of valid points from native advocates though. Like differences in touch features, various sensor APIs, Firebase etc. These may not be serious considerations in simple apps but they make major difference to both the end user as well as the codebase/developer in larger scale / more serious apps.

That said, myself I still write Flutter too, having jumped ship from React Native.

I use React Native so there is no difference in touch features etc. It's native components bridged by JS.

But on React Native there are major platform differences that you also have to bridge. Moreover, as the platform essentially uses each platform's native components through that JSON serialized bridge you'll have UI inconsistencies between platforms when sharing code.

I built upon ReactXP with helps with that. A project from Microsoft that powers Skype for Web.

But yes, there can be differences, but that doesn't mean give up and write the application code 6x.

I took this as an argument for a thin, or at least thinner, client. If something is complicated and costly to maintain - shouldn't it move to the server? What complicated processes are you doing on-device that couldn't be done somewhere else & fronted by an API?

Anything you want to run locally without being tethered to always-on connectivity, for one. Or just anything you want to run without network latency.

Which framework are you using for this?

React Native

Done correctly != react native. I've had to shut down and migrate 3 RN projects because of how much of a mess it is. It's not even 1.0 and is a horrible choice for important apps.

Sadists created it

Then you used it wrong, sorry.

Reply on news.ycombinator.com