> 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 250 megabytes
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!.
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.
> Someone imports a single method from the RIGHT package
and hundreds of megabytes come in for what might be one simple function.
> 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.
Judging by the price of monitor stands, I wouldn't be surprised for Apple to make such assumptions.
Any effort to use their brain shall be drastically punished. /s
For me that would also be wrong, if I cannot disable it in the configuration. I do bot want to extend startup time.
It's a whole new world out there.
I've read on HN that a lot of people have 10Gb Ethernet at home. /s
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%So yes, it’s insane, but easy to see where the size comes from.
Also webapps are just great nowadays most OS support install PWA's fairly decently no?
ffs
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.
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.
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.
I imagine if you stick to desktop the situation is less awful but still
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.
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.
Regardless, that’s absolutely irrelevant to the point that this app’s size is explained by Chromium’s (and thus Electron’s) size.