[tomduncalf]

In my experience, this is completely wrong.

We recently shipped a music making app which uses React Native for the UI, which is visually fairly rich and non-standard, including real-time rendering of shaders at 60fps responding to user input using gl-react-native and regl, and overall have been very pleased with the speed at which React Native allows you to iterate and the polish/smoothness of the resulting app; not to mention the fact that it allows us to easily make use of web developers’ existing CSS skills (as compared to writing a native app).

The fairly straightforward bridging between React Native and native code has allowed us to have an audio engine running in C++ and to communicate with it in both directions in real-time without significant overhead.

That’s not to say it’s been 100% straightforward, there were definitely a few rough patches along the way, but overall I would definitely use it again. I can easily believe that e.g. 18 months ago it may have been a much rougher experience which may explain your thoughts though!

[ptx]

> communicate with it in both directions in real-time without significant overhead

Doesn't all the communication have to be done by passing JSON-encoded messages between threads? So compared to calling a function on the same thread, there is very significant overhead, especially if you want to pass large data structures (which would have to be serialized) or if the calling thread needs to block waiting for the answer.

But as long as you stick to send small and asynchronous messages, it doesn't have a significant impact on the user experience, I suppose.

Or did they do something to improve this lately?

[zebraflask]

An audio engine in C++?

[tomduncalf]

Yep - C++ is generally used for audio programming because you can write code that is real time safe for use on the audio thread (low latencies mean you might have 5ms to fill a buffer with fairly intense calculations required for a modern synth, so any waiting for locks, memory allocation, GC pauses etc. can be disastrous and lead to audible glitches). On top of that there’s a huge amount of code and libraries for audio stuff written in C++ - we used JUCE which provides a lot of helpful abstractions and cross platform compatibility.

[zebraflask]

Is there? What would that huge amount of code meant to you?

[tomduncalf]

It means you can build on top of other people’s proven abstractions rather than writing your own buggy ones ;)