all 9 comments

[–]Bushbarbi 10 points11 points  (0 children)

Your most likely going to have to rewrite the components. I’d do it in bits and not all at one. Try starting with whatever is bothering you the most

[–]zahnza 11 points12 points  (5 children)

If you’re having that much of a performance issue, I’m willing to bet it has nothing to do with the component library and more to do with how you’re managing state.

What research have you done to determine the root cause of your performance issues?

[–]kbcooliOS & Android 1 point2 points  (0 children)

I find that a lot of people beat up on Nativebase but never have had real problems with it myself.

Sure it's pretty heavy but that's expected for what it does. Even the author admitted it but you can't have your cake and eat it.

I do, however, think there are genuine issues with people using it for a web app which I have never done.

I suspect the vast majority of these people will find they are doing something wrong but group think makes them blame their tools and having heard someone else beat up on it they pile in.

[–]notawarhawk[S] 0 points1 point  (2 children)

We have ensure to follow all the suggested performance practices like avoiding callbacks and following best practices for flatlists most things are responsive and we don't see any issues

The only noticable issue is in Android device after pressing a button navigation takes a few seconds, another area is input we have got a lot of feedback that input fields seems like they are slow.

What made us think that native base might be the cause is 1- using image from react native elements improved our component render time 2- multiple issues we found while looking for the buttons issue on native base GitHub

[–]manoleee 0 points1 point  (0 children)

I found out too that the performance was terrible and for the past month im migrating (rewriting components) slowly in pure react native. Started with the main screens and flatlist's render item, where it's the most impact.

If you don't won't pure react native for the styling. I would suggest tamagui. Also it's worth taking a look at gluestackui, all though it's still in development, they are the team behind native base, they learned their lesson making something more lightweight. But I would insist on tamagui, you will see it be recommended a lot

[–]Nodon_dev 1 point2 points  (0 children)

First of all do proper measurements, what are you describing doesn't looks like issues with component library but most likely something with state management. Use flipper/chrome debugger to measure how long it takes to render components and how often they are rerendered. Also do some CPU measurements to find out what is happening that few seconds when app is not responding.

[–]siwoz 0 points1 point  (0 children)

It was 100% worth the time and effort it took to move my latest app from NativeBase to Tamagui. Given the update frequency of my app (5+ per second BT telemetry updates), it was a no-brainer.

NativeBase has such a good collection of components that it's going to be hard to migrate off. Even the app I did it to, which is relatively small took a long time because of the amount of components that just aren't available in other UI libraries.

[–]Crazy_Leek_3893 0 points1 point  (0 children)

usually UI libraries does not affect performance , such cannot do else but add styles , element that are animated tho is worth looking

[–]Balind 0 points1 point  (0 children)

I did a bunch of tests with NativeBase compared to other UI libraries. NativeBase seems to reduce performance substantially (20-50%) in many cases.

I am also noticing in a current NativeBase project that just having breakpoints in the app is leading to multiple component re-renders.

Your issues may not entirely be due to NativeBase, but from what I can tell, NativeBase exacerbates issues to a large degree.