My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.
Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption.
And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.
And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.
Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.
The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.
And don't forget accessibility. That's the part that makes me want to scream whenever I see a new lightweight UI toolkit on HN.
Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, and you want this rather complicated functionality to perform at a reasonable level, you're looking at browser levels of resource consumption no matter what you do.
I mean, if you start working the math on what it looks like to have a bitmap of the screen in memory (which you may not literally have as a single flat plane, but we've got character caches, images, and all sorts of other things that add up to that pretty quickly, if not surpass it entirely very quickly), on a high-resolution display, a bit of extra memory left over from packing those resources, the dynamic scripting language space, the other support modules, various other bits of uncompressed media even if it's just windowed... you've gotten into the hundreds of megabytes pretty easily there. Maybe you could keep this below 100MB with a lot of work, but in a world where a single uncompressed 4K full-color image/framebuffer is running you at least 24 MB (for RGB, 32MB for RGBA), 10-50MB just isn't going to be an option.
I've got an emacs here with a couple dozen source code buffers loaded and it's running at about 60MB resident. That's a mere 1/5th of the Slack usage that everyone is incensed about, and while emacs can do a lot of things, it's still taking a pretty substantial capabilities hit vs. Electron to get that small.
Yes, I know emacs can have a web browser in it and such. And if I use eww to load news.ycombinator.com, emacs resident usage just jumped 15MB for what is, frankly, a terrible rendering. It isn't even rendering my jerf.org terribly well, which in modern terms is basically built by rubbing two sticks together and sending the resulting sparks down the wire. That's what 15MB on top of the already-loaded emacs bought me.