Comment by noduerme
5 days ago
This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like. But Apple (or Xerox) invented the UI paradigms we're still living with.
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.
IMO a bigger nail in the coffin of native interfaces was Microsoft writing a new widget library that was supposed to be better than the previous over and over again, but to this day never quite making any of them official.
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.
A nail, from what I hear about that side of things, but on the Apple side I could substitute the dual replacement of UIKit and AppKit with SwiftUI that somehow still isn't good, plus separate pressure coming from all the cross-platform options between iOS and Android.
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
Yeah, I agree. SwiftUI looks exactly the same mistake Microsoft made with MFC/WTL/VB6/WebForms/WPF/Silverlight/WinRT/UWP/WinUI/MAUI.
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.
Better garbage collection than current runtimes? Now this is surely rose tinted glasses, probably based on nostalgia. It had horrific performance all around. Even the now obsolete Opera browser Kestrel runtime had better JS performance, and it is obsolete because Chrome crushed it in benchmarks consistently for several years. No, there's no way Flash had the performance characteristics you mention, even less in a critical component like the garbage collector.
People have this odd view that Flash had horrific performance, largely because their encounters with it as users were mostly with ads and graphics on the web that were terribly written and soaked up a lot of CPU. The same is true for tons of Javascript junk that pollutes the web now, but no one blames the language or the interpreter for that. AS3 ran inside a VM, so garbage collection wasn't linked to the browser's needs the way an embedded JS engine's would be (although it could take hints from the browser, as I recall). But the GC was excellent if code was properly written, and that meant a lot of good practices like ensuring weak references in event listeners and destroying / tearing down instances. You had to write code in a way that the GC would know to mark and sweep. Having said that, I tested a 500,000 line, single bullet Flash gaming site running on a beta version of the Flash plugin for iOS/Safari in 2012, on an iPhone 5, that was running particle systems and multiple game animations on screen with performance that would almost rival a javascript-based game now on phones that are 15 generations improved. If written well, and with a good understanding of how it managed memory, and keeping in mind what you had up on the GPU, from about 2012-2015 you could make the AS3 VM perform about as well or better than a reasonable graphics stack like PixiJS performs in 2026, on much lesser hardware. And you could definitely avoid memory leaks if you took care to.
It's interesting to me whenever developers say "actually this framework/language/library/platform that's popular and lauded for how accessible it makes development has great performance as long as you dig into the architecture and write code skillfully" because the broad consensus among users is that they will not.
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.
3 replies →
Flash had horrific security and accessibility, along with Adobe just being a suck company in general. When you couple that with browser integration issues it just becomes a stack of issues that people became tired with in general.
I definitely blame JS whenever I have to interact with some websites or Electron applications :) Even coding agents. I made my own agent in d-lang just because I'm alergic to installing anything that requires node.js.
> This is really an Apple thing, rigidly enforcing whatever their current OS aesthetic looks like.
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.
most web elements are actually native components. The advantage to letting the device/OS decide how the components work is that say a handheld device will handle the drop-down select-box in their own way, allowing for new devices to improve the user experience.
> But Apple (or Xerox) invented the UI paradigms we're still living with.
Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
> By 2010 or so, it had the capability to leverage the GPU on pretty much any device
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.
> except for one: It was closed source.
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
This is absolutely false. Stage resizing and browser hooks for window resize were fundamental in Flash. (only in Chrome after 2017 did those events stop being delivered until after the window resize finished; prior to that they were delivered per frame). For complex Flex/Flash/AIR apps, layouts could be animated into new positions on the fly at 60fps as windows resized. I wrote three completely separate game platforms in AS3, and a full web CMS platform with dozens of widgets, and a file system manager, with interfaces that were as responsive as what you'd get from modern css. In many ways, creating responsive grids with proper text and image reflow was much easier, especially if you wanted something to "break the grid" on certain layout sizes. This was at a time when float:left was the HTML standard for wrapping text around an image block. In Flash you could define sizes and a vector line for text to runaround an image. The text handling for responsive resize and layout was light years ahead of native browser text rendering. Multi-column text and drop caps existed first in Flash. Whole magazines were written in it. Speaking as a graphic designer as well as a coder, I think the JS SPA web is on the whole much less responsive than Flash SPAs were, because of the poor flex-and-grid paradigm we're currently saddled with. And it's visually far more constrained to as couple of @media queries.
Responsiveness is overrated. I use a phone with one hand (unless typing). I use a tablet with two hands (unless on a stand), and I use my PC with a mouse and keyboard. The biggest benefits for me is when the developer think about the layout and specific widgets for each type of device and not merely reflow them.
Something like procreate would be horrible with mouse/keyboard. UX is not merely a function of size.
Flash generated SVGs so it could be resized to any screen.
Resizing (scaling) isn't the point. It's re-layout that's the point.
> except for one: It was closed source.
And it was a security nightmare...
IIRC Firefox was the first one to move extensions to a separate process so a hung/crashed extension wouldn't take down the whole browser.
That's when I learned about the halting problem.
..., slow and resource-hungry, prone to crash, ...
Slower than pages with HTML+CSS with tiny bit of JS. Much faster and leaner than current JS SPAs.
1 reply →