Live data from Hacker News

React Native for Android

code.facebook.com

211–220 of 248 posts

Re: React Native for Android

#211
post #193

Earlier quoted context omitted.

Of course. For example, suppose that there is a button in your UI that changes color whenever you click on it. Changing the color of that button in response to a click can be done in a simple Javascript function that takes O(1) time. However, doing it the React way, all buttons on the screen have to be traversed, O(N), and diff/patched into a new DOM, which is heuristically O(1). However O(N+1) = O(N), so React takes…

It's because anyone who has done any complex web app development knows that you don't have one button changing color. You have 100+ UI components whose state may depend on one another, and as the DOM nodes composing those UI elements get state attached to them, it's EXTREMELY easy for them to both (1) get out of sync, and (2) thrash and re-render entire trees of the DOM unnecessarily. This is a real thing that happen…

Yes, I understand all of this. It can work for small websites. However, the technique cannot uphold for larger systems. For example, consider writing a word-processor using this style of programming. If the user is writing a 10-chapter book, and every character entered by the user requires a visit of all characters in the book, that is not very usable. So even from a practical viewpoint (not just theoretical) it is not workable.

Also, consider adding items in a streaming fashion (one-by-one). If there are N items to be added, then the amount of items visited by this scheme is 1+2+3+...+N, which amounts to O(N^2). This is quite ridiculous.

Also don't forget about power consumption, which is of course very important for mobile applications.

Finally, The solution is not satisfactory from an intellectual viewpoint. Instead of trying to be smart, we are lazy, and abuse abstractions to make our lives easier, and at the same time our software behave slower (especially now that progress in speedwise performance in hardware seems to have stopped).

Re: React Native for Android

#212

Earlier quoted context omitted.

Of course. For example, suppose that there is a button in your UI that changes color whenever you click on it. Changing the color of that button in response to a click can be done in a simple Javascript function that takes O(1) time. However, doing it the React way, all buttons on the screen have to be traversed, O(N), and diff/patched into a new DOM, which is heuristically O(1). However O(N+1) = O(N), so React takes…

I think its because there are tradeoffs for managing the complexity yourself. Using this same argument most abstractions which have performance overhead should be unacceptable. There are tradeoffs everywhere and I guess this is one that a lot of people have accepted.

See https://news.ycombinator.com/item?id=10219678

Re: React Native for Android

#213
post #34

Earlier quoted context omitted.

Sure, but that works in reverse. People could easily port their code TO iOS.

Unfortunately everyone writes iOS first nowadays because rich people overwhelmingly own iOS devices.

You could probably replace "rich" by "people willing to pay money for apps". Although even on iOS this is less and less true.

Re: React Native for Android

#214
I'm sorry for the stupid question, but I'm in a hurry: I don't really want to write the whole app logic in JavaScript. Is it possible in an easy way to have a React Native UI on top of a common C/C++ code base? I don't know React yet, but it gets very interesting now and I'd like to give it a try. Maybe it could completely replace Qt for me.

Re: React Native for Android

#216

Earlier quoted context omitted.

I've done similar with inotify (dnotify before that) and Python now for over a decade, and it is an interface than can automate anything. I use it with doc generators also. I believe I used something similar called fam in the 90's but that may have only been on SGI.

Filesystem watching is only part of the equation though. Live reload has been available for the web and various other platforms for a long time, but the traditional approach to live reloading does not preserve application state. These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been…

That's why Common Lisp / CLOS has functionality like

  * CHANGE-CLASS (change the class of an object to a different class),
  * update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed),
  * update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),
  * LOAD (load source or machine code),
  * EVAL (eval expressions)
  * COMPILE (compile code in memory to memory), ...
One then always develops with a live application. Classes and objects can be updated in-place...

Re: React Native for Android

#217
post #121

Google has been working with the alternative already: https://flutter.github.io/ . Probably usable in some months.

One advantage of React Native is that facebook uses it and hence they will keep developing it. Unless Google apps start using Flutter, it may not gain traction/resources.

Except if they find out that it doesn't scale and abandon it. They have engineering resources to rewrite their app from the ground-up in whatever new technology they want.

Do you?

Not trying to discourage the use of it - just that "Facebook uses it in production" isn't really a big sell for me.

Re: React Native for Android

#218

I'm sorry for the stupid question, but I'm in a hurry: I don't really want to write the whole app logic in JavaScript. Is it possible in an easy way to have a React Native UI on top of a common C/C++ code base? I don't know React yet, but it gets very interesting now and I'd like to give it a try. Maybe it could completely replace Qt for me.

I'm not exactly sure of your circumstances, but this sounds doable.

The public React Native API allows you to expose arbitrary pre-existing Views and expose new native functionality in modules accessible from JS. These can be written in java (or in C/C++ and exposed via JNI -- and if you structure your code properly you can also share that native module with an iOS RN app if you'd like).

We also support having just part of the app, e.g. some of the screens, written with React Native. This is what we do with the Groups app.

The main thing to be aware of is that splitting app logic and data management between JS and native will mean that you need to be careful with cache consistency between the two.

Re: React Native for Android

#219
post #206

"OS X - Only OS X is currently supported" Why is this becoming popular ?

There's unfortunately a lot of non-overlapping work so we decided to release what we have finished incrementally. Most of the team uses OS X for development so it was a natural first choice. We're planning on adding the missing Windows and Linux support soon!

Re: React Native for Android

#220

Question for everybody doing some sort of cross platform mobile dev. How common is it to have NO experience with a platform's native libraries? In other words you didn't go from ObjC or Java to React Native/Cordova/Xamarin to try and re-use code but because you know JS or C# and weren't concerned about learning the native platform. For any that started out with no native platform knowledge did you start to dip into i…

If you stick with the tools which actually don't abstract the native platforms (e.g. RoboVM and Xamarin), I think you will learn native development quite easily. I've taken this approach, and I've had no trouble using documentation/StackOverflow to write equivalent code in Java/C#. Since pretty much all the APIs in these tools are 1-1 with the native APIs, I've also had no trouble going in the reverse direction and w…

I started serious app dev with Xamarin before I ever touched ObjC. After having implemented a ton of apps I am able to move between Xamarin/RoboVM/ObjC/Swift/Java quite easily. I dabbled with Cordova and Titanium before that a bit but that was not a good experience for me.
Post reply on HN