3 ms·

The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. It had zero mouse support, its keyboards lacked almost ever

The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. It had zero mouse support, its keyboards lacked almost every key, and its audio output was simply terrible. I don't think it supported IMEs or screen readers either. When I'm doing desktop work, I'd take a 300MB browser application over a SNES any day. The laudable terms used in the Tauri benchmark was a tad silly (though it makes some sense, as Tauri competes with Electron, not with normal native toolkits) but modern GUIs require more processing power than those 160x120 GUIs from back in the way did. It also helps a lot that you can subscribe to modern app subscriptions for half a decade before you've paid the price of what software used to cost (software that would be outdated by next year, and you had to pay again to upgrade), and that old price didn't come with hosting of any kind either. Programmers have always been lazy, but the modern laziness when it comes to performance isn't because nobody cares; it's because nobody is willing to pay for the kind of responsiveness of yore anymore.

mwcampbell 2y ago
This is the standard response, and I've given it myself, but I refuse to accept that we need all of the bloat of Chromium in order to do internationalization, accessibility, fast high-resolution rendering, etc. I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS). And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either. But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.
- josephg 2y ago
  Yeah the other reference point I sometimes think about is the old windows IRC client mIRC. mIRC was super fully featured - it supported downloads, scripting (I think it had its own embedded scripting language), colors, and all sorts of other wild things that I never learned to use. It had way more features than modern discord, although it was missing discord's voice chat, video chat and screen sharing. (And it obviously didn't have any of the modern encryption algorithms). I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.
  - jeroenhd 2y ago
    Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with. These days applications all seem to ship their own copy of every system DLL so they can work on every platform without having to support different APIs. As a result, mIRC only worked on Windows. If mIRC is all you need, mIRC still works just fine. It's still maintained, so unlike ancient versions of MS Office, you can be reasonably safe while using it!
    - josephg 2y ago
      > Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with. Hundreds of megabytes is overstating it. Windows 98 was 175mb for the entire OS, including the kernel and all included applications. I doubt the windows UI library of the day (winforms, gdi, etc) totalled more than 20mb. (But please fact check!) And, I don’t think browser engines like electron do ship their own system dlls. Dlls are only relevant on windows - they won’t do you any good on Linux or macOS. And windows always comes with those dlls. I’m pretty sure chrome on windows still makes use of a lot of the underlying windows APIs to render content on webpages in a system-native way. It just has its own layer of heavily custom UI code layered on top. But yeah, it’s cool that applications like mirc still work. It would definitely be a fun project to make a Spotify client or something in zig using winforms. It would be a fun exercise to make something so small.
josephg 2y ago
> The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. So what? None of that stuff necessitates such obnoxious computing requirements. How would you fill 2.4 billion bits of ram with the stuff needed to support a 120hz display? You can run quake 3 at 120fps on a potato, and I promise you a full multiplayer 3d game engine has much higher ram and compute requirements than a font engine with a single font loaded. > it's because nobody is willing to pay for the kind of responsiveness of yore anymore. Aren't they? With an attitude like that, how would you know? Sometimes I imagine an alternate universe where computer hardware doesn't get faster every year. In this world, consumers only replace their computers and phones when they physically break. As a result, our software couldn't keep getting slower over time. Any increasing bloat & new features would usually need to be "paid for" performance wise with newly added optimisations. For most consumers, everything would look more or less the same. All the software most people depend on (email, teams, the web, etc) would run the same as it does today. But miraculously, people would save thousands every year by getting off the computer hardware treadmill. Across the whole world, hundreds of billions of dollars per year of money spent on computers would be saved. There's no way you could convince someone living in that alternate reality that our reality makes any amount of sense. The cost would be that programmers would need to stop getting increasingly lazy every year. We'd just need to stop at the current laziness level. Can we manage that? Apparently not. Instead we have attitudes like yours. "My hello world app is actually similar to crysis in its computing requirements. It somehow needs 300mb of RAM to be able to render text at 120fps, because thats how that works."
- jeroenhd 2y ago
  I'd love for every application to be a few megabytes in size like in the old days. I'm a big proponent of building applications using native code and OS native controls, as far as those still exist. Unfortunately, nobody sells that software anymore. If you think you can make competing software for the Teams/Slacks of this world that runs the way programs written for Windows 2000 run today by just convincing a few developers not to be lazy, you stand to make a LOT of money. I'd welcome your attempt for sure. Everyone knows there's no strict necessity to modern desktop bloat, but nobody seems to have come up with a solution other than "what if we all did a lot more hard work (mostly for free)".

