4 ms·

I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead consta

I sometimes wonder how much slower technological progression would have been, if we hadn't taken whatever widget engine any given OS gave us, and instead constantly debated over and recreated every feature in the OS, like we do with web interfaces. 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-users-navigate-flat-ui-designs-22-per-cent-slower/590397 https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.

noduerme 3mo 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.
- 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.
sheept 3mo ago
Isn't that alternate reality the current reality? 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.
- fluoridation 3mo ago
  I'm not sure you're actually describing user's expectations, I think you're describing an oft-held belief about user's expectations among people who fancy themselves UX designers.
  - reb 3mo ago
    Even in the absence of designers' desire to play with established UI: humans respond positively to a mix of accessible novelty and familiar patterns. Knowing when to apply novelty and when to apply the familiar is the game.
- thwarted 3mo ago
  The industry couldn't decide what it wanted for a long time (and maybe still hasn't settled). Pages needed to be consistent visually no matter which platform and browser the page was displayed on (which is odd, few people used the same sites on multiple platforms at the time). Oh, but then it was visually jarring because it didn't match the rest of the platform and you couldn't leverage your knowledge and experience of the platform's UI (the way multi-select worked in drop downs, accessibility). But then you couldn't style the widgets on the page to make your site distinct (styling OSX "lickable candy" widgets didn't work so well since they were so visually unique). And then you had mobile where space is a premium and scrollbars were sometimes visually hidden and the entire application took up the whole screen, so differences from other sites and the platforms as a whole were not as prominent. So all widgets had to be stylable (IIRC, you could style buttons but not scrollbars for a while, which made things inconsistent within a given page itself). And complete control of the "experience" became desirable, the scrollbar was seen as part of the page, not part of the container that holds and displays the page. 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.
bluedino 3mo ago
In the earlier Windows days, Borland and a couple other companies did their own buttons etc https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-9011c3a4efbf/c2afc3b4-c3a3-0f4f-2b11-c3a4c28d5870 https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...
- NoGravitas 3mo ago
  Oh gods, you reminded me of the existence of Borland buttons.
jgalt212 3mo ago
Every once in a while, I do some rudimentary research on what problems the 100s of web UI frameworks are trying to solve versus the UI problems that were solved by Mac and Windows in the 1980s/90s. It's never been a satisfactory exercise.
BobbyTables2 3mo ago
Indeed. Windows 95 was Peak UI. Even Hollywood movies show better UIs than modern crap.

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

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.

sheept 3mo ago

Isn't that alternate reality the current reality? 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.

fluoridation 3mo ago
I'm not sure you're actually describing user's expectations, I think you're describing an oft-held belief about user's expectations among people who fancy themselves UX designers.
- reb 3mo ago
  Even in the absence of designers' desire to play with established UI: humans respond positively to a mix of accessible novelty and familiar patterns. Knowing when to apply novelty and when to apply the familiar is the game.
thwarted 3mo ago
The industry couldn't decide what it wanted for a long time (and maybe still hasn't settled). Pages needed to be consistent visually no matter which platform and browser the page was displayed on (which is odd, few people used the same sites on multiple platforms at the time). Oh, but then it was visually jarring because it didn't match the rest of the platform and you couldn't leverage your knowledge and experience of the platform's UI (the way multi-select worked in drop downs, accessibility). But then you couldn't style the widgets on the page to make your site distinct (styling OSX "lickable candy" widgets didn't work so well since they were so visually unique). And then you had mobile where space is a premium and scrollbars were sometimes visually hidden and the entire application took up the whole screen, so differences from other sites and the platforms as a whole were not as prominent. So all widgets had to be stylable (IIRC, you could style buttons but not scrollbars for a while, which made things inconsistent within a given page itself). And complete control of the "experience" became desirable, the scrollbar was seen as part of the page, not part of the container that holds and displays the page. 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.

bluedino 3mo ago

In the earlier Windows days, Borland and a couple other companies did their own buttons etc https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-9011c3a4efbf/c2afc3b4-c3a3-0f4f-2b11-c3a4c28d5870 https://winworldpc.com/screenshot/c5a0e280-a1c3-974a-24c2-90...

NoGravitas 3mo ago
Oh gods, you reminded me of the existence of Borland buttons.

jgalt212 3mo ago

Every once in a while, I do some rudimentary research on what problems the 100s of web UI frameworks are trying to solve versus the UI problems that were solved by Mac and Windows in the 1980s/90s. It's never been a satisfactory exercise.

BobbyTables2 3mo ago

Indeed. Windows 95 was Peak UI. Even Hollywood movies show better UIs than modern crap.