Comment by Cthulhu_
4 hours ago
This is the part I don't really understand - was the development experience and iteration speed really that much faster moving away from low level languages / APIs? It's in the critical path, it should be stupid fast.
I have some hope that thanks to hardware shortages and AI helping people write software they will rewrite some things back to faster languages. But this is all gut feeling, gut feeling that a lot of modern-day developers are afraid of optimized code.
(I fully acknowledge the hypocrisy, given my bread and butter is JS/TS front-end and I don't like C. But in my defense, there's no market demand for native developers either, barely any Go even, even though a few years ago it looked like a lot of Java backends were getting rewritten)
Yes, it was really that much better. Win32 was an atrocious API even by the standards of the time, and nobody uses it anymore for good reasons. You can't get the kind of UX modern users expect with plain Win32 - even implementing dark mode is a pain in the rear.
But! Something hardly anyone realizes is that you can get native old-school performance with modern frameworks if you do things right. The best example of this I've seen is what happens if you AOT compile JavaFX apps with GraalVM. They start instantly, every bit as fast as a classic Windows 95 era app running on a modern Win11 machine would.
JavaFX is the replacement for Swing in Java world. As GUI frameworks go I actually really like the API - it's not a ReactJS based paradigm that never really gelled for me, the closest JS equivalent might be something like Vue where reactivity is done at the property level instead of via vdom diffing. It is vaguely HTML inspired, so there's an XML based way to define UIs and you can style them with a dialect of CSS, but the whole thing is designed for GUIs from the ground up. Rendering uses the 3D pipeline on each OS (Direct3D, Metal, Vulkan or OpenGL), it's multi-threaded, there are sophisticated widgets for things like rich text editing and table views, properly parallel composited animation APIs etc. When it first came out it was quite futuristic, nowadays I'd say it's just standard.
Anyway, you can make apps with it that feel completely modern to end users, and yet, they start fast and use relatively little memory when AOT compiled. The JVM startup time disappears entirely.
Part of why it's fast is that GraalVM lets you initialize parts of the app statically at build time, so data structures like GUI widgets derived from XML or CSS can be frozen into a heap snapshot and just mmapped in. No startup time computation needed.
So it's possible and we don't have to go back to using legacy APIs to get this kind of performance. A sufficiently smart compiler can work wonders.
> even implementing dark mode is a pain in the rear
You don't need to implement dark mode when all the controls already follow the users system color scheme. Dark mode is a signficiant regression compared to user-adjustable color schemes and another example of designers wanting to enforce their vision over the desires of the user.
Using a library that wraps the native system is also good - eg. wxWidgets. I find it very nice to work with compared to attempting to learn any of the myriad UI attempts Microsoft introduced later.