Meanwhile 16GB of memory is becoming common and 1TB SSDs cost less than $100. So taking up a little bit more space saves me time and money and reduces the cost to ship to my customers. Oh well.
Meanwhile 16GB of memory is becoming common and 1TB SSDs cost less than $100. So taking up a little bit more space saves me time and money and reduces the cost to ship to my customers. Oh well.
- First of all the amount of RAM consumed actually depends on how much free RAM you have, Electron thinking it's a browser boggles up some extra RAM "just in case", which is a tread-off that probably works better for actual browsers than the average Electron app.
- Secondly while displaying "hello world" costs you ~100MB of RAM the RAM required as the app scales in complexity doesn't scale quite that fast, you may very well work on your app for a year and still need about ~100MB or RAM for it, you'll have to write very inefficient code (or keep a lot of data in memory) for it to require 1GB for JS' heap or something crazy like that.
Still ~100MB is a lot for sure, I think a lot of it could be trimmed away if the developers really tried to lower memory usage significantly, like maybe a much more efficient "Electron Mini" could be made with some effort.
Right now I'm running VS Code and PyCharm, each with an one open project and one open editor. PyCharm is eating 1.8 GB while VS Code is only eating 130 MB. Funny enough, I see people complain about VS Code being a resource-hungry Electron app all the time but I've never seen anyone gripe about the resource usage of JetBrainz IDEs.
This isn't an excuse to Electron all the things, but browser-based GUIs do have their place.
People have unrealistic expectations on this.
That's a problem that didn't have with GTK app running on a computer with one order of magnitude less computing power and RAM two decades ago. VS code on the first computer I used to program would probably be unusable (if it even launched), yet we had full fledged IDEs back then. I'm not talking about advanced language server plugins here, just basic usage.
The great side effect of this is that if you avoid all this wasteful crap and keep using old school technology, computers are snappier than ever. My terminal always pops up instantly, nvim fires up faster than I can press return, rg lets me search a huge codebase with barely noticeable latency. My IMAP mail client is faster, more configurable and more ergonomic than any webmail I've seen.
Life is good when you avoid the www.
For example, on my computer right now I have 55 applications that depend directly on qt5-base, not including libraries and parts of QT. This is also not including a ton of applications that depend indirectly on QT, including most every KDE desktop application, which depends through KDE's frameworks.
So while QT may not have caught on in commercial software development, I'd say calling it a failure depends very much on what software ecosystem you're in. You might argue that HTML has achieved "universal usage" for desktop apps in a way that QT has not, but I would have to disagree. I don't have a single HTML UI or Electron app on my computer, and I don't feel as though I've given anything up. In fact I simply haven't come across any of these apps that I felt like I needed.
So I might say that HTML has failed to gain mass usage on the platforms that matter to me. :-)
At the very least a proper gui library could precompile all of that stuff so you aren't literally parsing HTML and CSS to render things, and HTML And CSS parsers don't need to be part of your running code. Nor a Javascript JIT, and runtime, etc.
Don't forget browsers are pretty spectacular runtimes. V8 and its JIT compiler is arguably one of the best runtimes of any language in the world. Sure the very first view of a page is going to do some parsing, etc. but as it runs it gets faster and faster with core functions and components compiled on the fly into platform machine code. The sandbox and security and encryption support in browsers is top notch and supremely battle-tested and hardened. With WASM now pretty mainstream we're starting to see entirely new frontend UIs coded in languages like C++, Go, Rust, etc. that are incredibly fast too. If you squint hard enough the browser is really no different than the JVM or .NET CLR these days--it just has 20 more years or so and an order of magnitude more developers working on improving it.
As somebody who only started developing for the web a few years ago after a long time working with Qt, winforms, GTK and other "old school" native toolkits, I really don't find the web superior in terms of simplicity outside maybe of a few niches. You end up having to resort to dozens of external libraries to emulate the base functionality of something like Qt. And unless you want to go the transpiler way (which, admittedly, is incredibly common these days) you have to do it all is Javascript which is easy to pick up but a pretty huge liability in the long run IMO. It's just not a very good language, even if you stick to "the good parts".
Depends where you look. Plenty of hardware devices use Qt as their UI. Modern Mercedes-Benz and Ford cars, LG TVs UI, stuff like the Remarkable tablet or th Telegram chat app... The nice thing being that you can test the UI on whatever OS you're running. Also, i18n on the web ? Come on. It's terrible when compared to Qt tooling
In my experience, this is more about resources and economics ("reuse existing code" vs. having to learn something new).
Oh if only that was enough. My Safari is currently using 25.33GB¹ and and it regularly goes over 30.
> 1TB SSDs cost less than $100
Ah, if only it was that easy.
¹ (According to iStat Menus; it's harder to see in Activity Monitor due to the separate processes.)
My solution is to restart Safari when it gets too bad, as it's obviously leaky.
For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was overloading the poor machine. One day I saw the stats and realised what was happening. Now I open only one browser at a time, and everything is much nicer.
If I decide to get another Mac (undecided), I'm holding out for an M1X or whatever with more RAM. 16GB isn't comfortable for my work any more. I'm not the kind of person who casually buys new expensive machines, so won't be getting the x86 32GB as an intermediate knowing I don't really need it, as I think it would be better to end up with both an x86 (which I already have) and an ARM going forward. I'm into code generation and portability, so that's better for me. And I like the idea of less fan noise!
As an example, the new MacBooks are not very competitive (for performance) with the latest XPS series from Dell.
Like almost everyone, I'm financially constrained as well as space constrained. so buying multiple expensive machines, or a high end Mac Pro or something is not on the table as an option.
So it's a compromise.
My compromise at the moment is to use a MBP for Apple things, do smaller Linux and Windows things in a VM on it, and do big Linux and Windows things on cost-optimised rented servers much more powerful than the XPS from Dell. That seems to be a better use of the resources I have for the workstation class problems I'm choosing to solve.
An additional target of my interests is the M1-class processor with it's ARM plus extensions architecture.
So I will wait and see what the next high end, ARM-based MBP from Apple is like. By all accounts the M1 is an excellent and powerful processor, competitive with other Intel-based laptops, so its successor may be a good match for my needs. It might not be, in which case I will need to revisit my strategy, but until it's announced we don't know, and it doesn't make sense to buy an XPS at the moment for what might be just a few months of only marginal discomfort. I have my servers after all.