undefined | Better HN

0 pointsfreehunter6y ago0 comments

You're right, I didn't use the correct terminology and I appreciate the correction.

On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front.

Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite.

[1] https://facebook.github.io/react-native/showcase

0 comments

3 comments · 1 top-level

K0SM0S6y ago· 2 in thread

I think you'd indeed have to look at more demanding applications, more "bleeding edge" stuff computationally: 3D gaming is probably as good a candidate as ever, maybe some in-app AI workflows, idk. Truth is, I know how to bring a desktop/server to its knees because there are valid use-cases for that, but on mobile I struggle to find many examples indeed. I guess any heavy data crunching app might fit the bill, but when don't you run that remotely? On-premises offline pro apps maybe, like tools for e.g. plumbers and electricians? All of that stuff is in embedded afaik. Dedicated devices, rugged cases, it's a whole other market/target.

So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.

vlozko6y ago

The issues you tend to run into with mobile is that you have to either create so many shim layers to use native app features or resort to 3rd party solutions. And there are loads of examples (speaking for iOS here):

1. JSON parsing

2. Network calls

3. Background downloading

4. Notifications

5. Camera access

6. Password/contact/code auto fill

7. VoiceOver

8. Web Views

9. JavaScript bridging

10. Encryption

11. And many more

Almost every app needs some combination of those and in some of these cases you’re forced to use a native solution. What ends up happening is that a significant amount of developer resources gets wasted bridging many of these things with massive bug logs to go with them. It’s why at this point I refuse to do anything but native in my career.

K0SM0S6y ago

> “It’s why at this point I refuse to do anything but native in my career.”

Point well taken! If I may ask, would you say that

1. it's a problem inherent to developing on mobile (whatever the underlying reasons, hardware iterations, idk), and that OS APIs are indeed trying to solve as best they can (it's just a hard problem),

or rather

2. that it's a problem somehow created by OS vendors of their own volition? (a.k.a "evil microsoft walled garden", cue "Apple's take on that" and Google's similar moves for Android and we think Fuschia) In essence a business-driven reality.

I actually don't care about "evil" (hence the wording, it's funny) when it's just business strategy; my deeper question is really about the problem space.

Like, is this forever (native versus cross on a fast-iterating platform), is this industrial politics or technical limitations, could some other platform do it "better" (thinking of SailfishOS, or the Linux phones like the Pine project etc.)

j / k navigate · click thread line to collapse