A 2024 Plea for Lean Software

If any modern software company was given a spec sheet for Ventrilo (<a href="https:&#x2F;&#x2F;www.ventrilo.com&#x2F;about.php" rel="nofollow">https:&#x2F;&#x2F;www.ventrilo.com&#x2F;about.php</a>) and asked to develop it, you would get back a few hundred Mb installer that needed to download additional components, would send telemetry to their servers all day and check for updates, add background services to startup, and consume half a gig of ram while continuously managing to use a percent or two of your CPU at idle and probably even tapping the GPU to do god knows what.<p>Meanwhile Ventrilo 3 has a 5.4 Meg installer, consumes 4 megs of RAM, and does none of those things. The newer bloated version has a 7.9 meg installer.

I feel that we would&#x27;ve had better tooling for writing performant GUI apps today if electron JS never took off.<p>It certainly has its place, and I laud the authors for their efforts, but seeing how <i>every</i> startup is using electron for their native applications, I have little hope for lean software.<p>At the end of the day, developers need to finance their projects. No other toolchain out there [1] is going to give you the flexibility, development speed, and freedom to develop beautiful looking desktop apps using the muscle memory you trained while writing webpages. Of course, you can write the same application in Qt, GLFW, whatever, but I don&#x27;t think anyone will disagree that it&#x27;s much slower to build and prototype responsive UIs with these tools.<p>[1] Wry and Tauri (<a href="https:&#x2F;&#x2F;tauri.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tauri.app&#x2F;</a>) might be noteworthy, but I don&#x27;t know how much of a difference they make, as the runtime is still JavaScript, HTML, and CSS.

The software crisis was proclaimed to exist as early as 1969. We never solved it. But we did massively improve the scope of what software can do. The natural state of software is always to be almost but not quite at the breaking point. This is actually fine. Occasionally something goes wrong and then we fix it. And we move on. But the amount of stuff that works just fine is actually constantly growing.<p>The average software project sits on ginormous mountain of existing software. Libraries, components, tools, operating systems, etc. As a percentage of the overall source code, the tiny bit you add is a vanishingly small proportion. All this stuff exists, is being maintained by someone, and replacing it with something else has very low economic value. It adds negative value when it doesn&#x27;t work because then you have to fix it or deal with the problems it is causing. But if it works as advertised, it just levels the playing field. Because everybody else is at that level as well.<p>Your attention as a software engineer should be focused mainly on things that others don&#x27;t have that are valuable. It&#x27;s always been like that. What has changed over time is the amount of stuff that you no longer have to build or worry about that much. That&#x27;s the value of cloud based services. You get a lot of decent quality stuff that you pay a premium for that would be very expensive to match with in house development. Reinventing wheels like that is not lean but stupid.

This article is a bit hyprocritical. The example is an image sharing tool, but you don&#x27;t resize images at all.<p>So your server binary is tiny, but you&#x27;re serving full size unoptimized images and wasting bandwidth for every single user that visits the site, as well as the uploader. Even thumbnails are served full size.<p>In this case you&#x27;re optimizing for the wrong thing.

While I generally agree with the article, the &quot;reality check&quot; project seems somewhat forced: there are many widely used projects that are fairly lean. Many of the GNU projects are like that, not to mention explicitly minimalistic ones, and generally on a GNU&#x2F;Linux system (either server or desktop) you have a few notable resource hogs, but the rest you would barely notice. Many of those can be built without Python build-time dependencies, too. And there are tens of thousands of proper packages in common distributions&#x27; repositories, so surely it is possible. The mentioned Electron, Node.js, and SaaS examples probably happen more often in certain other settings, perhaps enterprise software tends to be like that. Likely its advocates would bring up speed and cost of development, and it may be argued that even security is improved with those, given the other constraints. A more interesting &quot;reality check&quot; may be to take a few actual (and preferably somewhat widely used) bloated projects, and implement leaner alternatives, while fitting into the same constraints: similar profits for commercial projects, maybe similar initial expertise levels, time spent, and perceived impact for non-commercial ones.

Maybe we should drop the idealism and be realistic: for various reasons bloatware is not going away. If we were to admit something like that, the next question is what can be done? We need better tooling for generating and reasoning about software manifests and supply chains, and we need better tooling and training for at least lightweight formal methods in design &#x2F; development phases. Industry adoption of such things is not impossible but it needs to be more accessible to devs without phds and it needs to be faster&#x2F;cheaper.

Mesa alone is like 50mb of tightly optimized x86-64 machine code (Windows 95, by comparison, came on 8x1.4mb floppies); and that&#x27;s just to talk to the actual kernel drivers - you need that for the GPU to draw things on the screen (unless you want software rendering = idle silicon).<p>Does every program need all of that code? There&#x27;s libraries in there to handle OpenGL (in half a million different versions), Vulkan, AMD, Intel, Nouveau, etc... Nope, you usually need just the tiny bits relevant to your application+hardware. But what&#x27;s easier, figuring out which bits you don&#x27;t need - or making the stack more portable and future-proof, by always shipping everything?<p>A lot of complexity is accidental, but most of it comes from conscious choices to make life simpler for everyone. Of course taken to the logical extreme, we do end up with Electron, but where are we supposed to draw the line?

The article doesn&#x27;t mention the most basic cause and issue: motivations. One guy writes absurdly bloated and bug prone code, but creates workable components&#x2F;products&#x2F;whatever in a month. Another guy writes tight, elegant, and rock solid code for the same thing in 6 months. The first guy&#x27;s getting promoted and the second guy&#x27;s going to end up having to explain his &#x27;lack of productivity.&#x27;<p>It creates a motivation system of to get something working, or even more cynically to just get something that looks like its working. The half dozen intermittently en vogue development acronyms also further this mindset. I don&#x27;t see how to overcome this issue, because it&#x27;s something like a tragedy of the commons. Nobody (at the top) wants to reduce bloat because it would likely reduce rather than increase profit on short time frames. Yet, at scale, it&#x27;s leading to a complete enshittification of all software.

The funny thing to me about this is that Trifecta is still less lean than the minimal “image sharing site”: copy the images to a web root (for drag and drop, use Samba, NFS or your favorite remote mounting protocol over an internal network). Have a minimally-configured web server serve the image (perhaps with some html generator to make an actual page).<p>A while back, I wanted to host a pastebin for sharing bits of code and other text. Then I realized that about 10 lines of (compile-time) elisp gave me everything I needed to turn any webserver I could ssh to into a pastebin with no runtime dependencies aside from nginx: <a href="https:&#x2F;&#x2F;fwoar.co&#x2F;pastebin&#x2F;3daaf7ce49ca221702c70b0d10ac5caec8962b78.el*.html" rel="nofollow">https:&#x2F;&#x2F;fwoar.co&#x2F;pastebin&#x2F;3daaf7ce49ca221702c70b0d10ac5caec8...</a>

I just released an update to my open source tool where the binary+dll size was reduced from 33mb to 1.4mb. Feels good to get rid of bloat.

I’m struggling with this post because it seems to imply that software quality has gotten worse over time. Bluntly put: I think this is nonsense.<p>I remember using Windows 9x, the running jokes about poor quality and security of all MS products. Adobe’s formats came from those early days and are roundly mocked. Hell, I’ve built replacements for 90s software and, I can assure you, what I replaced was not high quality or robust at all.<p>On this very site, we discussed Horizon: a project started in the 90s and 20000s that was so badly built that it led to hundreds of innocent sub-postmasters being imprisoned, bankrupted and a number committed suicide.<p>Is the author just romanticising the “good old days?”

&gt;Software security is dire<p>It&#x27;s 2024, why are we still blaming everything <i>except the Operating Systems?</i><p>&gt; simple products importing 1600 dependencies of unknown provenance.<p>Put yourself back in 1984... you&#x27;ve got an IBM XT with 2 floppy disks. You made write protected copies of all your important disks, and even more copies of your boot disk.<p>You&#x27;d go to a computer show, or your user group, and come home with <i>stacks of software of unknown provenance</i>, and then just try everything out over the next few weeks.<p>You were safe because <i>your system made it easy to know what you were risking</i> when you ran a program. There was one simple rule that was easy to understand:<p><i>Only un-write protected floppy disks in the drives were at risk</i>.<p>That quite limited computer system was, in effect, a capability based security system. Crude, but extremely effective.<p>Here it is 40 years later, and the ability to just run code with abandon <i>like we used to</i> seems to be a fantasy to younger people. Because we don&#x27;t expect our operating systems to be at least as safe as MS-DOS on an IBM-XT.

&quot;I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you, we are not merely suffering from nostalgia: software really is very weird today.&quot;<p>What about suffering software users.<p>&quot;! want to end this post with some observations from Niklaus Wirth&#x27;s 1995 paper.<p>&quot;To Some, complexity equals power. (...) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling - the incomprehensible should cause suspicion rather than admiration.&quot;&quot;<p>Who were the &quot;some people&quot; to which Wirth referred. A wild guess: software developers.

I wish legislation was pushing for open APIs.<p>I know many people push for interoperability, but that is a very hard problem. Open APIs are easy; I should be able to write e.g. my own Slack client, for my specific platform.<p>It is not a problem that there exists an (official) ElectronJS Slack app. The problem is that I am forced to use it. And what does it bring to Salesforce, except an opportunity to add telemetry in the app? With an open API, they would still make companies pay 5$ per account per month.<p>I believe that open APIs would enable better clients for popular services.

That is why I&#x27;ve decided to develop all my apps in Qt C++ and QML. For example I&#x27;ve created Plume[1] - an alternative to the resource-hag Electron app Notion. It&#x27;s the fastest block editor in my benchmarks (on the website). Faster than the fastest comparable native app on macOS.<p>Yes, Qt is quite a bloaty - the binary size is 139.2mb currently, but I think with static linking and some trimming, I can get it much lower.<p>[1] <a href="https:&#x2F;&#x2F;www.get-plume.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.get-plume.com&#x2F;</a>

I already experience the change in perspective that the new legislation caused. The new legislation requires software to be developed compliant to standards that define detailed thread and risk analysis processes and requires suppliers to offer updates for all their customers if a security breach was found in their software or in a dependency. This often is a big logistically challenge. Both requirements already lead us to rethink which dependencies we want to include in our software.

But you can&#x27;t have the cake and eat it too. We can&#x27;t expect every company to maintain native apps for every platform and a website on top of that; not relying on 3rd party packages and instead to write everything themselves. Maintaining all that, they&#x27;re bound to f-up at some point and expose vulnerabilities.

I&#x27;m actually surprised that grafana is just 350 MB, I deal with more trivial images which pack 700-800 MBs.

Seems like a lot of complaining and the only solution offered is regulation or “just do it better”? Ok.

To commenters claiming this is nonsense, I can point at Firefox packaging for Linux, which is now on Snap, and it&#x27;s like Docker container. A little version bump happens silently and eats up __extra__ ~500 MB (old versions are kept!), where it used to be (just ~5 years ago) like 50MB for the whole binary, and it was replaced upon update.<p>And recently, I&#x27;ve installed `clickhouse-client` (a new SQL database), which needs almost 900 MB for just a CLI client!!! Absolutely insane!<p>I use QGIS, which is an open source alternative to ArcGIS, and a non-IT friend asked something to draw maps and see imagery -- I recommended QGIS, and he wrote: &quot;1 GIG download? WTF IS THAT?&quot; Oops. We didn&#x27;t notice the little alternative open-source app turned into such a behemoth. (<a href="https:&#x2F;&#x2F;download.osgeo.org&#x2F;qgis&#x2F;windows&#x2F;weekly&#x2F;?C=M&amp;O=D" rel="nofollow">https:&#x2F;&#x2F;download.osgeo.org&#x2F;qgis&#x2F;windows&#x2F;weekly&#x2F;?C=M&amp;O=D</a> -- actually, since last year, it grew by 20%!)<p>The reason for this kind of bloat to me seems the race for version updates. And it probably did make sense in late &#x27;00s, when you could claim Linux ecosystem be underdeveloped. But 15 years late, it&#x27;s still here. Every package is updated at high pace, breaking stuff downstream, and now instead of settling on compatibility, everybody just started to ship docker containers.

Google are the worst. The dependencies for something a simple as the official cloud storage client are horrendous. I just want to download a file from a bucket, why do I need all this cruft.

I just downloaded a freshly minted app from Notion called Notion calendar. It looks beautiful, and it&#x27;s download size is 84Mb! Most likely an electron app.

By 2030, if not sooner, the idea of humans writing software will be very quaint.