4 ms·

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 livi

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.

master-lincoln 3mo ago
> except for one: It was closed source. And it was a security nightmare...
- thyristan 3mo ago
  ..., slow and resource-hungry, prone to crash, ...
  - Sankozi 3mo ago
    Slower than pages with HTML+CSS with tiny bit of JS. Much faster and leaner than current JS SPAs.
    - noduerme 3mo ago
      This is the right way to look at it. Anything with a ton of JS ads chewing up memory now is just as bad, or worse, than a ton of Flash ads were in the early 2000s. But Flash sites were, essentially, SPAs at the time. And they were far more performant than most JS SPAs are now (although a lot of that also has to do with React/Vue/etc. and how poorly-trained coders choose to deploy them).
- OptionOfT 3mo ago
  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.
Cthulhu_ 3mo ago
> 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.
- z3t4 3mo ago
  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.
whstl 3mo ago
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.
- ben_w 3mo ago
  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
  - whstl 3mo ago
    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.
Shorel 3mo ago
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.
- noduerme 3mo ago
  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.
  - Shorel 3mo ago
    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.
  - 3mo ago
paulryanrogers 3mo ago
> But Apple (or Xerox) invented the UI paradigms we're still living with. Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.
realusername 3mo ago
> 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.
socalgal2 3mo ago
> 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
- skydhash 3mo ago
  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.
- goatlover 3mo ago
  Flash generated SVGs so it could be resized to any screen.
  - socalgal2 3mo ago
    Resizing (scaling) isn't the point. It's re-layout that's the point.
- noduerme 3mo ago
  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.

master-lincoln 3mo ago

> except for one: It was closed source. And it was a security nightmare...

thyristan 3mo ago
..., slow and resource-hungry, prone to crash, ...
- Sankozi 3mo ago
  Slower than pages with HTML+CSS with tiny bit of JS. Much faster and leaner than current JS SPAs.
  - noduerme 3mo ago
    This is the right way to look at it. Anything with a ton of JS ads chewing up memory now is just as bad, or worse, than a ton of Flash ads were in the early 2000s. But Flash sites were, essentially, SPAs at the time. And they were far more performant than most JS SPAs are now (although a lot of that also has to do with React/Vue/etc. and how poorly-trained coders choose to deploy them).
OptionOfT 3mo ago
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.

Cthulhu_ 3mo ago

> 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.

z3t4 3mo ago
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.

whstl 3mo ago

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.

ben_w 3mo ago
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
- whstl 3mo ago
  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.

Shorel 3mo ago

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.

noduerme 3mo ago
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.
- Shorel 3mo ago
  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.
- 3mo ago

paulryanrogers 3mo ago

> But Apple (or Xerox) invented the UI paradigms we're still living with. Others invented plenty of UI paradigms before Apple: swiping, skeomorphism, etc.

realusername 3mo ago

> 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.

socalgal2 3mo ago

> 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

skydhash 3mo ago
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.
goatlover 3mo ago
Flash generated SVGs so it could be resized to any screen.
- socalgal2 3mo ago
  Resizing (scaling) isn't the point. It's re-layout that's the point.
noduerme 3mo ago
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.