Look at the progress of Flash/AIR AS3 as an embedded runtime prior to its annihilation. By 2010 or so, it had the capability to leverage the GPU on pretty much any device, directly uploading bitmaps and shaders. It had garbage collection as good as or better than any existing [modern] JS engine, had strong types and compile time errors. It was better and cleaner than the modern fractured Typescript-and-canvas web app gaming paradigm in every respect, except for one: It was closed source.
I'm not a fan of AS3's demise, nor of the current state of affairs. We are stuck a decade ago because of it.
But I can also imagine a world where Adobe has a stranglehold in 2026 on most cross-platform game development, and where little arose to compete with it outside their ecosystem. And they've become such a hideous company blinded to their users, even without the advantage they used to have of dominating browser plugins, that I can see now maybe it was for the best that they're not the guardians of the way we do things anymore.
The anarchic process of creating standards is messy, and it results in a huge amount of wasted effort by developers. And it's often a lot less fun.
On the other hand, the job is to make shit using whatever is available.
Instead, I've had people from Microsoft itself recommending me to "just write it in HTML, there's no standard" and "accessibility sucks with native".
When you have the market leader telling you to write HTML for their OS, it's a carte blanche to do it everywhere.
At this point, I think HTML+JS is able to be a better choice than SwiftUI for most things: Yes, some stuff will still need to go to a native layer, but that's true for HTML as well. ;P
Is it a better interface and developer experience? For sure. Is it gonna replace the previous API? Doubtful.
I have to admit I'm still ignoring it though.
It's not just that I think, using their native components also ensures accessibility and consistent UX throughout different apps, which is a huge benefit to e.g. screen reader users. Everyone else - especially web interface builders, especially if they eschew just using native elements - reinvents the wheel and considers accessibility as an afterthought.
At least we have laws now that mandate accessible websites for corporates, in addition to government sites.
And it was a security nightmare...
That's when I learned about the halting problem.
As a user, comparitive "performance" is about the code people actually write, and even more on the code that I'm most likely to interact with. I don't actually care whether or not the code could be faster if it was written better, because it always could, and it never is. When people say "Electron is slow and bloated" they don't mean that exhaustively written Electron apps could never" be performant, they mean that apps that use Electron tend to be slow and bloated. The way to change that reputation is not to argue that Electron could* be fast if people held it right, but to make it easier and more natural for Electron apps to be faster than they currently are.
So I do understand why it got that reputation. But I'm using Javascript's raw performance in 2012 as an objective point of comparison. Consider a browser game. Given well-written JS coded with a competent understanding of the engine architecture versus well-written Flash, rendering the exact same animations, effects and interactions, you would find that the framerate in Flash could stay 25-30 fps on an iPhone 5, and be < 10 fps in Javascript. And that was with an alpha version of the Flash plugin. Similarly for JS bundled in Electron versus AS3 in the AIR engine as a "native" app. I know, because I wrote one of the first game engines for Javascript that attempted to do a subset of what could be done in Flash at the time.
What did make the dev process in Flash truly accessible was that it allowed the artists' pipeline to work in the same environment as the coders'. That did sometimes give rise to poorly written apps, but the fact is that the same thing in JS would have been even slower and more battery-draining, in an apples-to-apples comparison.
There are fewer browsers than native GUI environments but we still couldn’t make that work…
Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
If your device was running Windows sure. On Linux, Flash absolutely sucked with 100% CPU usage to render the most basic still image and on Android it was kind of similar.
Two, it was not responsive. It was written for fixed sizes with keyboards and mice. Not portrait displays with touch screens, nor AR/VR displays with pointers/hands, and for resolutions of the day, not reflowing / resizing to fit the user's device
Something like procreate would be horrible with mouse/keyboard. UX is not merely a function of size.
For whatever reason, developers and some users expect an app to look the same across all platforms, while also looking distinct from other apps—otherwise, the app looks indistinguishable from a low effort one. This involves creating a design system and departing from each operating system's native widgets.
Knowing when to apply novelty and when to apply the familiar is the game.
Ultimately the browser was recognized as its own platform and had to support all the customizations and accessibility concerns. User stylesheets are a thing, but few used that for much more than hiding annoying elements, and today the most likely user customizable thing is being able to switch between light and dark modes.
https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...
Even Hollywood movies show better UIs than modern crap.
The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.