3 ms·

> Why optimize for size when users don't complain about it? Pride in one's work? Especially when comparing it to the "good old days". Maybe we'd have better mo

> Why optimize for size when users don't complain about it? Pride in one's work? Especially when comparing it to the "good old days". Maybe we'd have better morale if we were allowed (or allowed ourselves, for those of us running our own companies) to indulge in such "useless" optimizations. But no, the pressure is on to keep cranking out more, more, more, with no time for quality that we can be proud of. Edit to add: You're right though that splash screens are less common now.

mike_hearn 2y ago
Well, let's think about the sources of bloat. I'd argue that the primary source of bloat in software today is when there's a mismatch between what developers need and what the underlying platform provides. The most extreme case of this can be found in desktop operating systems where relatively few apps now use the underlying platform at all, largely because nobody wants to write GUI code multiple times. What developers want and what the underlying operating systems provide are almost entirely different so everyone ships a giant runtime to replace what's the OS comes with. Modern mobile platforms have a similar problem, where things like Swift UI or jetpack tend to be bundled with the app or at least were historically up until recently, and that yields bloated packages too. In contrast people get the vapors if a web app is more than 5 MB of download and this happens because the web platform is significantly more responsive to what developers really want even though it has poor technical foundations. Where bloat does occur in web apps, it's because the browser makers have not responded quickly enough or at all to growing mismatches, for example the vdom diffing algorithm react uses could be implemented in the browser itself, but isn't, so lots of apps ship it bundled. Apps for Windows 95 didn't seem bloated, but that's because they relied so heavily on what already came with the computer when you bought it. People just had a suck up the fact that the underlying API was pretty bad, because they couldn't afford to ship anything better and till the CD era came along and then you did start to see apps leave behind the underlying platform and get more bloated. A truly next-gen operating system would make it very difficult to talk precisely about bloat, I think, because if you really went beyond the Unix or NT designs your operating system would download and manage code modules automatically, a little bit like browsers did before the introduction of cache partitioning. How bloated an app appears to be then would depend entirely on what you had previously used and downloaded, and thus to some extent would be in the eye of the beholder. After all, if you measured all of the code paged in by running a native Mac app, or even something like delphi, versus the amount of code paged in by an electron app, it probably wouldn't be that different. It's just that the Mac app is accessing code that is shared with other operating system utilities.
- mwcampbell 2y ago
  Thanks for steering the discussion in a more constructive direction than where I was going. There are C++ UI toolkits wrapping Win32, Cocoa, etc., and sometimes such toolkits are statically linked into the executable, meaning that dead code elimination should be able to minimize the executable size. I'm thinking in particular of wxWidgets. But even with C++ and static linking, it's easy for a library to be designed in such a way that you end up paying for stuff you don't use. The last time I did a project in C++ with wx, 10+ years ago, my program itself was quite trivial, and it only used very basic widgets, but the statically linked Win32 executable still ended up being ~2.5 MB. I didn't get very deep into why, but my understanding is that code for a bunch of features (printing, drag and drop, etc.) got linked in, even though my application wasn't using it, because the window procedure had to handle messages related to those features regardless. I guess, to optimize for minimal executable size, the API would have to be designed to require the application developer to explicitly initialize only the features they need, and in this case, the message handler would have to be more dynamic. Sometime I'd like to design a new toolkit inspired by wx and SWT, in either Rust or Java. In the latter case, I'd use the new Foreign Function and Memory API to call the native APIs. I'd be interested to see how much GraalVM Native Image could optimize an application written with such a toolkit; I recall you've said good things about how much Native Image can optimize program initialization in particular. There seems to be a broad consensus, though, that Win32 in particular isn't suitable for "modern" desktop apps, and so, by extension, neither are wx and SWT. Certainly in the Rust GUI space, all the popular toolkits are drawing their own widgets, and even reimplementing lower layers of the stack like text rendering, thus contributing to the trend you talked about where applications bring along their own runtime. I assume there are actual deficiencies in OS-supplied APIs that are leading to this, though a sufficiently jaded person might argue that developers are in fact wasting their time on unnecessary things for one reason or another. Anyway, if the classic Win32 widgets are still good enough for some parts of the OS itself (although, admittedly, fewer and fewer with each release), then presumably they're good enough for some subset of applications as well, and if the developers of those applications had a convenient and lightweight abstraction layer over those classic widgets, then we could start to reduce bloat.
  - mike_hearn 2y ago