mwcampbell 2y ago

This is the standard response, and I've given it myself, but I refuse to accept that we need all of the bloat of Chromium in order to do internationalization, accessibility, fast high-resolution rendering, etc. I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS). And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either. But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.

josephg 2y ago
Yeah the other reference point I sometimes think about is the old windows IRC client mIRC. mIRC was super fully featured - it supported downloads, scripting (I think it had its own embedded scripting language), colors, and all sorts of other wild things that I never learned to use. It had way more features than modern discord, although it was missing discord's voice chat, video chat and screen sharing. (And it obviously didn't have any of the modern encryption algorithms). I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.
- jeroenhd 2y ago
  Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with. These days applications all seem to ship their own copy of every system DLL so they can work on every platform without having to support different APIs. As a result, mIRC only worked on Windows. If mIRC is all you need, mIRC still works just fine. It's still maintained, so unlike ancient versions of MS Office, you can be reasonably safe while using it!
  - josephg 2y ago
    > Programs like mIRC benefitted a lot from the hundreds of megabytes of Windows libraries that the OS shipped with. Hundreds of megabytes is overstating it. Windows 98 was 175mb for the entire OS, including the kernel and all included applications. I doubt the windows UI library of the day (winforms, gdi, etc) totalled more than 20mb. (But please fact check!) And, I don’t think browser engines like electron do ship their own system dlls. Dlls are only relevant on windows - they won’t do you any good on Linux or macOS. And windows always comes with those dlls. I’m pretty sure chrome on windows still makes use of a lot of the underlying windows APIs to render content on webpages in a system-native way. It just has its own layer of heavily custom UI code layered on top. But yeah, it’s cool that applications like mirc still work. It would definitely be a fun project to make a Spotify client or something in zig using winforms. It would be a fun exercise to make something so small.

josephg 2y ago

> The Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. So what? None of that stuff necessitates such obnoxious computing requirements. How would you fill 2.4 billion bits of ram with the stuff needed to support a 120hz display? You can run quake 3 at 120fps on a potato, and I promise you a full multiplayer 3d game engine has much higher ram and compute requirements than a font engine with a single font loaded. > it's because nobody is willing to pay for the kind of responsiveness of yore anymore. Aren't they? With an attitude like that, how would you know? Sometimes I imagine an alternate universe where computer hardware doesn't get faster every year. In this world, consumers only replace their computers and phones when they physically break. As a result, our software couldn't keep getting slower over time. Any increasing bloat & new features would usually need to be "paid for" performance wise with newly added optimisations. For most consumers, everything would look more or less the same. All the software most people depend on (email, teams, the web, etc) would run the same as it does today. But miraculously, people would save thousands every year by getting off the computer hardware treadmill. Across the whole world, hundreds of billions of dollars per year of money spent on computers would be saved. There's no way you could convince someone living in that alternate reality that our reality makes any amount of sense. The cost would be that programmers would need to stop getting increasingly lazy every year. We'd just need to stop at the current laziness level. Can we manage that? Apparently not. Instead we have attitudes like yours. "My hello world app is actually similar to crysis in its computing requirements. It somehow needs 300mb of RAM to be able to render text at 120fps, because thats how that works."

jeroenhd 2y ago
I'd love for every application to be a few megabytes in size like in the old days. I'm a big proponent of building applications using native code and OS native controls, as far as those still exist. Unfortunately, nobody sells that software anymore. If you think you can make competing software for the Teams/Slacks of this world that runs the way programs written for Windows 2000 run today by just convincing a few developers not to be lazy, you stand to make a LOT of money. I'd welcome your attempt for sure. Everyone knows there's no strict necessity to modern desktop bloat, but nobody seems to have come up with a solution other than "what if we all did a lot more hard work (mostly for free)".