Riffing of the predictability of an adjustable distance, a similar option might be something like a marker/inverse colour applied to a line immediately before the scroll. The marker would help orientation after the scroll and disappear after some time. You could also scan the text of course but a marker would be much faster.
Holdonasec - I can list roughly (looking through my bookmarks and counting) - about 20sh different forum type sites with discussion (reddit, anand, verge, slashdot, ars, strachery, etc...) - None of them I like as much as HN. Why would trying to find a site that is better (given the OP didn't like HN) make me sound like a Bot?
And if the answer was, "Well, there is nothing better than HN" - kind of makes me wonder what his original point actually was.
I've seen a few comments along the lines of wishing that the author had included examples of solutions. I wrote a very similar post recently that details both the issues with the animations, very similar to this article, as well as how I improved them.
Appreciate heads-up! I just checked Chrome on my Android device and it's all working fine for me. I don't know if I set the page up weirdly but I have to refresh the page sometimes for the videos to show up.
Thanks for highlighting the "one element cross fades into a totally different one" example. That particular type of animation really makes an app feel ungrounded and unreliable to me, it gives a sense that the UI elements aren't really tied closely to the data and are just barely existing. And somehow I see it all the time across tons of apps.
The improved versions where the elements actually transform into each other, sharing the same visual real estate, is so much better.
Ty for the kind words! I completely agree with you too. Compose added a Crossfade modifier that makes it super easy to apply the animation to a content switch but it's often applied in the lazy way you mentioned.
Artists benefit hugely from the extra horsepower. My brother works in the animation industry and uses an ipad as his primary work device when travelling.
You realize of course that you are also on HN and thus this apparent dichotomous behaviour applies to you as well? I imagine you have some reason for why it doesn't and I think you'll find that it can just as easily apply to everyone else.
From what I've seen,the refractions happen in predictable contexts so I suspect that they'll be able to create shaders, etc that will limit the performance hit
I was glad to see the discussion as well but it feels like the downsides were also very understated. Working on an RN app as a native dev requires a lot of cross-domain knowledge that isn't typical for a native dev.
Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".
For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)
Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.
On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
Pixel 9 Pro, or virtually all android phones apart from the recent snapdragon Elite and coming ARM Cortex X5 all have much slower single threaded performance comparing to iPhone.
The Google Tensor G4 in single thread and integer only is roughly in between iPhone 11 and iPhone 12. That is the performance between 2019 and 2020 on iPhone.
And Tensor G4 is already on the high end Android Phones. You can quickly see how all previous and lower end android phone are much slower.
Developing for Apple can be a PITA with their strict background processing rules, apps just terminate/stop working unless they fall under a special case. I get it but yeah.
edit: by terminate I don't mean crash, it just stops code execution an example is an active socket connection getting disconnected unless it's doing something like streaming audio
But as a user I appreciate the strictness much more. I don't have to worry about closing background apps or having a bunch of crap running when I'm not actively using it. The OS (mostly) handles that for me, as it should.
Absolutely. I’d rather have backgrounded apps unexpectedly closed from time to time than to find a big chunk of battery gone at a bad time because some app I don’t even care about has decided it needs to keep running and eating resources for some reason.
