Discussion on: What's wrong with code in 2022? 🤷🏻‍♀️

View post

I don't know what it's like now, but when I ran "hello world" in React a couple of years ago it extracted a quarter of a gigabyte of files.

I mostly agree with you (and as I'm in your father's age range that might not be surprising) but I do recognise that everything we do is standing on the shoulders of those who came before. We have things like Electron to genericise making applications and while everyone knows it's bloated, it works, and it works for almost everyone because it does everything you don't need in case someone else does.

I find the weird background tasks applications use upsetting as well. I have no idea why every proprietary application needs to run at startup and have "update" and "maintenance" processes running when I'm not trying to use it. It's another reason to steer clear of proprietary software wherever possible; free software almost never does this, or if it does it asks you first.

Peter Vivo • Dec 27 '22 • Edited

I was checked my "~~hello world~~" "mmorpg poc" application written in NextJS ( react + BE ) memory footprint was 2.5Mb. That is still count as huge. But I think that is quite fine in our memory gobbler times.

===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 CSS                     1            7            6            0            1
 JavaScript             18          517          456            3           58
 JSON                    6        22672        22672            0            0
 Sass                    6         1032          865           31          136
 SVG                     1            1            1            0            0
 TSX                    10          523          444            1           78
 TypeScript             18         1284         1106           13          165
-------------------------------------------------------------------------------
 Markdown                5          440            0          321          119
 |- BASH                 1           31           24            1            6
 |- JavaScript           1            3            1            1            1
 |- JSX                  1           11            9            0            2
 |- TSX                  3           53           42            2            9
 (Total)                            538           76          325          137
===============================================================================
 Total                  65        26476        25550          369          557
===============================================================================

./server size is: 256kb.
./static (graphic files - maybe few unwanted still left): 1.3Mb

Worst part the node_modules lib: 350 MB.

This way of programming fare more distand from my Z80 assembly game code writtend around 1987 on Videoton TV Computer.

Wade Zimmerman • Dec 29 '22

We could use far less code if browsers supported other languages besides JavaScript

Peter Vivo • Dec 30 '22

Actually you can write any languages to browser compiled to WASM/JS/HTML. By the way if you create any JS/HTML application that is also need for compile to proper JS target, mainly ES5 for compatibility reason.

I think actual browsers is so complex application - with tons of unused API ( surprise ! ), any extra languages will be raise these complexity unnececcary.

const speak = sentence => speechSynthesis.speak(new SpeechSynthesisUtterance(sentence));
speak('What did you think about browser complexity?');

The good question is:
Why don't able WASM reach these API endpoint and HTML page without any JS code?

Maria 🍦 Marshmallow • Dec 27 '22

Thanks for sharing 🌈

Bangy Slower • Dec 24 '22

Just look at the calculator, which used to require less than a megabyte, but now it eats up more than 150 MB of RAM at a time with the same functionality.
I don’t know, maybe in Photoshop this is justified: there is a new useful and diverse functionality, albeit bloated code for its implementation. But in the case of a calculator, this is really just indecent.

Conor Gibson • Dec 27 '22

I have a better example. To turn off the RGB lighting of the Aorus graphic card (Gigabyte vendor), I need to install 0.5GB of software. It's that shitty soft... 400 megabytes to turn off the RGB.

Bangy Slower • Dec 27 '22

It's funny. How much does the installer weigh? And how much space does the installed utility take up?

Conor Gibson • Dec 27 '22

RGBFusion2.0 installer 253 MB.
When installing and uninstalling the program, it says that it takes 170MB.
In fact, 2 utilities are needed there, and as I understand it, the 2nd one used to be separate, and then became a plugin for the first one. 0.5GB is the total weight of the installers.

Conor Gibson • Dec 27 '22

That is, you must first install the aorus engine so that it installs RGB fusion. If you install RGB Fusion separately, it doesn't work for some reason. Moreover, with this utility installed separately, aorus engine will not install it. Such crap...

Bangy Slower • Dec 27 '22

500 MB is about the weight of Windows 2000 installation files, in which there is "a little" more functionality 🙃

Maria 🍦 Marshmallow • Dec 27 '22

Can't you physically disconnect the RGB cable?

