How Discord achieves native iOS performance with React Native
blog.discordapp.com
How Discord achieves native iOS performance with React Native
1–10 of 115 posts
Re: How Discord achieves native iOS performance with React Native
#2I’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 spinning animation in the background chewing away at CPU — death by the smallest cut!”
I spent an entire day doing the same! I had a spinner running in the background that ate 30% of my battery! I felt so stupid back then. :)
Thanks Discord for sharing this, the community really appreciates it!
Re: How Discord achieves native iOS performance with React Native
#3Re: How Discord achieves native iOS performance with React Native
#4I 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.
Re: How Discord achieves native iOS performance with React Native
#5I 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…
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 animation to that frame.
Re: How Discord achieves native iOS performance with React Native
#6Re: How Discord achieves native iOS performance with React Native
#7Re: How Discord achieves native iOS performance with React Native
#8Sounds 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
Re: How Discord achieves native iOS performance with React Native
#9I 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.
So apparently the experience never gets really good as opposed to native iOS development where once you get to a certain level you don't spend that much time chasing weird build errors.
Re: How Discord achieves native iOS performance with React Native
#10I 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…