News for hackers. Stuff that matters.
Re:Gio UI – Cross-Platform GUI for Go by ricardobeat on Saturday May 18, 2024 @06:55AM (#40397924)
My team achieved better than native performance using RN when rewriting a very large iOS app. And that was in 2018, before Hermes and a lot of other optimizations.

It takes some careful usage of requestIdleCallback and avoiding doing work in the UI thread but it is not rocket science. You do have to avoid a lot of the going advice and bloated libraries / frameworks though.

Re:Gio UI – Cross-Platform GUI for Go by mradonic on Saturday May 18, 2024 @07:13AM (#40398014)
| better than native performance

Maybe better than the native you had before the rewrite lol

Re:Gio UI – Cross-Platform GUI for Go by ricardobeat on Saturday May 18, 2024 @07:02PM (#40402794)
“The app we had before” had 50M+ users, developed by a large iOS team, including a lot of experienced developers working on performance, and generating billions. I think it was a valid baseline.
Re:Gio UI – Cross-Platform GUI for Go by robterrell on Saturday May 18, 2024 @11:59AM (#40400027)
> better than native performance using RN

You had an app written natively in Objective-C or Swift, switched to single-threaded javascript React Native, and then your app ran faster?

Re:Gio UI – Cross-Platform GUI for Go by wiseowise on Saturday May 18, 2024 @02:23PM (#40400925)
Unoptimized native application, probably written in a yolo let’s ship it faster way, is slower than rewrite that learned from mistakes of previous application. What makes you surprised?
Re:Gio UI – Cross-Platform GUI for Go by ricardobeat on Saturday May 18, 2024 @07:22PM (#40402906)
Though JS is single-threaded, it only builds the render tree and is more than fast enough if you’re careful. RN has a separate UI thread for actual rendering, I/O is offloaded and extensions can use extra threads.

The largest bottleneck historically was the bridge between obj-c and js (now superseded by JSI), and not the speed of the engine itself.