Because developers can suck.

I work with developers in SCA/SBOM and there are countless devs that seem to work by #include 'everything'. You see crap where they include a misspelled package name and then they fix it by including the right package but not removing the wrong one!.

The lack of dependency awareness drives me insane. Someone imports a single method from the wrong package, which snowballs into the blind leading the blind and pinning transitive dependencies in order to deliver quick "fixes" for things we don't even use or need, which ultimately becomes 100 different kinds of nightmare that stifle any hope of agility.

In a code review a couple of years ago, I had to say "no" to a dev casually including pandas (and in turn numpy) for a one-liner convenience function in a Django web app that has no involvement with any number crunching whatsoever.

Coincidentally, Copilot has been incredibly liberal lately with its suggestions of including Pandas or Numpy in a tiny non-AI Flask app, even for simple things. I expect things to get worse.

There's a ton you can do with sqlite, which is in the Python standard library. You just have to think about it and write some SQL instead of having a nice Pythonic interface.

To push back on this, I consider pandas/numpy so crucial to Python as a whole they are effectively stdlib to me. I wouldn't blink at this because it would happen sooner or later.

Unless is was absolutely critical the server have as small as a footprint as humanly possible and it was absolutely guaranteed there would never need to be included in the future of course. However, that first constraint is the main one.

You forgot the "/s"?

Automated dependency resolution has made it so the default is frequently

> Someone imports a single method from the RIGHT package

and hundreds of megabytes come in for what might be one simple function.

and when that fails #pragma once, oh the memories!

>> their software also downloaded a 250MB update file every five minutes

> How on earth is a screen recording app 250 megabytes

How on earth is a screen recording app on a OS where the API to record the screen is built directly into the OS 250 megabytes?

It is extremely irresponsible to assume that your customers have infinite cheap bandwidth. In a previous life I worked with customers with remote sites (think mines or oil rigs in the middle of nowhere) where something like this would have cost them thousands of dollars per hour per computer per site.

> It is extremely irresponsible to assume that your customers have infinite cheap bandwidth

Judging by the price of monitor stands, I wouldn't be surprised for Apple to make such assumptions.

For a long time iOS did not have features to limit data usage on WiFi. They did introduce an option more recently for iPhone, but it seems such an option is not available to MacOS. Windows supported it as far as I could remember using it with tethering.

screen studio is pretty great, it has a lot of features and includes a simple video editor

Or.. Why on earth you need to check for updates 288x per day. It sounds and seems more like 'usage monitoring' rather than being sure that all users have the most recent bug fixes installed. What's wrong with checking for updates upon start once (and cache per day). What critical bugs or fixes could have been issued that warrant 288 update checks.

A 250MB download should be opt-in in the first place

I got 8 :)

Do you mean 8 homes with 10Gb Ethernet, or 1 home with 8 10Gb Ethernet connections?

8 of the 10 Gbits I meant :) sorry I see it reads a bit weird yes. So 8 gbit for single line is the max currently. But huge competition on the horizon, so I expect soon more :)

8 people who have 10Gb Ethernet at home

I read it as 1 x 8GB connection But that’s only because I think 8GB is offered in my area. I’ve limited my current service to 1.5GB / 1GB fibre, because well I only run gbit Ethernet … so more sounds totally unnecessary

It sounds right, and this is the kind of thing I'd expect if developers are baking configuration into their app distribution. Like, you'd want usage rules or tracking plugins to be timely, and they didn't figure out how to check and distribute configurations in that way without a new app build.

> they didn't figure out how to check and distribute configurations in that way without a new app build.

Any effort to use their brain shall be drastically punished. /s

What's wrong with checking for updates upon start once (and cache per day)

For me that would also be wrong, if I cannot disable it in the configuration. I do bot want to extend startup time.

Wait until you learn about non-blocking IO. And threads.

It's a whole new world out there.

If you're expecting the guys shipping the 250mb bloated app to get this right i might haave a bridge to sell you

Pretty snarky and useless comment. It is clear I mean also, for example, noot use BW for that.

They probably just combined all phoning home information into one. Usage monitoring includes version used, which leads to automatic update when needed (or when bugged...).

