Live data from Hacker News

How Discord achieves native iOS performance with React Native

blog.discordapp.com

41–50 of 115 posts

Re: How Discord achieves native iOS performance with React Native

#42

Earlier quoted context omitted.

I understand they are using the Dart langugage? Was it hard to master?

Super easy if you know JS/TS and turns out that I actually quite like it.

What's missing? TS has quite a few interesting language features that I assume Dart is missing (seems Dart has the reputation of being a Java-like language, with all the boilerplate that that entails).

Re: How Discord achieves native iOS performance with React Native

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

Ionic is quite decent, though can become sluggish once your app grows in complexity (even with lazy loading) if you're not careful.

Flutter looks interesting, going to check it out.

In the end one wants a true "write once, run everywhere" framework, not write the business logic and then write the UI 3+ times for each target platform. Ionic delivers on this front, but am curious to see if Flutter takes it to another level (blazing fast dev/reload cycles and native performance in production sound quite appealing).

Re: How Discord achieves native iOS performance with React Native

#46
post #11
post #6

Sounds like React Native causes more work then necessary. Business logic can be easily shared between different platforms, Android, macOS, Windows and iOS. Always the most time is spend to make the app behave right for each platform, so that’s only bit which differs. I am happily writing apps in Swift for Android and iOS

Watching some videos illustrating writing iOS React Native apps using Clojurescript, with REPL changes updating app display in real time (well, "live") is what makes me interested in RN. Were it not for that, I don't see why Swift is such a bad thing. I know that maintaining two separate code bases for iOS and Android is theoretically bad, but I imagine if the apps are architected well it shouldn't be such an issue.

I'm using Clojurescript with react native via re-natal and it's a decent experience because of Clojurescript. If Clojurescript was not an option I'd probably just use flutter instead.

Re: How Discord achieves native iOS performance with React Native

#47
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…

I’ve seen this happen especially with Lottie. And what basically happens here is the actual drawing isn’t actually handled by react-native since the library is itself a native view to either platform. Therefore, react-native has no idea it’s wasting any resources because it’s not technically “in charge” of what exactly the native view itself is doing. It certain scenarios where it might be “covered up”, such as all JavaScript based views (which are essentially just UIViews in iOS) then iOS itself also doesn’t know to stop this animation either (view compositing is quite popular).

However, if using something like native navigation, where view controllers and their life cycle get handled by iOS then it will correctly end an animation.

I have no idea if this is true for Android. But I have witnessed it on iOS and fixed this issue in react-native apps on quite a few occasions.

The ultimate downside to frameworks like this is they imo, don’t know enough about the content they’re showing to make great choices for users. But at the same time, it’s not fully desirable to attempt to assume. That’s the platforms job. And that’s an obvious catch-22. How should you know this if you aren’t a native app builder?

Re: How Discord achieves native iOS performance with React Native

#48
It's good to see that they care a lot about TTI and put work into optimisation, but the desktop app needs the same love. My Windows PC boots to the desktop in less time than it takes for Discord to then start up. I'm unclear what it's doing - checking for updates?

This is about my only gripe with Discord though, it's a great service.

Re: How Discord achieves native iOS performance with React Native

#49

Earlier quoted context omitted.

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.

Seriously, take a stab at building an app in Flutter.

Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.

Re: How Discord achieves native iOS performance with React Native

#50
post #24
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…

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms): - It forces you to think about your business logic vs. UI structure. - It forces you to make your core logic library easily testable. - Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much…

how did the java interop work for you ? I used to work in a company that used that approach with gomobile (golang) , and frankly the dark magic required to have a decent java API to the shared library made me want to not touch that with a ten foot pole.

I believe it was due to JNI but my memories may be wrong.

Post reply on HN