...and remember that Quake 3 required 64 MB to run, while Half Life managed to run on 96 MB of ram.

I'm pretty sure Half-Life required a lot less than that. The first PC I played it on only had 16 or 32MB of RAM.

Those games were all written to "bare metal", talking to Win32, DirectX, etc. Most modern apps like Slack use a pile of giant frameworks which handle most cross-platform portability, at the cost of massive explosions of resource usage. It's a lot more work to write platform-specific code without those frameworks. I don't defend their choices, they're big enough to pay that cost, just explaining where this comes from.

> It's a lot more work to write platform-specific code without those frameworks

Qt/QML abstracts over a ton of platforms, lets you write UI code in JavaScript, is extremely easy to pick up, has a WYSIWYG drag-n-drop editor and consumes a small fraction of the resources Electron does.

The overuse of Electron is not because everything else is impossibly hard; it's just old-school fashion-driven development.

I've got a lot of experience with Qt, since I ported Google Earth from Windows to mac and linux, and it was Qt based back then. You have the problem of having slightly non-native feel because Qt has to code around platform differences to present a unified API. When we first released the app, we took a lot of criticism because of its non-native feel on all platforms (except for Linux, which doesn't have a native feel). So, if you want a top-quality app, you're probably breaking it apart into a platform independent core and then writing your interface separately on each platform using native API's. I wish that the cross-platform abstractions worked well enough to be indistinguishable from a native well-coded app, but we're not there yet.

I didn't suggest Qt as an alternative for native toolkits to achieve a native look and feel; while it can be done it's a lot of work. I suggested Qt (specifically, QML) as an alternative to Electron, which doesn't care about native look and feel.

Bloat is making me so angry that I'd take an as400 textual interface as native feel any day. The web era is one step too much in the wrong direction to me. I enjoyed the hyper genericity of the web, but I'm tempted to say we need a little bit more of the flat and trickful things of the past.

You guys should remember that a lot of crap we write nowadays is a consequence of bloated languages and "move fast break things" attitude.

Doom and Half life were at their core exceptionally optimized C.

Behind the trees you don't see a forest: Half-Life used 32MB of memory on 1024x768 display. By 4 or even 2 byte color it is 2MB just to store picture output. Modern apps work with 4k2k*4byte color, which on itself is 8 times more memory.

I think I understand the point you're trying to make (modern apps draw to larger screens, and therefore must use more memory) but this is a poor comparison for a number of reasons. The most obvious of these reasons is that graphics cards are leagues ahead of where they were back in the days of Half Life. Sure the framebuffer takes a bit more memory, but a 4k frame is only about 32MB of memory at 32bits per pixel.

Anyway, you're root argument is still somewhat valid: Half Life was working with some really tiny constraints compared to modern machines, and did amazing things within those limits. Modern apps, were they coded to the same level of optimization as Half Life, should be much, much smaller and more efficient than they are. But as it turns out, the human cost of developing video game software is high, and the one area where Electron truly succeeds is in its ease of use. By driving development costs down for non-game apps, it balances out its high resource usage, and to a company producing software, that's enticing. I think that's awful (and would prefer to run optimized software personally) but the industry seems to disagree with me.

So, 2 MB for the display. And then there are the textures for the walls, plants, people, monsters, etc. And the vertex data for each of the models on the level. And the level itself. And then there are the light maps for static lighting. That's at a minimum. After that there is the memory required for the AI. Much of the models and textures won't be used in any given scene, but might get used in the next frame, or the next half second, and to avoid long pauses when a new model is loaded they all have to be in memory. If Half Life could have been done in less memory, I'm pretty sure they would have done it. It probably started off using a lot more memory and they probably spent a lot of time getting the memory down so that your mid-class machine could play it.

So that accounts for 16MB of the 1500 used, where is the other 1484 going?

Half Life 1 run on 32MB ram.

> Your users don't care how easy it is to find js devs.

Their user do absolutely care about UI/UX. If you're going to implement it native without all the "free" things you get from the web stack, and its popularity, the UI is most likely going to suffer.

I don't know about other platforms but on MacOS native apps are way better designed (looks and usability) than the electron crap that is available. So I'm curious, what makes you say JS devs are better at designing apps than native devs who know how native apps work?

They also care about battery life and system performance, they just don't know to blame Electron for any problems they have with those things.

What evidence do you have that js devs are any better at ui than native devs?

Most of the web is a usability nightmare.

On Windows we have WPF.

Compared to the web stack, it packs much more free things relevant to desktop development. The examples of such things are animations, composition, data binding, pixel shader effects, and vector graphics.

Also WPF renderer is based on Direct3D, I would expect better performance.

Telegram for macOS is fine except it could look and feel more native imho

The solution to all of this is to use React Native, or a technology that is based on its principles to the desktop.