Electron: Build cross platform desktop apps with JavaScript, HTML, and CSS

I can't believe people actually use this shit.
The amount of RAM it uses is seriously insane.

Free ram = wasted ram
Most people have 32+ GB, so this doesn't matter much

>>2
Bullshit.

>>3
No, really. it is
Even operating systems agree with this claim by giving applications more ram than needed and leaving the actual free ram amount in the low 10s.

>>4
That's not the part that's bullshit.

>>5
You're right. 16GB is more likely

>>2

Most people have 32+ GB

Not even for gaymers is this statement true.

>>2
Your garbage isn't the only program on the machine.

Most universities don't teach anything students really understand anymore. Teaching JavaScript will only make this worse.

Some people like to blame the problems with C on imperative programming, manual memory management, pointers, etc. The problem with C-based languages is bad syntax and semantics, not the features and purpose of the languages. Look at switch, for, arrays, pointers. They do not behave like the normal CS concepts. Nothing makes sense in these C-based languages, not even numbers. 0123 is actually 83.

They tried to solve these problems by switching to Java, but that didn't help. It just made more concepts ``advanced''. They said that garbage collection will fix everything and pointers are an advanced concept. Now they're blaming OOP, garbage collection, object references, static typing, etc.

Now Java is too hard and they are replacing it with JavaScript. Students think ``hard to learn'' means it's advanced concepts, but it could also mean that the concepts are ruined by a bad language.

>>9

not even numbers. 0123 is actually 83.

Of course it is. 0123 is octal.

>>9

0123 is actually 83.

Now this is what I call autism.
Please try to nitpick about an actual issue.

I think electron is a step into the right direction.

Let's assume for a moment there weren't the problem with JavaScript performance (because, for example, web assembly can replace it).

Then electron is the platform everyone can build his applications on. And once that happens, we can rip out the cruft from the operating systems.

This is just one possibility, and I am not saying it's going to happen or that it is even a good idea. But if you have to write cross platform apps it seems to have its advantages.

>>12
Electron makes web browsers that are used as desktop applications.
Your argument is invalid.

>>11

autism

Are dozens and dozens of Stack Overflow questions ``autism'' or is C badly designed? Take your pick. 0123 should mean 123 like everyone expects a positional numeral system to mean, and it does in all programming languages that are not based on B and C.

Please try to nitpick about an actual issue.

There are thousands of issues about C, which would be at least as long as the C standard. It comes after a lot of things on the list, but it's still a C problem. It still causes numbers to be interpreted incorrectly.

https://stackoverflow.com/questions/1661369/how-does-c-handle-integer-literals-with-leading-zeros-and-what-about-atoi

The only thing worse than C's unfortunate use of leading zeros to make a number octal is Javascript's handling of leading zeros to sometimes make a number octal (the number is octal if the rest of the digits are OK - less than 8 - decimal otherwise). In Javascript, (017 == 15) but (018 == 18).

https://stackoverflow.com/questions/7027025/overloading-inserters-and-strange-outputfor-20-and-020
https://stackoverflow.com/questions/6365565/what-does-it-mean-when-a-numeric-constant-in-c-c-is-prefixed-with-a-0
https://stackoverflow.com/questions/20177853/why-are-integers-converted-to-octal-numbers-here

>>14

Are dozens and dozens of Stack Overflow questions ``autism''

Didn't read. Nice shitpost.

>>15
You read it, but have no response because I'm right. C octal is a huge mistake.

>>14

In Javascript, (017 == 15) but (018 == 18).

I don't understand the issue if you enter invalid numbers on purpose.

And what you said isn't even true.

018 == 18

SyntaxError: 08 is not a legal ECMA-262 octal constant.

>>14
The word "gift" also means something very different in German and English.

German is not English, and neither is C.

>>18
There can also be a language where you write the numbers backwards if the first or last digit is 0, but that would be stupid. It sounds like INTERCAL and Malbolge are more your style.

>>19
Seems like autism. Just don't prefix your numbers with 0.

