Even well-written Web applications tend to use more system resources than their well-written desktop counterparts. A few days ago, I was surprised to find that Chromium was using 6 GB of RAM, while all other processes combined (including three Emacs instances, running fancy modes) were using just 1GB. And, no, I wasn't playing browser games or doing anything fancy in Chromium: just viewing text and images.
> And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
It would be much better to use programs that don't need to run in a sandbox in the first place. (To be fair, OS-enforced memory protection can be considered a kind of sandboxing too.)
The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.
Yes, they do, via Web Workers. They just don't support multithreading at the level of concurrent access to the DOM, and they don't support shared memory. Very few native libraries support concurrent access to UI widgets, and not many native applications make heavy use of shared memory for compute either. (Most native applications don't have heavy compute needs in the first place…)
> Give me an array of 10 elements
new Array(10)?
> give me a integer of that length
Uint8Array, Uint16Array, Uint32Array?
> Yes, they do, via Web Workers.
Which are not part of the javascript spec, it is DOM related. And web workers were never meant to increase performance. In fact in practice they don't, they often make code slower. They just guarantee that the UI thread will not block.
> new Array(10)?
Which doesn't allow any specific runtime optimization as the array can be resized at anytime
> Uint8Array, Uint16Array, Uint32Array?
Which doesn't give me an integer of a specific size BUT any array of integer.
Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.
Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.
That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.
Excel is a great example of that, but it's done with programming languages as well.