[Rohansi]

That's basically what React Native does/did and it's generally good but turns into a nightmare when you need to synchronize interactions between the two threads. 16ms is a long time - if your UI manipulations eat up most of that time then there's something wrong. Entire video games can run basically on one thread within that time and they do way more.

[vbezhenar]

16ms is a long time by C standards.

16ms is not a long time, when interpreted languages like Lua are used.

16ms is not a long time, when GC can suddenly kick in and stop the thread for unspecified amount of time.

16ms is not a long time, when JIT can suddenly kick in and stop the thread for unspecified amount of time.

GC and JIT are good techniques for server-style throughput workloads, when infrequent delays are not noticeable. For GUI, infrequent delays lead to skipped frames and stuttering.

I don't think that it's reasonable to ask the world to develop GUI apps in C or Rust. Probably Swift is a good middle point between usability and predictable performance. But most GUI projects use slow languages and/or languages with GC.

[Rohansi]

I disagree. Yes, it's less time vs. C but still a long time.

There are plenty of games built with Lua that run very well such as Balatro and Don't Starve. And games are far more sensitive to hitches than GUI projects because they are constantly animating. Your users will not only easily see lag - it can ruin the game for them.

If a basic GUI is performing poorly then the blame almost certainly lies on whoever developed it. Don't blame the language or runtime.