>>19
You have obviously never experienced the productivity of a proficient APL programmer.

https://github.com/arcfide/Co-dfns

https://www.youtube.com/watch?v=a9xAKttWgP4

>>21
Who cares. APL is a deprecated language.
It's not the 70s anymore, where there are people who care about code column width

>>22
Still impressive

What programming language is this?

>>24
looks like javascript

>>21
What does that have to do with anything?
Does the productivity of an assembly programmer justify a different language's shortcomings?

>>2
malloc(999999999999L)
There, giving some productive use to your 32GB of RAM.

>>27
Nothing wrong with that, if you need it. Overcommitment will ensure it only uses it when needed.

>>2
>>4
>>28
You really don't have the slightest clue about the 'keep the RAM filled' paradigm at all, don't you? Protip: not only L1/L2/L3 caches can have misses, RAM can have them, too. And those RAM misses aren't measured in us or ns or something. Those misses are measured in seconds and minutes.

>>29
Yes it is slow, but certainly not "minutes". I don't know where you got these estimates from.

>>29
Optimize your quotes,「何卒」.

>>28
Overcommitment is a bad idea only a C hacker could come up with.

>>30
Consider these scenarios:
4GB RAM
no SSD, or slow Flash or similar

1. Your RAM is almost full (<100MB free) and you start a large program that isn't cached in RAM. You just closed your 48 hours browser session and RAM is still filled with stuff you don't need anymore -> Load time of the new program will multiply by a few factors.

2. You play a video game and are on a mid-session load-screen, like a map-change and the next map is not cached, and the RAM is almost full, and the game engine maybe also has to do some garbage collection -> Load time can increase from maybe 30 seconds (with correct data cached) to multiple minutes (with incorrect data cached and RAM full).

Of course, the good timings come from good RAM caching.
But for the bad scenarios, bad RAM caching and software bloat have worsened the situation drastically.
In the end, it's not about having the RAM filled at all times. It's about having it filled with stuff you actually need and not bloated JS shit (the same thing goes of course for L1/L2/L3, where performance people optimize madly for size). And it's probably safe to assume that by writing software efficiently, memory footprints of individual programs could be at least halved (some people would maybe claim a lot more, like 1/100, but even only halving would already be a serious win).

>>33

some people would maybe claim a lot more, like 1/100, but even only halving would already be a serious win

Hackers and appers don't care about the users. If they cared, they would already be doing the Right Thing.

>>32
No. It's a good idea.

>>33

Load time of the new program will multiply by a few factors.

Multiply, yes. But not in minutes.

2. You play a video game and are on a mid-session load-screen, like a map-change and the next map is not cached, and the RAM is almost full, and the game engine maybe also has to do some garbage collection -> Load time can increase from maybe 30 seconds (with correct data cached) to multiple minutes (with incorrect data cached and RAM full).

Video games load a lot of stuff into RAM, so I guess that makes sense.

>>35

An aircraft company discovered that it was cheaper to fly its planes
with less fuel on board. The planes would be lighter and use less fuel
and money was saved. On rare occasions however the amount of fuel was
insufficient, and the plane would crash. This problem was solved by
the engineers of the company by the development of a special OOF
(out-of-fuel) mechanism. In emergency cases a passenger was selected
and thrown out of the plane. (When necessary, the procedure was
repeated.) A large body of theory was developed and many publications
were devoted to the problem of properly selecting the victim to be
ejected. Should the victim be chosen at random? Or should one choose
the heaviest person? Or the oldest? Should passengers pay in order not
to be ejected, so that the victim would be the poorest on board? And
if for example the heaviest person was chosen, should there be a
special exception in case that was the pilot? Should first class
passengers be exempted? Now that the OOF mechanism existed, it would
be activated every now and then, and eject passengers even when there
was no fuel shortage. The engineers are still studying precisely how
this malfunction is caused.

https://lwn.net/Articles/104185/

>>37
False equivalence.

>>37
they won't be thrown out of the airplane if you had swap lol

>>33
does a 5,000 tab browser process consist as "stuff you actually need"?