Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing Our First iOS App with React Native

code.hireart.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: Developing Our First iOS App with React Native

#81

Post by EvanPlaice »

tomjen3 wrote: post #68
warcher wrote: 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).

Lazy evaluation is no longer exclusive to Haskell and other functional languages.

C# has had Linq for lazy evaluation of data collections for many years.

Javascript supports observables now and ot's only a matter of time before they're included in the official spec.

Reactive Extensions has been extended to many different languages now.

Lisp macros are essentially higher order function definitions. They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).

Re: Developing Our First iOS App with React Native

#82

Post by EvanPlaice »

alexashka wrote: post #57
leosantos wrote: post #28

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

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

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.

Re: Developing Our First iOS App with React Native

#83

Post by jbeja »

ghrifter wrote: post #33
warcher wrote: 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…

Yep this is what I'm realizing after a few years of programming. I can pick up a language easily, however learning it's APIs is almost as hard as learning the syntax for the language itself. Like how do I open a file? Ok cool. How do I close it? Do I need to explicitly close it? Ok. Also, learning APIs for other peoples codebases/software is task of learning that isn't trivial too

This is why language oriented programming is a better alternative to everything else.

Re: Developing Our First iOS App with React Native

#84

Post by EvanPlaice »

marknutter wrote: post #38

What I'm curious to know is, outside of the arguments about React being the superior pattern for developing UI's, how is this fundamentally better than or different from other hybrid libraries like Appcellerator Titanium or Xamarin? In my experience they all fall short when you try to get the last 20% of your app written. Because you're not writing in the native language, directly accessing native API's, you're alway…

React Native doesn't use embedded webviews and provides an escape hatch to write native code when Reactive Native's capabilities fall short.

Re: Developing Our First iOS App with React Native

#86

Post by jaegerpicker »

coldtea wrote: post #54
misiti3780 wrote: post #37

Earlier quoted context omitted.

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…

> 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.) Delegation has been a standard feature of desktop APIs for decades. Not just on things like Smalltalk and ObjC -- it has been the standard .NET model for UI events since C# 1.0.

sure but the majority of developers writing code write webapps. Some there are some desktop apps out there but not a lot.

Re: Developing Our First iOS App with React Native

#87

Post by jaegerpicker »

EvanPlaice wrote: post #79
minionslave wrote: post #51

Earlier quoted context omitted.

Where does C# fall among these 3 families?

The C category. A 4th category is probably needed for statically compiled, garbage collected, OOP languages. The reality is, most/all of the most popular languages blur the lines. Javascript is getting official support for OOP as well as better support for functional programming. C# has good support for dynamic typing as well as many functional characteristics. High performance Python has always had the ability to de…

I've been out of the ecosystem for a while but isn't it closer to type inference than dynamic typing?

Re: Developing Our First iOS App with React Native

#88

Post by officialchicken »

EvanPlaice wrote: post #79
minionslave wrote: post #51

Earlier quoted context omitted.

Where does C# fall among these 3 families?

The C category. A 4th category is probably needed for statically compiled, garbage collected, OOP languages. The reality is, most/all of the most popular languages blur the lines. Javascript is getting official support for OOP as well as better support for functional programming. C# has good support for dynamic typing as well as many functional characteristics. High performance Python has always had the ability to de…

Agree 110% on the blurring, and maybe a 5th category too - 4GL, for SQL and its ilk.

Obj-C, Obj-C++, C++, and C can all co-exist in the same codebase and be complied into 1 output (if you are insane enough to try), similar to CUDA or Fortran with C/C++. That's not really possible with JVM or CLR languages, but not impossible either. Which makes them more like 3GL/OOP while sharing more similarities with smalltalk than 2GL/C.

Py, Lua, GLSL/HLSL, and many others can "mix" or be called by C/C++ similar to CUDA, and Lua is definitely in the interpreted "script stuff" bucket, not statically compiled like Java, C#.

The shader languages like GLSL/HLSL are really confusing to categorize, especially when used with C#, because they can exhibit characteristics of 1GL thru 4GL.

Re: Developing Our First iOS App with React Native

#89

Post by marknutter »

EvanPlaice wrote: post #84
marknutter wrote: post #38

What I'm curious to know is, outside of the arguments about React being the superior pattern for developing UI's, how is this fundamentally better than or different from other hybrid libraries like Appcellerator Titanium or Xamarin? In my experience they all fall short when you try to get the last 20% of your app written. Because you're not writing in the native language, directly accessing native API's, you're alway…

React Native doesn't use embedded webviews and provides an escape hatch to write native code when Reactive Native's capabilities fall short.

That's no different than appcellerator or xamarin though. And in the case where you are just using embedded webviews you can easily write native code alongside them. Cordova is written in objective-c and is easy to understand.

Re: Developing Our First iOS App with React Native

#90

Post by alexashka »

EvanPlaice wrote: post #82
alexashka wrote: post #57

Earlier quoted context omitted.

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

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…

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.

Post reply on HN