Conor Gibson • Dec 28 '22

In my case, the card must be disassembled for this.
It would suck to lose the warranty.

Maria 🍦 Marshmallow • Dec 28 '22

It's a pity... on some of them, the wire can be traced and unhooked without unscrewing a single screw.

Ben Sinclair • Dec 28 '22

I have a Gigabyte card like this too. I'm pretty sure you can install the software, use it, then uninstall it and the light settings will remain (not really the content of this thread, I know).

When I mentioned .25GB for React, I was mostly talking about the total size of files it added to my node_modules directory. The "installer" was technically only a few MB, the compressed files it downloaded might have been (guessing) 50MB, but after unpacking all of them to text files, and using up a zillion inodes, and creating directory structures you need a rope and a torch to explore, the end effect is a lot more than the initiator.

I think it'd be benefitial to talk about all these things separately (size of download, size of installation, amout of resources uses when running) because if the installation process only downloaded the files it needed, and everything else was run with libraries existing on the system, then that would be... great? Right? But you can have an application which behaves that way during installation and turns out to chew its way through all your available RAM when running, for example. And these things are different, and if they were the responsibility of different actors, they might be better optimised?

Maria 🍦 Marshmallow • Dec 28 '22

This is a similar topic, but I think that you are right and it is better to consider it separately, since my page will not withstand as many comments of such a discussion 😁

cubiclesocial • Dec 30 '22

There's no need to install a 500MB application to turn off RGB lighting. A piece of electrical tape works wonders. It's non-conductive and comes in a variety of colors with black being the most popular.

I use painters tape, electrical tape, and even the sticky part of sticky notes to cover up the blindingly-bright LEDs that all modern technology gadgets seem to come with. Depends on how much light I want to let through that decides which route I go with to cover up the LEDs. When I want nothing showing, electrical tape gets used to great effect.

Conor Gibson • Dec 30 '22

Using electrical tape for such purposes is an incredible bullshit, I'd rather install 0.5 GB of software. My video card is not 4090, of course, but that's how much you have to disrespect your hardware to do such things with it.

Maria 🍦 Marshmallow • Dec 30 '22

Here I can support you, I would not do such "modifications" with my hardware, in my opinion it is "village custom". But for someone a PC is just a working machine, then this is quite an effective option.

cubiclesocial • Dec 30 '22 • Edited

SpeedCrunch: 4MB RAM. Has a portable version in the Portable Apps platform.

It does way more than Windows Calculator. The only thing it doesn't do is graph equations. For graphing, I will occasionally fire up:

desmos.com/calculator

I still run Calculator though when I need "as soon as I type it in" conversions between bases (binary, decimal, octal, and hex). That's something SpeedCrunch doesn't do very well.

Maria 🍦 Marshmallow • Dec 30 '22

They look like really useful tools, thanks for the recommendation 🤗
4MB are much better than 150

Amanda Swensen • Dec 24 '22

A 20-year-old calculator did not have to think about hidpi, 4k, multi-monitor configurations, touch control, support for a dozen interface themes, synchronization to the cloud, loading exchange rates from the Internet and a whole lot of functionality that an individual user may not need, but others users do, and writing millions of versions for each is unprofitable.

Bangy Slower • Dec 24 '22

The fact is that a modern calculator does not have to think about it either. All these themes/touchs/hidpi and others like them — all this is resolved by the libraries of the operating system. And in terms of functionality, it has not gone too far from a 20-year-old calculator, but it eats resources like AutoCAD or MathLab 20 years ago.

Amanda Swensen • Dec 24 '22

It is precisely the libraries that are part of the calculator that occupy those megabytes

Bangy Slower • Dec 24 '22

They are part of the OS, why separate them? And it is highly doubtful that touch control support will increase the code by 40-50 MB.
This is the characteristic mindset of some modern programmers, justifying bloat with incredible complexity: all those "touchs/hidpi/unicode" is just a mantra to stop thinking. "What are you doing? Don't go there! It’s difficult, there are touch, hidpi, currency conversion and some other important things!”

Paweł Świątkowski • Dec 25 '22

I have no idea why every proprietary application needs to run at startup and have "update" and "maintenance" processes running when I'm not trying to use it.

