Hacker News new | past | comments | ask | show | jobs | submit login

It means that the transitions between RN and Native for most cases are visually indistinguishable to the end user. Of course there are potential differences "under the hood" simply b/c the animations are implemented differently.

It's possible that the OPs ran into certain issues with specific cases or weren't able to figure out a workaround even though solutions exist, but the result of their comments unintentionally create FUD.

I'll give an example. One of the most popular libraries for messenger apps to use in RN is GiftedMessenger, but it's actually doing the keyboard wrong, so people may get the misconception that ReactNative doesn't support smooth keyboard animations, which is not true. There are a lot of examples like this, not meaning to pick on anything specific.

I will say that the library ecosystem around RN doesn't feel mature yet, kind of like Node.js in the early days, but React-Native itself is not the issue.




If you require more CPU cycles to do it, then it's not indistinguishable, even if it actually winds up being visually indistinguishable.

It drains more battery, it leaves less CPU for other operations, etc.


Indistinguishable as far as the user is concerned. I'm guessing most users won't ascribe any battery or CPU degradation to a new app, unless they spend half their day on it.


I have very high doubts that they are "visually indistinguishable". Did you time animations exactly? Did you give the animations the same easing function exactly? Also, what happens when iOS 10 comes, and tweaks these values?

No, the user always feels. Even the grandmas and grandpas, that are far away from technology as possible, feel it in the back of their mind. They know something is "off".

Also, adding "artificial delays" to wait for animation end is a sign of a terrible terrible animation system.


> I have very high doubts that they are "visually indistinguishable"

It's hard to describe without showing you in person and asking you to tell me which app is a RN app vs native, but it's actually the case... There's pretty granular control over the easing functions and the default ones do match the iOS curves.

I was a designer before being an engineer, and I was immersed in Obj-C for 4 years before trying React Native. On the well-implemented React Native apps, it really truly is indistinguishable.


Perhaps the difference here is between a RN app written by someone with only a web/js background and a RN app written by someone who has a deeper understanding of the system beneath RN's abstraction layer?


That's not what I meant. It's got the right easing curves out of the box for most transitions. Sorry for the confusion. But there are definitely some things that take a little more digging around as the documentation doesn't exactly offer "best practice" recommendations in all cases.

It does help to read obj-c code in the RN repo to see what's possible and how things work so you use the right javascript parameters, but you don't normally have to do additional obj-c coding most of the time.


Yea, I'm offering a bit of a different point than you.

You're saying that that it is easy to use RN to build an app that is indistinguishable from an app written in obj-c

I'm offering the possibility that your 4 years of obj-c experience trained you to make intuitive judgements about how things should be done and that this intuition is mostly correct. Also that a person without that experience wouldn't make those same judgements and might default to doing things in a lower-fidelity way.

This suggestion is offered without experience using either react native, obj-c, or swift. So coming from ignorance, I might be entirely wrong.


>No, the user always feels. Even the grandmas and grandpas, that are far away from technology as possible, feel it in the back of their mind. They know something is "off".

If it's below a certain ms (milliseconds) threshold the user does not "feel". There's nothing more or less to it besides simple physiology.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: