6 ms·

I'm sorry but this seems overstated. There is already two highly competitive navigation libraries: https://github.com/wix/react-native-navigation https://githu

I'm sorry but this seems overstated. There is already two highly competitive navigation libraries: https://github.com/wix/react-native-navigation https://github.com/wix/react-native-navigation https://reactnavigation.org https://reactnavigation.org Edit: Replaced the word FUD with overstated, to not seem like I'm attacking the author personally.

rimliu 8y ago
I had some discussion with the Wix engineer. Let's just say, they still feel the pain of going RN route. There are reasons why this may still be beneficial to them, but it is still painful.
ballenf 8y ago
Agree with you, but think it's somewhat unfair to call the parent comment "FUD", given the specific examples cited. To me, FUDdy comments are more vague and less dis-provable. More like "but you never know whether Facebook is going to deprecate React tomorrow". Just a nitpick because I think "FUD" borders on ad hominem in the way it's sometimes used. Again, as a React dev, I haven't encountered the cited issues and they seem a little dated, but I wouldn't call them FUD.
- RubenSandwich 8y ago
  Fair enough, I'll replace the word FUD with 'overstated' I do not mean to attack the author.
saagarjha 8y ago
I looked at the GIF that the first one had on their GitHub page and it doesn't do iOS navigation right at all. I'm not impressed.
- Klonoar 8y ago
  You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. It's iOS-style navigation and transitions through and through.
  - saagarjha 8y ago
    > You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work. > The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. > It's iOS-style navigation and transitions through and through. UINavigationController is a complex beast that is often difficult to work with even in native code, because it tries to do a lot of things for you that are difficult or outright impossible to replicate if you try yourself (which isn't necessarily a good thing, but that's what we have so that's what we need to work with). Plus, a lot of this behavior "comes for free", but the downside to this is is you customize certain things you give up a lot of this behavior. So UINavigationController is not just showing a title and a back button in a box: it does things like managing transitions, animating the title when pushing onto the navigation stack, handling popping gestures, handling content insets and vibrancy, and providing certain niceties such as "tap the top of the screen to scroll up". It's a lot of things to keep track of, even for native developers, so while I'm not saying that this can't be done in JavaScript often a lot of this just ends up being reimplemented in scratch and you end up missing things. For example, the provided link, from a cursory glance that navigation controller completely butchered title handling and animations. If you want to take look at how these should work, take a look at Settings or Mail and see how the behavior differs.
    - Klonoar 8y ago
      ...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS. All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. There are a lot of reasons to prefer the Apple dev ecosystem on a native level, but this is a moot point at the end of the day. Finally, look... I was your age once, and believe me, I too thought I was an expert when I was in high school. Age and time are gonna show you otherwise sooner or later. Blind allegiance to a particular tech stack isn't healthy for your career, and throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. This is almost willful ignorance on the level of Twitter's Cocoa community.
Etheryte 8y ago
As I stated above, it's my personal opinion on the matter. I've used both of those libraries in a medium-sized project and they don't work well. Simply linking to libraries and saying they exist is hardly making a point.
- RubenSandwich 8y ago
  I have used both of those navigation libraries in medium sized projects as well. This is the section that struck me as overstated: "The last time I checked there was still no reasonable, scalable way to do complex navigation on the platform. Most third-party components are unusable six months in due to API changes." The links are counterpoints to the complex navigation issue. Showing that libraries exist and can handle complex navigation. If you want to argue that they are going over rapid change, which is true, then that is another thing. But I'm gonna disagree with the blanket statement of "there was still no reasonable, scalable way to do complex navigation on the platform" as overstated. As for the second point. I assume what you mean by 'third-party components', is actually third-party native modules. In which I agree the API for them doesn't seem to have stabilized yet so there is a lot of churn in native modules. But a lot of third-party components I have seen continue to work in newer versions of React Native.

rimliu 8y ago

I had some discussion with the Wix engineer. Let's just say, they still feel the pain of going RN route. There are reasons why this may still be beneficial to them, but it is still painful.

ballenf 8y ago

Agree with you, but think it's somewhat unfair to call the parent comment "FUD", given the specific examples cited. To me, FUDdy comments are more vague and less dis-provable. More like "but you never know whether Facebook is going to deprecate React tomorrow". Just a nitpick because I think "FUD" borders on ad hominem in the way it's sometimes used. Again, as a React dev, I haven't encountered the cited issues and they seem a little dated, but I wouldn't call them FUD.

RubenSandwich 8y ago
Fair enough, I'll replace the word FUD with 'overstated' I do not mean to attack the author.

saagarjha 8y ago

I looked at the GIF that the first one had on their GitHub page and it doesn't do iOS navigation right at all. I'm not impressed.

Klonoar 8y ago
You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. It's iOS-style navigation and transitions through and through.
- saagarjha 8y ago
  > You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work. > The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. > It's iOS-style navigation and transitions through and through. UINavigationController is a complex beast that is often difficult to work with even in native code, because it tries to do a lot of things for you that are difficult or outright impossible to replicate if you try yourself (which isn't necessarily a good thing, but that's what we have so that's what we need to work with). Plus, a lot of this behavior "comes for free", but the downside to this is is you customize certain things you give up a lot of this behavior. So UINavigationController is not just showing a title and a back button in a box: it does things like managing transitions, animating the title when pushing onto the navigation stack, handling popping gestures, handling content insets and vibrancy, and providing certain niceties such as "tap the top of the screen to scroll up". It's a lot of things to keep track of, even for native developers, so while I'm not saying that this can't be done in JavaScript often a lot of this just ends up being reimplemented in scratch and you end up missing things. For example, the provided link, from a cursory glance that navigation controller completely butchered title handling and animations. If you want to take look at how these should work, take a look at Settings or Mail and see how the behavior differs.
  - Klonoar 8y ago
    ...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS. All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. There are a lot of reasons to prefer the Apple dev ecosystem on a native level, but this is a moot point at the end of the day. Finally, look... I was your age once, and believe me, I too thought I was an expert when I was in high school. Age and time are gonna show you otherwise sooner or later. Blind allegiance to a particular tech stack isn't healthy for your career, and throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. This is almost willful ignorance on the level of Twitter's Cocoa community.

Etheryte 8y ago

As I stated above, it's my personal opinion on the matter. I've used both of those libraries in a medium-sized project and they don't work well. Simply linking to libraries and saying they exist is hardly making a point.

RubenSandwich 8y ago
I have used both of those navigation libraries in medium sized projects as well. This is the section that struck me as overstated: "The last time I checked there was still no reasonable, scalable way to do complex navigation on the platform. Most third-party components are unusable six months in due to API changes." The links are counterpoints to the complex navigation issue. Showing that libraries exist and can handle complex navigation. If you want to argue that they are going over rapid change, which is true, then that is another thing. But I'm gonna disagree with the blanket statement of "there was still no reasonable, scalable way to do complex navigation on the platform" as overstated. As for the second point. I assume what you mean by 'third-party components', is actually third-party native modules. In which I agree the API for them doesn't seem to have stabilized yet so there is a lot of churn in native modules. But a lot of third-party components I have seen continue to work in newer versions of React Native.