
Show HN: React Native scrollable bottom sheet native animations gestures 60FPS - rgommezz
https://github.com/rgommezz/react-native-scroll-bottom-sheet
======
0xDEEPFAC
You mean our modern super-computer level machines with gigabytes of RAM and
GHz level processors can actually show basic animations at 60 FPS!? Wow!

RIP native development, long live non-native native development?

~~~
tenaciousDaniel
As someone with a shallow grasp of rendering in general, it amazes me that we
can achieve near 60fps for these insanely detailed games with tons of 3D
objects, and yet we find it difficult to do the same with 2D UI rendering.

~~~
gdubs
The bottleneck is typically CPU <-> GPU transfer. If your UI is processing
data on the CPU, that information has to be shuttled over the GPU. On a
platform like iOS (or MacOS) the core text rendering frameworks are built on
the CPU. Text rendering, for instance, is complicated and despite a lot of
experience with both native iOS development and recently with compute shader
development, I couldn’t really throw out an estimate of how involved it would
be to recreate something like CoreText fully on the GPU. And unless you give
up CPUs, you’re still left with the problem of transferring data back and
forth.

More and more gets ported to the GPU through parallelized algorithms, and
smart GPU memory usage — but CPUs still offer a lot in their ability to do
generalized computing.

This is why as I’ve gotten older I’ve come to really respect Computer Science
fundamentals; the more you understand how to make the most of resource
constraints — whether time, or memory, etc — the more magic you can make.

