Live data from Hacker News

Developing Our First iOS App with React Native

code.hireart.com

131–135 of 135 posts

Re: Developing Our First iOS App with React Native

#131
post #29

Truthfully, the language barriers are nothing next to the API barriers dealing with your platform of choice. I am probably giving away my age here, but there's very little that's new under the sun after you've tussled with... say one each of the big three language families. These being: Nasty old C (not going anywhere, ever. Deal with it.), modern scripting languages (Ruby, Python, et al) and the real deal functional…

i agree with you, although i think you are forgetting to add (and maybe it is implied here and i missed it) that learning mobile development requires you to not only learn new language APIs in objC/swift, but you also have to learn some new design patterns (delegation, etc.) and most importantly the SDKs (CocoaTouch) if you can use react native and avoid learning a lot of this it is a big win - I havnt used it yet, a…

So here's the real bear of it, and the crux of my argument.

The delegate thing is an iOS thing. Android uses a totally different pattern. I mean, there are delegates, to be sure, but android loves their anonymous inner classes in many of those cases. (Which is closer to idiomatic js IMHO.)

So on a language level sure, easy peasy, you could delegate in javascript all day long (and you do). But on a platform level, nuh-uh. One is going left and the other is going right. How do you meet in the middle? What fine line gets scrubbed in between?

Re: Developing Our First iOS App with React Native

#132
post #60
post #29

Truthfully, the language barriers are nothing next to the API barriers dealing with your platform of choice. I am probably giving away my age here, but there's very little that's new under the sun after you've tussled with... say one each of the big three language families. These being: Nasty old C (not going anywhere, ever. Deal with it.), modern scripting languages (Ruby, Python, et al) and the real deal functional…

While I agree with you, I also think that it's easier to overcome one of those hurdles first, rather than to overcome both at once.

I guess I see it as a form of technical debt-- you move faster, but past a certain level of performance it's all gotta go native. There are a lot of places it would be a decisive win. There are a lot of mobile websites that are great. But there's a ceiling, and once you hit it, all that javascript is gonna get rewritten.

Re: Developing Our First iOS App with React Native

#133
post #68
post #29

Truthfully, the language barriers are nothing next to the API barriers dealing with your platform of choice. I am probably giving away my age here, but there's very little that's new under the sun after you've tussled with... say one each of the big three language families. These being: Nasty old C (not going anywhere, ever. Deal with it.), modern scripting languages (Ruby, Python, et al) and the real deal functional…

That is one way to write the code, but if you do it that way you will never get the benefits of each language. Haskell and Lisp are both functional, but they way they are intended to be used are very different (example: if you don't use macros with lisp you are probably missing something. If you don't take advantage of lazy evaluation in Haskell you are also missing something).

Uhhh, I never suggested writing lisp in a C style, or ruby in a functional style (well, more so than it encourages at least). That would be crazy. My point is that there aren't that many ideas under the sun. Lazy evaluation, super. Monads, ok. Real-deal, no playing memory allocation and management? Where's that union stashing variables again? Are you sure? Uhhh, fine I guess. (Although I'd rather take the monads.)

Re: Developing Our First iOS App with React Native

#134
post #129
post #128

Earlier quoted context omitted.

Correct, it's not a trivial app by a long shot. Also, a validation for React Native.

> They are using Reactive Native for a lame duck Groups and some ad manager app. "Some ad manager app" which happens to be the ad manager for one of the largest advertising platforms on the planet right now. It's also composed of non-trivial UI, you should try it before blindly bashing it. I've used both Cordova, and Titanium, too, by the way - Cordova was relatively painless but lacked the native feel. Titanium sort…

Okay how about one very, very simple question - Can I replace my all of my Swift and iOS+tvOS+watchOS APIs with React Native? To make it easy for you. Can I do that within next 1 year? What will happen when Apple will introduce a slew of new APIs will be introduced in Sept?

Let's say I don't have any real world examples. I'm not seeing any engineering marvel in React Showcase. https://facebook.github.io/react-native/showcase.html pales in comparison to http://phonegap.com/app/

Re: Developing Our First iOS App with React Native

#135

Earlier quoted context omitted.

> 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 f…

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…

> 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.

Post reply on HN