Live data from Hacker News

How Discord achieves native iOS performance with React Native

blog.discordapp.com

31–40 of 115 posts

Re: How Discord achieves native iOS performance with React Native

#31
post #26
post #18

Earlier quoted context omitted.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. Bu…

I did not have a great experience with that approach. The now (in)famous DropBox article describes why way better than I ever could: https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cos... My biggest pain points were tooling. For all of Xcode’s faults, C++ and Objective-C debugging and intermingling wasn’t one of them. Android, though, was another story.

The big thing the Dropbox article does not mention is the fact that they never really ported the Dropbox core functionality to C++ so they never reaped the benefits of sharing code in their most complex and most business logic heavy part of codebase.

We actually used their own Djinni library on one of the projects and it worked well - but even at that time the Dropbox team wasn't maintaining it at all since they never used this approach beyond the short-lived Carousel app.

Re: How Discord achieves native iOS performance with React Native

#32
post #23
post #16

The iOS app of Discord is crappy compared to the Android app. I mean, it's not bad bad, but it's not good, or at least not as good. I wonder why they decided to go this route instead of hiring iOS developers? I could understand if they used the same app for both platforms (like they do with their Electron app, which is also not as good as Ripcord), but since they have a native app for Android...

As far as I know, they use react for both. Where did you hear that they had a native android app?

From their open job positions - it looks like the Android app is indeed native (mostly Kotlin + heavy use of RxJava).

And only iOS + web (+ desktop?) are mentioned in the post.

I'd imagine the reason they didn't use RN on Android is because historically it's always had much worse performance on that platform. iOS RN performance is usually acceptable, but Android has always been a bit of a 2nd-class citizen.

Re: How Discord achieves native iOS performance with React Native

#33
post #2

I almost got an tear in my eye reading this, being heavily invested in React-Native and the worries I’ve felt since Airbnb abandoned the ship. I’ve always loved the framework and the beauty of being able to write native , cross-platform applications as a web developer. And what they are doing right now, trying to get rid of the js-thread bottleneck in 2020 excites me a lot! > “While it was closed it always had a spin…

A spinner running in the background consuming CPU is two bugs... The non-obvious one is why is the framework consuming any CPU time at all on something not visible? When an element tries to animate, and the whole element is covered/offscreen, the framework should simply pause the animation. When the element becomes visible again, it's simple to calculate how long the element has been invisible, and fast-forward the a…

Maybe you created your own spinner, swapping between 100 cute pngs...?

Re: How Discord achieves native iOS performance with React Native

#34
post #3

I recently tried to start a react native / typescript project, but the ecosystem confused me a lot. The various different tool recommended to create a project, some project templates not even compiling, the tons of different utilities required to process source files.. All that and not a single reliable source of documentation, made me feel it would be a real nightmare to maintain on the long run.

Is that really true? ‘react-native init AppName’ and your ready to go?

What is wrong with react natives official documentation? I think what many mess up(me included) is to look at the wrong version of the documentation. I guess that could be a little bit more obvious.

edir: oh, typescript! Yeah, that is a little bit more troublesome; https://facebook.github.io/react-native/blog/2018/05/07/usin...

Re: How Discord achieves native iOS performance with React Native

#36
Once i have a dream about RN application for iOS/Android without Xcode and AndroidStudio.

Started with Expo, great tool if you don't have native modules. But i have, very complex search library in Rust. After few attempts the code was converted to asmjs (RN doesn't support wasm). So i have JS-only codebase that works on Expo. Livecoding (a bit slow beause of large js codebase) and easy deploymnet on all platforms.

After release users starts complain about performance. RN fetch API doesn't support binaries, everything passed back and forth as base64. Some low-mid tier phones got stuck for few minutes. Also RN fetch doesn't support progress and a lot of other thing.

Decision was to start using native libraries. Ehh, goodby sweety Expo...

The lesson was learned, if you have complex application don't expect too much without heavy investment. JS is ugly and unpredictable as usualy. Overall experience is ok/mehh, but not great.

For the next project i give Qt5 a chance.

Re: How Discord achieves native iOS performance with React Native

#37
post #3

I recently tried to start a react native / typescript project, but the ecosystem confused me a lot. The various different tool recommended to create a project, some project templates not even compiling, the tons of different utilities required to process source files.. All that and not a single reliable source of documentation, made me feel it would be a real nightmare to maintain on the long run.

You are not wrong. It is a nightmare to maintain, and if you already took the leap you best keep that project updated as soon as possible or you will be fucked beyond repair. There has to be a better way to write mobile applications. Is that Ionic? I don't know.

If you’re going to remain within Apple platforms, try SwiftUi:

https://developer.apple.com/tutorials/swiftui/

There may be a chance of it being adapted for other platforms in the future.

Re: How Discord achieves native iOS performance with React Native

#38
Amazing job by the discord team having the patience with the available tools to analyze these problems and the stamina to dig deeper and deeper. Well done!

It is quite interesting to see that the re-frame and fulcro authors were on the right track adding their own 'componentNeedsUpdate' layer which is very fast and will minimize the repainting React has to do. (Mostly thanks to immutability)

Re: How Discord achieves native iOS performance with React Native

#39
React Native is excellent for web teams that are creating a new mobile app. If your team has more experience with React than native iOS/Android, then it's a no-brainer.

However, in my experience you get diminishing returns once your app has passed v1 and your customers expect more after the new-ness wears off. You find yourself spending more and more engineering effort to make your RN app to feel as good as existing mature native-first apps, which is especially frustrating as you are solving problems that native-first app developers never had to solve in the first place. They got the solutions for free with the native sdks.

This plateau of developer effectiveness is hard to get away from as your app becomes so coupled to RN and your team invests so much into RN tooling and skills that it feels like a sunk cost.

I do not envy the Discord apps team.

Re: How Discord achieves native iOS performance with React Native

#40
post #2

I almost got an tear in my eye reading this, being heavily invested in React-Native and the worries I’ve felt since Airbnb abandoned the ship. I’ve always loved the framework and the beauty of being able to write native , cross-platform applications as a web developer. And what they are doing right now, trying to get rid of the js-thread bottleneck in 2020 excites me a lot! > “While it was closed it always had a spin…

Don't thank people actively working on proprietary software bent on hindering people's rights to privacy and freedom.
Post reply on HN