Bluestein 2y ago
> Pride in one's work? Especially when comparing it to the "good old days". Indeed. And, tangentially relevant: Visited a castle today. 1399. Stonemasons used to mark (among other things) their "signature" on rocks they cut.-

mike_hearn 2y ago

Well, let's think about the sources of bloat. I'd argue that the primary source of bloat in software today is when there's a mismatch between what developers need and what the underlying platform provides. The most extreme case of this can be found in desktop operating systems where relatively few apps now use the underlying platform at all, largely because nobody wants to write GUI code multiple times. What developers want and what the underlying operating systems provide are almost entirely different so everyone ships a giant runtime to replace what's the OS comes with. Modern mobile platforms have a similar problem, where things like Swift UI or jetpack tend to be bundled with the app or at least were historically up until recently, and that yields bloated packages too. In contrast people get the vapors if a web app is more than 5 MB of download and this happens because the web platform is significantly more responsive to what developers really want even though it has poor technical foundations. Where bloat does occur in web apps, it's because the browser makers have not responded quickly enough or at all to growing mismatches, for example the vdom diffing algorithm react uses could be implemented in the browser itself, but isn't, so lots of apps ship it bundled. Apps for Windows 95 didn't seem bloated, but that's because they relied so heavily on what already came with the computer when you bought it. People just had a suck up the fact that the underlying API was pretty bad, because they couldn't afford to ship anything better and till the CD era came along and then you did start to see apps leave behind the underlying platform and get more bloated. A truly next-gen operating system would make it very difficult to talk precisely about bloat, I think, because if you really went beyond the Unix or NT designs your operating system would download and manage code modules automatically, a little bit like browsers did before the introduction of cache partitioning. How bloated an app appears to be then would depend entirely on what you had previously used and downloaded, and thus to some extent would be in the eye of the beholder. After all, if you measured all of the code paged in by running a native Mac app, or even something like delphi, versus the amount of code paged in by an electron app, it probably wouldn't be that different. It's just that the Mac app is accessing code that is shared with other operating system utilities.

mwcampbell 2y ago
Thanks for steering the discussion in a more constructive direction than where I was going. There are C++ UI toolkits wrapping Win32, Cocoa, etc., and sometimes such toolkits are statically linked into the executable, meaning that dead code elimination should be able to minimize the executable size. I'm thinking in particular of wxWidgets. But even with C++ and static linking, it's easy for a library to be designed in such a way that you end up paying for stuff you don't use. The last time I did a project in C++ with wx, 10+ years ago, my program itself was quite trivial, and it only used very basic widgets, but the statically linked Win32 executable still ended up being ~2.5 MB. I didn't get very deep into why, but my understanding is that code for a bunch of features (printing, drag and drop, etc.) got linked in, even though my application wasn't using it, because the window procedure had to handle messages related to those features regardless. I guess, to optimize for minimal executable size, the API would have to be designed to require the application developer to explicitly initialize only the features they need, and in this case, the message handler would have to be more dynamic. Sometime I'd like to design a new toolkit inspired by wx and SWT, in either Rust or Java. In the latter case, I'd use the new Foreign Function and Memory API to call the native APIs. I'd be interested to see how much GraalVM Native Image could optimize an application written with such a toolkit; I recall you've said good things about how much Native Image can optimize program initialization in particular. There seems to be a broad consensus, though, that Win32 in particular isn't suitable for "modern" desktop apps, and so, by extension, neither are wx and SWT. Certainly in the Rust GUI space, all the popular toolkits are drawing their own widgets, and even reimplementing lower layers of the stack like text rendering, thus contributing to the trend you talked about where applications bring along their own runtime. I assume there are actual deficiencies in OS-supplied APIs that are leading to this, though a sufficiently jaded person might argue that developers are in fact wasting their time on unnecessary things for one reason or another. Anyway, if the classic Win32 widgets are still good enough for some parts of the OS itself (although, admittedly, fewer and fewer with each release), then presumably they're good enough for some subset of applications as well, and if the developers of those applications had a convenient and lightweight abstraction layer over those classic widgets, then we could start to reduce bloat.
- mike_hearn 2y ago

Bluestein 2y ago

> Pride in one's work? Especially when comparing it to the "good old days". Indeed. And, tangentially relevant: Visited a castle today. 1399. Stonemasons used to mark (among other things) their "signature" on rocks they cut.-