The answer to this is simple, whether you like it or not - it's the users. They expect the software to be updated automatically. They never do it manually, but they are first to complain that something is not working on their not-updated-for-two-years version.

Ben Sinclair • Dec 26 '22

Isn't that what package management is for, though? It's not the job of an application to handle things like window decorations or storage quotas... or updates.

Paweł Świątkowski • Dec 26 '22

It is. Does Windows have package manager that is popular among its users? Isn't the most popular way to install things on MacOS to just download a dmg from a website?

Ben Sinclair • Dec 27 '22

On Mac, it's the App store or homebrew (third party) (or Ports, if that's still maintained). On Windows, it's the MS Store or chocolatey (third party) (I think?)

I don't think many people download .exe or .dmg files any more.

Paweł Świątkowski • Dec 27 '22

Literally nobody is using Chocolatey or MS Store. Some people use Mac App Store, but most application aren't there. Only developers use Homebrew or MacPorts. Most people download from websites.

Maria 🍦 Marshmallow • Dec 27 '22

@moopet When there are tens of thousands of software packages in a distribution, updating a program with hundreds of dependencies becomes quite difficult, especially for non-free software. Yes, all sorts of snap and flatpak are used to solve this problem, but they completely eliminates the advantages of shared libraries, which are designed to avoid code duplication.

Ben Sinclair • Dec 28 '22

@katafrakt it doesn't matter for the purposes of this whether many people use it or not, it's the only practical way for applications to behave unless (as @mariamarsh notes) we all move to statically-linked behemoths.

Paweł Świątkowski • Dec 28 '22

Oh yeah, of course, if the reality does not matter, keep wondering why every application has this kind of background process.

Ben Sinclair • Dec 28 '22

The question is, "what's wrong with code in 2022" and the culture of downloading separate things for everything is part of that.

Maria 🍦 Marshmallow • Dec 24 '22

It works, but most of the time it sucks. And lately, the user does not care what the software is written on, as long as it works. For users, the quality bar has already gone underground, so when they find something that works quickly even on old hardware and does not take up a hundred megabytes, they are really surprised.

Imagine if almost all popular instant messaging clients were written in Word macros and shipped with a Word copy. In my opinion, Electron is just as ridiculous.

But despite the general disappointment that there is a lot of software on the electron, it is still really the leader in cross-platform desktops... And there are certain reasons for that which can't be solved by other frameworks.

cubiclesocial • Dec 30 '22

Reasonable alternative to Electron:

github.com/cubiclesoft/php-app-server

Produces similar results at a fraction of the size (e.g. 85KB app size for Linux). And PHP is available to write code for the server side of the app.

Maria 🍦 Marshmallow • Dec 30 '22 • Edited

How popular is this product? I haven't heard of it before, but it looks interesting. Are there any examples of software on it? What features did you personally use working with it?

P.S. Sorry, I did not notice that you are a representative of this software.

cubiclesocial • Jan 6

That's okay. It's obviously not as popular as Electron but a number of people have clicked star/fork, so it's slowly gaining traction. I don't advertise my software very often and just expect people to run into my stuff. As to software that uses PHP App Server, there's this:

file-tracker.cubiclesoft.com/

A commercial project I wrote and actively use/maintain.

Maria 🍦 Marshmallow • Jan 6

Thanks for sharing 😊
I'll be sure to explore your products, and hope you'll find your audience 😌

Diamond • Dec 28 '22

Electron got so popular because it meant you could write an application once for the web and then never have to care about cross-platform compatibility because that stuff is all taken care of for you. It had a great developer experience and a good-enough user experience.

I personally regret the rise of Electron because it's lead to slow, bloated applications that take half a gigabyte of memory instead of a few megabytes, but at the same time I understand why it's gotten so popular.

It's kind of like money -- the less you have, the more conservative you are with it. The more you have, the more you get conditioned to irresponsibly spend it and you start to care less about how much you are spending. It's not responsible, necessarily, but you've got enough to the point where you don't really care that you could be spending less; and I think that's kind of what's happened with the current problem of software bloat.

Maria 🍦 Marshmallow • Dec 29 '22

Yes, exactly as you say