I don't think bundle size is a legitimate/relevant criticism of a modern graphical application, unless we're talking double- or triple-digit gigabytes. I have 8000GB in my portable machine.
And even if it were, the size of an application in relation to its purpose is a relevant metric.
Our ancestors would argue that a 1MB application was bloated. Our children will complain about 1000GB bundles.
The programs, of course, do vastly different things as the realm of what is possible with technology inexorably advances.
Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges, and the curmudgeons who are shaking their collective canes at the kids on their lawn are actually technically competent and can recognize this if they choose.
There are legitimate technical criticisms to doing things with JS and Electron and whatnot; but "the bundle is hundreds of megabytes" isn't that.
No, we really don't, because these libraries are available to other programs as well, whereas a huge packaged application is availabe to nothing than itself.
> To really compare them properly, you'd also need to make the typescript compiled into equivalent JS VM assembly.
That's like saying, to compare Usain Bolt and myself in terms of sprinting performance, you should consider the fact that I'm chubby for a fair comparison.
(I know of the suckless community and of st in particular (I've never tried it)).
"It is 250MB" alone isn't.
This slowness costs users so many hairs pulled out. Programmers who think that "this is acceptable" lack the awareness that they haven't even tested the software under only slightly unusual conditions which is when everything is already crawling to a halt.
When that "bundle" is 1000MB while technically there is no reason it should be more than ~1MB, many operations that you might want to do as a developer / trying-outer of the bundle take 1000x longer (no shit). Not unlikely, in some cases that even applies to runtime performance.
Why in the world would you accept that when it takes only a little discipline to get it down to a "reasonable" overhead of say, 10x???
Not all software is getting slower faster than hardware is getting faster.
It has always been possible to write slow software.
But to your actual point, of course you can write software that runs not slower, or even runs much faster, than the software of 30 years ago that ran on machines of the time. The exception proves the rule (while I feel it's always been so obvious that there was never a proof needed).
And the important point is: it _is_ annoying, an actual bootup in 5 seconds is easily possible from a technical perspective, and would much improve the user experience.
Take systemd, I remember it brought a lot of startup time improvements for a while, or at least promised them. I don't follow Linux very much these days, but when I do a standard installation of a popular distro - sloooow startup. Last I looked I had an issue with tons of virtual serial devices created serially, took probably 10 seconds alone.
Parkinson's law at work.
And no one listened, so now -- despite our computers being thousands of times faster -- basic applications are hundreds of times slower to open. And we're junking a bunch of "old" machines that are considered too slow even though they're technically capable of performing rapid operations at levels our brains can barely comprehend.
They still do, thank you very much.
Our children will still complain about a 10MB application, if it does something that could be done by a 500KB solution.
>Comparing a complete bundle for an advanced graphical application framework with a TUI application is apples to oranges,
And what do I need a "advanced graphical application framework" for if the intended use case is displaying text in a grid?
Good for you, I guess. I, myself, have 120GB.