Unpacked, it's actually 517M on disk:

   517M  ─┬ Screen Studio.app                     100%
   517M   └─┬ Contents                            100%
   284M     ├─┬ Resources                          55%
   150M     │ ├── app.asar                         29%
   133M     │ └─┬ app.asar.unpacked                26%
   117M     │   ├─┬ bin                            23%
    39M     │   │ ├── ffmpeg-darwin-arm64           8%
    26M     │   │ ├── deep-filter-arm64             5%
    11M     │   │ ├─┬ prod                          2%
  10.0M     │   │ │ └── polyrecorder-prod           2%
    11M     │   │ ├─┬ beta                          2%
  10.0M     │   │ │ └── polyrecorder-beta           2%
  10.0M     │   │ ├── hide-icons                    2%
   9.9M     │   │ ├─┬ discovery                     2%
   8.9M     │   │ │ └── polyrecorder                2%
   5.6M     │   │ └── macos-wallpaper               1%
    16M     │   └─┬ node_modules                    3%
    10M     │     ├─┬ hide-desktop-icons            2%
  10.0M     │     │ └─┬ scripts                     2%
  10.0M     │     │   └── HideIcons                 2%
   5.7M     │     └─┬ wallpaper                     1%
   5.7M     │       └─┬ source                      1%
   5.6M     │         └── macos-wallpaper           1%
   232M     └─┬ Frameworks                         45%
   231M       └─┬ Electron Framework.framework     45%
   231M         └─┬ Versions                       45%
   231M           └─┬ A                            45%
   147M             ├── Electron Framework         29%
    57M             ├─┬ Resources                  11%
  10.0M             │ ├── icudtl.dat                2%
   5.5M             │ └── resources.pak             1%
    24M             └─┬ Libraries                   5%
    15M               ├── libvk_swiftshader.dylib   3%
   6.8M               └── libGLESv2.dylib           1%

Is it normal to include the Electron framework like that? Is it not also compiled with the binary? Might be a stupid question, I'm not a developer. Seems like a very, very heavy program to be doing such a straightforward function. On MacOS, I'm sure it also requires a lot of iffy permissions. I think I'd stick with the built-in screen recorder myself.

So looks like the app itself is about 10MB but there are multiple copies of it, a bundled ffmpeg and all kinds of crap like wallpaper?

I'm not sure why there are both app.asar and app.asar.unpacked. I did just run `npx @electron/asar extract app.asar` and confirmed it's a superset of app.asar.unpacked. The unpacked files are mostly executables, so it may have something to do with code signing requirements.

Looks like a one person shop, lots of things not optimised.

As I recall, it’s an Electron app. I just checked and the current version of Google Chrome is 635 MB, with its DMG being 224 MB.

So yes, it’s insane, but easy to see where the size comes from.

firefox is only about 200MB less.

“Only” is doing some heavy lifting there. 200 MB is a lot, both in absolute and relative terms. It means Firefox is a full third smaller.

Regardless, that’s absolutely irrelevant to the point that this app’s size is explained by Chromium’s (and thus Electron’s) size.

Tauri has been a thing for a while, it baffles me people still choose Electron without a good reason to do so.

Also webapps are just great nowadays most OS support install PWA's fairly decently no?

ffs

Tauri is not as platform-agnostic as Electron is because it uses different web views depending on the platform. I ran into a few SVG-related problems myself when trying it out for a bit.

For example, on Linux, it uses WebKitGTK as the browser engine, which doesn't render the same way Chrome does (which is the web view used on Windows), so multi-platform support is not totally seamless.

Using something like Servo as a lightweight, platform-independent web view seems like the way forward, but it's not ready yet.

> Tauri is not as platform-agnostic as Electron

I suspect the real reason electron got used here is that ChatGPT/Copilot/whatever has almost no Tauri example code in the training set, so for some developers it effectively doesn't exist.

>on Linux it uses WebKitGTK

It's about time Linux desktops adopt some form of ${XDG_WEB_ENGINES:-/opt/web_engines} convention to have web-based programs to fetch their engines as needed and play nice with each other.

It has: /dev/null /s

We're talking about a MacOS App. Platform-agnostic is irrelevant.

It's relevant in the broader context, cross-platform is a significant reason people choose Electron, and lighter alternatives like Tauri still have some issues there.

seconded -- tried to use tauri for a cross-platform app but the integrated webview on android is horrendous. had to rewrite basic things from scratch to work around those issues, at which point why am I even using a "cross-platform" framework?

I imagine if you stick to desktop the situation is less awful but still

> Tauri is not as platform agnostic as Electron is

Found this a few months ago: https://gifcap.dev/

Screen recording straight from a regular browser window, though it creates GIFs instead of video files. Links to a git repo so you can set it up locally.

Thanks, didn't knew about Servo, hopefully we'll get there Electron really is bloated and any app using it eats my ram whatever how much of it i have

> Also webapps are just great nowadays most OS support install PWA's fairly decently no?

I would say no, and some are actively moving away from PWA support even if they had it before.

Plus, electron et al let you hook into native system APIs whereas a PWA cannot, AFAIK.

The app itself is probably much bigger than 250mb. If it is using Electron and React/other JS library like a million other UIs just the dependencies will be almost that big.

For context, the latest iOS update is ~3.2GB, and the changelog highlights are basically 8 new emojis, some security updates, some bug fixes. It makes me want to cry.

That 3.2G is some sort of compressed OS image though, right? So it’d be of a constant size relative to whatever changes or updates it brings.

Just my hypothesis: some softwares includes video tutorial accessible offline. A short but not-compressed-high-res video can easily go big.

It was probably written by the type of programmers who criticise programmers like me for using "unsafe" languages.

You probably deserve to be criticized if you think this is the culprit.

"How can I make this about me and my C/C++ persecution complex?"

I don’t use their software but if someone has they should be able to decompile it.

It's an electron app.

I would bet money it's electron