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

111–120 of 135 posts

Re: Developing Our First iOS App with React Native

#111

Post by lispm »

EvanPlaice wrote: post #81
tomjen3 wrote: post #68

Earlier quoted context omitted.

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

> Lisp macros are essentially higher order function definitions.

Definitely not. Lisp already has higher order functions. Macros are something entirely different.

> They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).

Of course not. Decorators and closures are in no way related to Lisp macros.

There is enough literature about Lisp macros... For example a certain Paul Graham wrote a book explaining them in detail:

http://www.paulgraham.com/onlisp.html

Re: Developing Our First iOS App with React Native

#112

Post by alexashka »

EvanPlaice wrote: post #110
alexashka wrote: post #90

Earlier quoted context omitted.

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…

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

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

Re: Developing Our First iOS App with React Native

#113

Post by EvanPlaice »

officialchicken wrote: post #88
EvanPlaice wrote: post #79

Earlier quoted context omitted.

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

Can't forget the declarative regular and context-free languages.

XLST and other template syntaxes are another interesting case. They look mysteriously like a declarative context-free language but have imperative characteristics of a turing complete syntax.

JVM may not be able to be combined with compiled languages but there are a number of languages that, at a bytecode level are compatible with Java. For example IronPython, Rhino, etc. The same can be said for the .NET environment and languages like VB.NET, managed C++, C#, F#, etc.

Don't even get me started on languages that can output output Javascript. Last I heard, there's over 100 of them now and the list keeps growing.

I'm not sure about GLSL/HLSL because I haven't used them but they sound like they're declarative DSLs (Domain Specific Languages).

Maybe it's about time somebody created an update to the Chomsky hierarchy. Instead of the traditional subset-superset classifications, some other system is used to compose the characteristics of languages.

In the bigger picture of things, it's all very incestuous. Like every language is trying to be like every other language. The winners of the pack are those that everything else compiles/transpiles down to.

Re: Developing Our First iOS App with React Native

#114

Post by [deleted] »

seivan wrote: post #96
mostafaberg wrote: post #32

Earlier quoted context omitted.

It's a great piece of tech, I'm not saying anything against that, I'm saying that it shouldn't be used as a replacement for native programming because you don't want to learn a new language. react will come with huge limitations and deps that you don't want to even think about, it's never easy as "code once, deploy everywhere", this is usually a bad decision any company makes, engineering wise.. same reason as adobe…

React is native . It's a JS interpreter on a separate queue rendering native UILabels and UIViews. I'd say the concept is far more superior to UIKit which disgusts me, and I've worked with for almost seven years now. I honestly think React is the future, but for now we can try to stick with MVVM and RxSwift ;-). I think you're fundamentally not understanding how React (not just React-native) works.

[deleted]

Re: Developing Our First iOS App with React Native

#115

Post by iLoch »

dj_doh wrote: post #104

The biggest barrier to high fidelity ECMAScript apps on native platform is simple economics. Apple is guaranteed a $99 bounty when you push something on the appstore. Making Safari or WebView compatible with their native APIs and performance is a risk for AppStore. Having built 3 non-trivial iOS apps using phonegap and JavaScript. I have come to the conclusion that I'm never going to build native apps using web stack…

You also appear to not know how it works. React Native doesn't use a web view at all. It uses JavaScriptCore to process UI updates to native views.

Re: Developing Our First iOS App with React Native

#116

Post by pka »

trollied wrote: post #46
Apocryphon wrote: post #12

Earlier quoted context omitted.

Isn't the advancement of computer science towards further abstraction?

No. You still need to teach the fundamentals or you'll run out of people to do everything low level. It's no longer a science when it's wishy washy high level

Pointer arithmetic is really not that hard. It's not something worthy to be proud of.

Re: Developing Our First iOS App with React Native

#117

Post by alien3d »

sjclemmy wrote: post #34

I'm writing mobile apps using angular / Cordova and ionic. When they are running on a device I can't tell the difference between a native app and a JS Cordova one. I think JS is the future of mobile apps.

There is a big different. File size especially.Limitation payPal API and the most buggy me was XCODE upon compiling to apple apps.

Re: Developing Our First iOS App with React Native

#118

Post by satya164 »

alexashka wrote: post #112
EvanPlaice wrote: post #110

Earlier quoted context omitted.

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

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

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

Re: Developing Our First iOS App with React Native

#119

Post by coldtea »

jaegerpicker wrote: post #86
coldtea wrote: post #54

Earlier quoted context omitted.

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

I'd say the majority of developers write enterprise code, whether web or not.

Re: Developing Our First iOS App with React Native

#120

Post by alexashka »

satya164 wrote: post #118
alexashka wrote: post #112

Earlier quoted context omitted.

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

> 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 and insurmountable stumbling block.

Post reply on HN