Hacker News Reader

Comment by leosantos | Hacker News Reader

On a more technical note - I'm exploring React Native (having significant experience shipping native iOS Apps) and while on the face of it React Native looks amazing, as I go deeper into building something production quality, I've hit roadblocks with doing simple (natively) things like scrolling a scroll view to focus on a text field that's partially visible and changing the offsets of a scroll view to prevent the keyboard from masking the focused text field in a way that doesn't appear glitchy.

Did you encounter any such problems?

View on HN

What are you hoping to get out of using react native?

This write once, use everywhere is such a strange desire.

If you're a serious company, develop on iOS/Android first, then hire a dev or two to make an exact copy for the remaining platform. It's really not that hard.

The hard part is doing something the first time and iterating. Copying is not rocket science - look at the Russian facebook clone - it's actually better because of copyright laws, you can do more on their version.

There are two fundamental issues with the mobile first approach.

Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication.

The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time.

Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences?

Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale.

The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.

I understand the theoretical upsides to one platform/language to rule them all, absolutely.

I am saying that trying to re-write the layout engine, data layer and all the rest to make it work the same on both platforms is not only a massive undertaking - it is ignoring the reason the platforms diverge to begin with.

iOS has features Android doesn't and vice versa. Something that works on both platforms is always going to be a second-class citizen - it's the lowest common denominator.

I don't want the lowest common denominator because it's 'easier for developers'. I want the best stuff.

The theoretical technical debt due to writing on different platforms is why we have software architects and senior developers.

Really, I've been part of a dev shop that does ios/android - the biggest hurdle is people problems, not code. People who don't know what a good app is or have any taste so they say first show me, then I will start asking for changes at random while insisting on a tight deadline.

As for web/ios/android/desktop - this is a rare bird, if you need to support that many platforms, you can afford an architect and some smart people.

The application layer is decoupled from the rendering layer specifically for reuse across multiple platforms. That means the data layer that handles data fetching and change propagation works everywhere.

The view rendering layer is the part that is specific to each platform and the React community provides web components that work natively on each platform making the development process between mobile/web more consistent. Mobile provides an escape hatch to write platform specific code in the native language.

"As for web/ios/android/desktop - this is a rare bird"

Targeting all, will remain very unlikely. Targeting more than one is pretty common. React and Angular2 are pushing hard to enter the mobile development ecosystem. Microsoft has been pushing for Typescript usage on the desktop and just picked up Xamarin so we'll likely see desktop or web or mobile hybrid applications at some point in the future.

If the barrier-of-entry to support another platform is low enough, it'll make sense to do so. In the current ecosystem, supporting even 2 platforms is a massive undertaking.

I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.

I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.

For starters - using Javascript when you could be using Swift/Objective-C is laughable. That's a non-starter. Then, there is no real data layer at all! You have to interface with Objective-C!

So what is the point of using this at all? To have shared view layer logic? Facepalms

> I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.

Facebook is using RN in production. So I doubt it.

> Then, there is no real data layer at all! You have to interface with Objective-C!

I don't get what you mean. You don't have to interface with any native code if you don't have a very specific need to use a platform specific feature which is not available in RN.

> I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.

If you spent just 5 minutes, it clearly means that you don't have enough experience with React Native, and I don't think you should give opinion on anything without at least being familiar with it. I've been working with React Native for months, and yeah, there are technical hurdles. But I'd say the same for Android, or web (I don't have any experience with iOS dev).

There are parts of React Native that suck. But there parts which are amazing. Amazing enough that I'll choose React Native over Java/Obj-C any day. The development speed with React Native is much faster than native Android dev. The DX is getting better day by day.

I get to share code isn't the primary reason why I love React Native, but it's an important thing for companies which want to support multiple platforms.

I'd say let's focus on fixing the parts that suck in React Native, rather than discarding a new tech without even trying it.

Ok hold on, you've been working with it for months? To what end?

Please tell me you're not using a library that's at 0.20 for production.

So you're using ReactNative for pet projects right?

As soon as you get to writing a real app that's beyond a to-do list, you'll be in a world of pain. Just start with having no support for a sqlite/database or an orm layer on top of it, only a key-value store as your first massive and insurmountable stumbling block.

> Please tell me you're not using a library that's at 0.20 for production.

I'm using it in production. And so is Facebook.

No, it's not a pet project, and much more than a TODO list app.

I've implemented one solution to this in FB's Groups App. Try that experience out and let me know what you think. Also, Nick Lockwood should comment here.

Is the solution something you can share on a general level? Would love to see how you approached it.

It's not incredibly advanced: It mostly just consists of measuring where exactly the current text box is in the scroll view, how high the text box is, and then having the scroll view scroll to that location, followed by fading in a docked text input right on top of the underlying one. It's pretty slick, but I'd encourage the community to recreate it in a reusable component and open source it.

We should hopefully be able to open source a cleaned up version of the solution that Jordan alluded to, but we have a long list of components we'd like to work on, and only a finite in-house development resource.

I think it's important to understand that React Native is not an attempt to replicate the entire iOS native framework - it's a set of UI components that aim to provide a better developer experience for the common app development challenges we face at FB, combined with a framework for building new components.

When we encounter an uncommon challenge (i.e. something that we haven't already had to solve and build a reusable JS component for), we simply drop down to the layer underneath and create a new native component.

That's why I struggle to understand the argument that "React Native doesn't do this one thing I need, so I can't use it" - we put a lot of thought into the plugin architecture of RN, and making native plugins is trivial for anyone familiar with iOS or Android development.

If there is something you already know how to do natively, you can leverage that knowledge to build an RN plugin and then get the best of both worlds. If you don't already know how to do it natively, there's a good chance that someone else already made a plugin that will do what you want.

Reply on news.ycombinator.com