Hacker News Reader

Comment by oakesm9 | Hacker News Reader

I've worked as a "real" native Android and iOS developer for a fair few years and just started working on a project which is built using React Native (Android and iOS).

You're right that the development experience is nothing like "real" native. It's using lots of web tech so it's never going to feel like Java or Swift, however, that comes with its own advantages such as code reuse and libraries.

I'm actually really impressed with the quality of the apps you can create with it. They feel native and feel really smooth, but you need to be aware of the limitations. The major one is that the apps are essentially single threaded so you need to be aware what work you're doing to avoid UI stutters. That does make it less suited for very data heavy apps, but you can work around it if needed.

Overall, as a "real" native developer I'm pleasantly surprised.

View on HN

Your app doesn't need to be single threaded. To begin with, the JS that you write is running on a different thread to the app's UI thread, but if you also have blocking work that you want to offload to another thread, that is possible by writing a native module [1, 2]. The story isn't perfect, there are probably some things that you want to be dealt with asynchronously, but could be written in JavaScript, but on this front React Native isn't any less limiting than native.

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

[2] https://facebook.github.io/react-native/docs/native-modules-...

To the extent I have used RN, I find the good parts to be: - Fast & iterative development

- If you are web developer, easy to switch to this (duh!)

- The "React" philosophy of "diffing" and pushing changes and having a virtual DOM

- Javascript - less boiler plate and easier to write (YMMV)

But, with RN you hit the limits in some spots:

- Handling navigation. The available navigator components are difficult to work with. The idioms are little sticky. I know they've started working on a new one

- With Android SDK, you have the full set of components available and hence more choices - components, Material themes etc.,

- Because of the above point, you are always ahead, unless you have bandwidth to write wrappers for new components/ changes

- Slightly noticeable lesser frame rates compared to native. I don;t think this is a deal-breaker though.

Overall, the RN team is doing a great job by bringing the well tested RN concept to the mobile world and making "reusable code" worth an attempt. The choice depends on one's requirements and technology choices available in the project etc.,

Can you use React Native for the UI thread and talk to another thread to get data or perform long running calculations?

Yes, I do this in my app. It's well-supported by the platform and quite easy -- there are built-in primitives to call a native function from javascript that returns a promise, which can then be fulfilled/returned asynchronously on the native side once your long-running calculation or transfer is finished.

My main concern is about the performance and overhead that whole node ecosystem brings.

Despite that, it's nice to read a positive feedback :)

Other then using the same package manager there is very little overlap between the node ecosystem and react's, so I'm not sure what you are referring to

Maybe I missed something.. where are all js files going to be rendered on?

javascript engine provided by the OS, in iOS it's JavascriptCore, in UWP it's the chakra engine. Not sure what it is in Ubuntu, probably v8 packaged with the executable.

In either case, it's not using node or v8/chromium .

Sorry about my uneducation but if v8 is running standalone isn't this similar to having node running on the OS?

v8 is just a javascript engine, node.js is a platform built on v8.

Node.js adds various standard native modules - mostly various IO (file, tcp etc...), a way to load other modules, access to the underlying OS (environment variables etc...).

running v8 alone is akin to running the browser without html or the dom api, you basically can compile and run javascript functions, but can't do much with it.

Isn't javascript really really really fast?

The Julia websites has a benchmark for various languages performing some tasks. Javascript seemed pretty comparable to Java.

Every language has it's pros and cons in terms of performance and benchmarks are notoriously inadequate to compare but my general probing of people in the industry result in the following regarding language speed:

1. c/c++ is the fastest.

2. modern java is either the same as c/c++ or about 2x slower

3. modern javascript (i.e. v8) is about 4x slower then java.

4. python/ruby and most other dynamic languages are about 10x slower then java.

Never seen C# really compared with others because it's rarely ran on the same systems.

Go, Rust and all the new shiny languages are still far away from when we can infer about their performance, but they are probably somewhere around the Java level.

Source? According to this Rust is faster than Java http://benchmarksgame.alioth.debian.org/u32/performance.php?... Here you can see that it wins in almost every benchmark compared to Java http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

>> is faster than Java

You seem to have cherry-picked that single-core-x86 n-body measurement just because the quad-core-x64 n-body program measurements are slower than the Java program measurements.

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Like I said, benchmarks are a terrible way to gauge performance, most of my rankings come from people's experience in various situations, Rust is too young for people to have any experience with it.

Also, the Python JIT compiler PyPy in many cases matches or exceeds V8.

I wouldn't lump all of the "new shiny languages" together; they all have their own performance profiles.

Sorry, I meant all the new shiny languages are too young to make good estimation about and from those Go and Rust appear to be somewhere in the Java level.

Didn't mean to imply that other shiny languages are in the Java level, just bad grammar on my part I suppose.

Why do you think Rust is at the Java level for example?

It's a low level language without a GC and compiles to LLVM, it should in theory rival C/C++ in performance, but it's still young and only recently begun making headways for performance.

So just a hunch, also some barely usable benchmarks that appeared on HW a few months back.

> only recently begun making headways for performance

What gave you this impression? MIR landing?

I'm not saying it is a wrong impression, but it doesn't match mine. My impression is that Rust is routinely very fast, often rivals C, and most of the recent headways were surrounding the performance of the compiler, not the resulting programs.

Worth noting that Dalvik/ART has very different performance characteristics than a desktop or server JVM (many of the optimizations that proguard does matter a ton on Android where they wouldn't matter very much at all with the jvm).

Javascript has been optimized to hell but I'm not sure I would call it really really fast. Its still going to be much slower than Lua (a language that its easier to make go fast) and a good Javascript JIT interpreter uses lots of memory and needs some warmup time.

I'm not familiar with React Native but can't you use Web Workers to get multi threading, and get around the UI stutters?

Isn't react native using one thread for uiand another for running js?

Can you use service workers with react native?

>it's never going to feel like Java or Swift

.. or Lua, or Bash, or Qt, or Love, or Unity, or Tcl/Tk, or C/C++, or .. anything else that this is now sitting alongside, 'in the stack of usable components'.

Its good for web developers. But in the 'native application' realm, there are .. frankly .. a lot of better ways to do user interfaces than the franken-nightmare that supports the gloss...

> It's using lots of web tech so it's never going to feel like Java or Swift

I'd consider Swift to be native, but Java generally not. You can compile Java to machine code, but typically people run bytecode on a VM.

I think by Java he's talking about Android.

I think we need to find better terminology, then. The same thing happened for 'realtime'. It used to imply hard deadlines in performing actions (like applying brakes in a car). Now there are realtime web apps that certainly don't have those sorts of requirements.

My understanding of real time is that it can be broken into hard real time and soft real time. Hard real time systems (such as car brakes) require a guaranteed response time. Soft real time systems (games are the canonical example) have similar time constraints, however the penalty for not hitting them isn't considered an absolute failure (not hitting 16ms/frame every now and again isn't the end of the world). I'm not aware of any other definitions of real time systems?

Reply on news.ycombinator.com