~~~
izacus
Native framework (I'm familiar with Android) will just issue a translation
coordinate change for the rendered view in this scroll. So there's no CPU
<\--> GPU transmission here because the view is already rendered in a texture
and compositor will just move it a bit.

If web frameworks really reupload the whole view to GPU on each frame, it's no
wonder all apps run like arse and burn battery.

~~~
kall
They don‘t, but you also can‘t prepare (and download) a whole list of (tens
of) thousands of items, which is why you only do the parts that are going to
be scrolled in next. Both react native and standard native apps do this, but
standard native apps are much better at it.

------
tcmb
> Show HN: React Native scrollable bottom sheet native animations gestures
> 60FPS

What a trainwreck of a headline. It sounds like someone fell asleep on the
push button of a 'modern web dev' phrase generator.

------
ericwood
This seems to be one of those react native holy grails; I've been building an
emoji picker similar to the one Slack uses but it's been a chore! I recently
discovered Modalize, and it's working fairly well, but for a long SectionList
performance was abysmal; there's so many levers to pull with any of those
VirtualizedList components it's tough to tell if it was me or modalize.

Excited to check this out!

~~~
bhl
Are you building an emoji picker with each emoji per row, or multiple emojis
per row? I'm wondering since there's virtualization libraries for lists, but
not for grids.

~~~
411111111111111
If flexbox taught me anything, it's that a grid is a list of lists.

~~~
k__
Don't let the CSS-Grid people hear this :D

------
philplckthun
There’s a small asterisk to this in that it says “No Native Dependencies” .”
This is true for Expo which comes with a couple of libraries for Reagt Native
with native bindings to iOS and Android (and also for Web)

A lot of fluid animations and interactions in React Native are finally not
that much of a hurdle anymore thanks to react-native-gesture-handler and
reanimated, which are brilliant abstractions that fully offload work to the
native thread and don’t interrupt interactions due to work on the main thread.

React Native’s own primitives, like Animated, can only go so far until they
require intervention or activation from the main thread.

These libraries by Software Mansion have basically become a “must have” for
creating compelling apps in React Native.

------
ex3ndr
Very cool!

I just really recommend to use our library
([https://github.com/openland/react-native-fast-
animations](https://github.com/openland/react-native-fast-animations)) for non
interactive animations like appearing and disappearing. Since iOS and Android
could block UI thread during initial layouting if there are a lot of content
and you will get dropped frames or just broken animation (if freeze will be
~200ms).

This is important since iOS actually rely that all animations are done via
Core Animation that could not be blocked by main thread and therefore a lot of
UI widgets are just slow on first view. Most iOS developers don't care if
instantiating view will take 50ms since you have 300ms budget for all
transition animations.

This library does same thing for Android by "hacking" native API the same way
as official Google Apps do. This is a shame that google not opening this API.

~~~
dep_b
We thought maintaining two platforms was too much, so we got React Native.

Now we have three to maintain.

~~~
ex3ndr
No problem, you write this code once and reuse everywhere and you fixing bugs
for all apps instead of hacking all by yourself for each platform. After
coding for more than 10 years RN approach is so much better than native one.

~~~
dep_b
I tried to work with React Native and while there are many things that
especially iOS development could learn from the developer experience apart
from the fact that it's a platform-on-platform (with the associated problems
the poster I initial replied to, I just can't get over the fact I'm working
with Javascript and everything related to it.

I have built native interfaces that would interface C# code, that was slightly
less pleasant as a developer experience while I would get a 100% native
experience for the user and a better programming language in return.

So what you gain in getting a singular code base for at least your logic and
data parts you lose because you're chasing bugs that would never happen if you
would have used a better programming language.

The average native project I've seen had 5-15 dependencies. The average React
Native project thousands and thousands of them.

~~~
ex3ndr
Our app is much better written in RN than the one i built in native code. RN
doesn't have native bugs - they are worked around unlike pure native
development when you have to live with them. Have you tried to customize
UINavigationController to run on every version of iOS? Almost all projects i
have seen eventually replaced it altogether with a custom implementation.

Typescript IS better programming language and much more powerful than, say
swift. I can't see whats so special about swift comparing to typescript. I was
coding for 5 years on swift and know what it is. Tests are much easier,
typesystem is much more powerful and flexible. Compilation times are instant
comparing to native.

Please, don't rant on JS ecosystem and "dependencies". To build native app you
download 30GB xcode, clang and god know how many different libraries and
runtimes. JS just not install them globally and 90% of deps are for
development only.

Our app have 700kb of compiled JS. I have NEVER ever able to fit my
kotlin/swift app to 700kb of compiled binary (excluding libraries).

~~~
sandGorgon
Wanted to get your thoughts on tuning for performance on RN.

We are native platform specialists..but have been seriously looking at RN and
Typescript.

App sizes is a definite concern since we build for Indian markets.

What about assets? Do they bloat up more than on native.

~~~
ex3ndr
I stopped measuring sizes unfortunatelly, since nowadays you can cut heavy
native part to pieces and deliver them separately and native part is out of my
concern. We use webrtc anyway, so it won't be super light.

I could recommend RN if you can tolerate slightly lower performance (because
of the stuff i mentioned earlier) and beware that infinite lists are absolute
shitshow (we built our own). If you are native specialists you can write
bindings by your own and replace only parts of the app with RN.

Assets are stored the same way as in native, not sure how you can do something
with them.

------
cosmotic
A+ job on a polished version of that interface element.

It's too bad it's an interface element that causes a lot of pain by covering
content and embracing dark patterns.

~~~
victorvation
In my opinion bottom sheets are actually a far superior experience to the
previous pattern of dialogs/modals or push screens:

\- The user doesn't lose their navigation stack because they can tell the
bottom sheet can be dismissed, they know where they "came from"

\- The user keeps visual context on whatever triggered the bottom sheet,
because they can still see what's behind it

\- The user doesn't get forcibly navigated away from whatever they were
browsing, they know that once whatever they're doing in the sheet is done,
they can "go back".

My only complaint is that Apple added them to stock apps in iOS 12, so many
iOS users got used to the pattern, but didn't provide an easy way to give the
same experience for developers which creating a need for libraries like this.

~~~
cosmotic
I'm not defending dialogs or modals, but at least with those (on a larger
screen) you have control over what hey cover.

I suspect most users wouldn't even know the bottom sheet is there nor how to
bring it up nor how to dismiss it had they brought it up.

The visual context on whatever is underneath is lost once the sheet is brought
up.

The user absolutely get forcibly navigated away; their context is shifted to
the new layer which is slapped on top of the other layer. I can't count the
number of times I either accidentally activated the bottom sheet or used it
then got lost.

Bottom sheets are like hamburger menus; they are rugs that UX designers sweep
all their baggage underneath.

------
Austin_Conlon
I wonder if Apple will release first-party API for this kind of UI in a month
at WWDC.

~~~
nxc18
It’s sorely needed at this point, it’s clearly a standard UI control now and
countless developer hours have been wasted on it.

I’ve got several apps on my phone (maps, DoorDash, google maps, etc) all doing
the same thing, but inconsistently and it’s infuriating. What makes iOS great
(IMO) is consistency in UI patterns with things like navigation controllers,
toolbars, etc. floating sheets are worthy of that treatment.

~~~
kall
especially frustrating because apple themselves have a good version of it (in
Maps, Shortcuts)

------
Kiro
> Also, it's 100% compatible with Expo.

What does this mean? I thought Expo was just tooling for React Native.

~~~
fknop
Expo comes with pre-installed native bindings. If you want to add native
bindings to your expo app you need to eject. This means it does not use any
native bindings not included in the Expo SDK.

------
julius_set
Lol at all the web dudes amazed by this, making this on native mobile is a
breeze (Android and iOS)

~~~
nxc18
Native iOS alone is a substantial project in its own right.
[https://github.com/SCENEE/FloatingPanel](https://github.com/SCENEE/FloatingPanel)

There are several of these implementations. I’ve recently had to implement
something similar in Xamarin.iOS. It isn’t a breeze.

~~~
LeoNatan25
60fps and gesture handling is a breeze on iOS. There is nothing impressive
about achieving this. We’ve had it for 13 years now on iPhones. We now have
120hz displays on iPads, and guess what, animations there are easy to achieve
too, at 120fps.

~~~
exogen
Maybe you should let the amateur devs at Facebook and Pinterest know how easy
it is? After all, they developed this entire framework in Objective-C to
address UI performance, and – shocker here – they consider 60fps a selling
point there, too.

[https://www.youtube.com/watch?v=8ngXakpE2x8](https://www.youtube.com/watch?v=8ngXakpE2x8)

I guess you probably have better insight than the devs of two of the most
popular native apps, though. Cheers!

~~~
julius_set
Yes I’ve worked at FAANG companies, and yes it’s great Instagram used
AsyncDisplayKit (which is archived by the way).

For most companies (maybe all), it’s not needed. Apple is doing a fantastic
job abstracting views into SwiftUI and Android team is doing the same with
Jetpack Compose.

Then what? More abstractions over abstractions to achieve 60 or 120 FPS
through another framework?

And this is not related to the OP post, making these bottom sheets is a
breeze. Literally:

1.) Custom ViewController with custom UIView as base view 2.) Add as child or
present over root controller 3.) Translate and animate custom base view from
bottom (top... left... whatever the hell you like)

~~~
kall
It‘s about as easy to do what you describe in react native without performance
issues, but like others have mentioned there is more to this pattern related
to scrolling content, snap points, interaction with the content behind it...

~~~
julius_set
What performance issues? You’re telling me the native implementation has
performance issues over RN?

------
yagodragon
meanwhile, I've made a small app with Flutter and loved it. Everything just
works. Install it in 10 minutes and you're good to go. In flutter everything
is a widget and creating your own widgets by composing other widgets makes so
much sense. Seriously, you have to try it to appreciate it. Dart is also nice
and easy for those familiar with Java and JavaScript.

------
nerdbaggy
Would love to see an actual demo link in the GitHub. Although there is a lot
lot of stuff so I may have missed it

~~~
victor9000
Hera ya go, requires Expo on Android:

[https://expo.io/@rgommezz/react-native-scroll-bottom-
sheet-e...](https://expo.io/@rgommezz/react-native-scroll-bottom-sheet-
example)

~~~
nabn
that's not fast

~~~
victor9000
Then don't use it?

The amount of useless negativity in this thread is really amazing. The repo
has ~650 stars right now, so clearly developers are finding this work to be
useful. Yet look at all the mindless poo slinging going on in this
"community".

------
jiofih
Why would you put a list or carousel inside a bottom sheet? Please don’t.

~~~
polynomial
Why not? Don't have a lot of experience with React Native, so it's not
immediately obvious why that is a bad thing.

~~~
jiofih
Not specific to RN, just terrible UI. Bottom sheets are for contextual info,
action sheets, not loads of content.

~~~
nicoburns
Do you use iOS? On Android I agree, but iOS seems to have adopted bottom
sheets as a way to make up for it's lack of a back button, which means that
you have to reach all the way to the top of the screen to dismiss a
traditional modal, and it works pretty well.

~~~
jiofih
Just look at the example videos they have in the repo. You won’t find any of
that in iOS apps.

------
mihaela
Let's just learn one language and do everything with it, NOT.

------
robertoandred
Can you scroll down to close or do you have to drag the handle itself?

~~~
rgommezz
Absolutely! You can scroll down to close it as well

------
LeoNatan25
Come September, when new iPhone comes with 90 or 120hz display comes out, web
devs will be back to square one with these nonsense “60fps animations”
“challenges”, which are the simplest thing to do in native development.

------
matchbok
Is RN still used widely? Most people/companies I know have ditched it. It's
never a time saver and usually just a pain once you wanna do something
complicated.

~~~
ericwood
It seems to be more and more a niche tool. I don't think there's really
anything better for situations where you have a small startup that needs an
app, has JS experience, but can't justify a full-time mobile dev for each
platform. This is the situation I'm in now, at least, and despite a few warts
I couldn't imagine anything better for getting some fairly high quality apps
out the door.

~~~
la_fayette
Why don't you use ionic or a pwa? It is known that RN has an extreme impact on
battery consumption, the web browser is much more efficient in terms of energy
use...

~~~
ericwood
Not familiar with Ionic, honestly, and React Native has been around a few
years and supported all the use-cases we'd want, and I've been doing React for
a number of years, so a familiar environment was a huge win.

Energy consumption is definitely a concern, but our app isn't exactly
something people are going to be on all the time...it's more of a "check it a
few times a day and move on" sort of deal. It's a fairly complex app with
quite a few screens and with daily usage I haven't noticed any hit on battery
life.

A PWA could be a good fit, and while I think there's many cases where it makes
a lot of sense, there's a handful of native features we wanted to utilize
(most importantly, push notifications!) that aren't possible yet in the PWA
world.

There's always tradeoffs with any of these abstractions and React Native fit
the bill with what we were comfortable trading off. I'd love to see the whole
thing get the full native experience on iOS and Android once we're profitable
and can hire full-time devs on those projects, but we're not there yet and so
far the decision to go with RN has paid huge dividends in terms of shipping
this. You'd be hard-pressed to tell it wasn't a native app, seriously!

~~~
la_fayette
Great explanation, thank you!

------
CleanCoder
Finally, we can do tabs in tabs!

------
sandGorgon
This is super brilliant. Have you tested this with the new Hermes engine on
both iOS and Android?

~~~
rgommezz
I haven't. Although I reckon there shouldn't be much difference performance
wise, since all the heavy lifting is done on the native thread. Maybe it could
potentially improve the mounting time, which is the only code JS has to run
during the lifecycle of the component.

