Hacker News new | ask | show | jobs
by EvanPlaice 3772 days ago
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.

1 comments

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.