5 ms·

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

by ex3ndr 6y ago

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.

sandGorgon 6y ago
What about MotionLayout ?
- ex3ndr 6y ago
  All Android API executes animations on main thread except for vector animations, but in reality you need transitions to be fast.
hadrien01 6y ago
> 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 6y ago
  I have an idea about an article unfortunately I can’t write in polite way about this issue, will try again soon.
dep_b 6y ago
We thought maintaining two platforms was too much, so we got React Native. Now we have three to maintain.
- ex3ndr 6y ago
  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 6y ago
    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 6y ago
      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).
kall 6y ago
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 6y ago
  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.

by ex3ndr 6y ago

sandGorgon 6y ago

What about MotionLayout ?

ex3ndr 6y ago
All Android API executes animations on main thread except for vector animations, but in reality you need transitions to be fast.

hadrien01 6y ago

> 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 6y ago
I have an idea about an article unfortunately I can’t write in polite way about this issue, will try again soon.

dep_b 6y ago

We thought maintaining two platforms was too much, so we got React Native. Now we have three to maintain.

ex3ndr 6y ago
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 6y ago
  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 6y ago
    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).

kall 6y ago

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 6y ago
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.