Get the top HN stories in your inbox every day.
0xDEEPFAC
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.
0xDEEPFAC
Its the abstraction on abstraction culture which seems to be the norm these days, because, hey "ECMA script is portable and accessible"! So lets "browserify" all the things...
Just wait until your BBQ has its own browser - oh shit wait
h-cobordism
> hey "ECMA script is portable and accessible"! So lets "browserify" all the things
It's not because JavaScript is portable or accessible (it's definitely not portable, and if you wanted accessibility you could do much better), it's simply because it's the most popular language.
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.
LeoNatan25
The overhead is much, much lower in native development. Having a JS bloatware adds a lot of slowdown, as does the additional nonsense layers of React Native itself. As you can see, RN developers are still boasting “60fps animations” in 2020.
Pulcinella
Also I believe the traditional drawing algorithm (e.g. the painters algorithm) is not well suited for parallelization and how gpus do work. So the gpu is “fast” at slapping a circle texture on a couple of triangles, but rendering a circle from vector data not so much.
I think Apple has said that Core Animation (and maybe Core Graphics) now use Metal where possible, but vector to bitmap rendering is still done on the cpu.
https://raphlinus.github.io/rust/graphics/gpu/2019/05/08/mod...
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.
tomaskafka
But apparently only in the bottom sheet. Scientist estimate, though, that humanity might be able to achieve 60fps scrolling in other app areas as soon as 2035, on a schedule right after cold fusion!
dean177
Try being less dismissive, you might be happier and make others happier while you are at it
Guaranteed good performance (the bit you picked up on) for a feature people want in an easy to use package sounds great. Well done the author and thanks for sharing your work.
jfkebwjsbx
Yeah, is a bit shocking this being news in 2020...
zemnmez
people will really write a bunch of opengl graphics demos and think that's all there is to ui
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.
ericwood
It's around 8 emojis per row; FlatList can do multiple columns out of the box, but in order to allow scrolling through all categories I was forced to use SectionList to get the headings. Chunking the larger data array into groups of 8 and rendering them as single columns worked well enough, but the perf was abysmal, and it wasn't immediately clear why. I've found all of the VirtualizedList components are an absolute nightmare to perf tune, so I replaced the SectionList with a ScrollView and instead force users to tap on categories to switch.
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) 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.
hadrien01
> 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.
I'm interested to read more about that, do you have an article or something?
ex3ndr
I have an idea about an article unfortunately I can’t write in polite way about this issue, will try again soon.
kall
have you actually looked at reanimated, which this uses, to see if that has the issue you describe? It sure doesn‘t block the JS thread, and I‘m pretty sure it doesn‘t block the "native" layout thread either? I‘m not 100% on that but I haven‘t seen it stutter, even on a bad android phone.
ex3ndr
I am saying about blocking native main thread not js one for sure. 90% of the time people saying it is not shutter are 1) use very simple ui that does nothing or 2) it shutter they just have low bar for Android in general.
sandGorgon
What about MotionLayout ?
ex3ndr
All Android API executes animations on main thread except for vector animations, but in reality you need transitions to be fast.
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.
madeofpalk
There's a difference between a dark pattern and a bad pattern. I don't think this is either, but it of itself is certainly not a dark pattern, one that's intentionally used to mislead.
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.
HeinZawHtet
"Expo compatible: no need to eject to enjoy this component!"
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
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
I guess you probably have better insight than the devs of two of the most popular native apps, though. Cheers!
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.
merrvk
Sorry but what has this got to do with this package?
undefined
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...
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".
Get the top HN stories in your inbox every day.
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?