This article seems to be underestimating how much RAM a weather app should take. A well thought-out, native Weather app wouldn't take more than 100 mb of RAM.
...you know, I keep reading all this stuff about memory prices, and it does suck, but memory is still much cheaper per gigabyte than it was ~15 years ago.
Which matters because the things most consumers are doing on their computers haven't changed in the past 15 years. We browse the web, edit photos, message friends, and so on. AI generally runs on remote servers anyway.
For years, everyone kept saying it was fine that Electron used gigabytes of memory, because on modern PCs memory was plentiful anyway. Well, it's not plentiful anymore! Maybe it's time software developers actually used resources efficiently?
I don't really understand the "its cheaper now than xyz years ago"
Sure, but we're being screwed regardless. You should be disappointed that almost 2 decades on, pricing hasn't improved. You should be disappointed the reason memory costs so much is because of AI contracts that you cannot compete with.
>Maybe it's time software developers actually used resources efficiently?
At least anecdotally, I'm seeing more and more native apps being written. Sure most aren't first party products, sure some are AI generated but its better than having 11 electron apps on my computer running at the same time.
I want to upgrade to AM5 (thus DDR5). I currently have 64GB of RAM and most of the time in games (even "less demanding" games like CS2), I find my system using over 32GB of RAM. This is a Fedora system!
I think I could get away with 48GB, but 64GB is too far out of my price range.
PC games were the last reason why I still used windows. Now that Proton works wonders in Linux, I hope I don’t need to ever come back again. Great times with 98, xp and win7 that were snappy, easy to install and with no slop
This took me down a rabbit whole. Why can a simple single purpose app not be just a couple megabytes if not less? The popular options are electron 100MB+, or embedding python3 in your executable which is at least 40MB.
But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.
My gaming PC that I built in January 2006 that IIRC I used to simultaneously run Battlefield 2, Trillian, Xfire, Thunderbird, and Winamp with a 1680x1050 monitor had 1 GB of total system RAM.
That's because programmers in 2006 didn't understand programming. They didn't understand how to make their software better.
Real programming means writing your own javascript glue, pulling in hundreds of supply-chain-compromised js libraries that you never inspect or profile, and running the whole thing in a browser engine, while making sure to store all state in the cloud.
The modern breed of programmers who don't understand programming have switched from C and C++ to Rust and Go, so they're on the right track of using more resources to improve the developer and user experience, but they haven't gone nearly far enough. They still do dumb things like write efficient code, and profile and put effort into reducing binary and resident size. They should trust in javascript and the browser and the internet, like all good programmers do.
Zig programmers have completely lost the plot. They're of the type that tries to write "hello, world" manually rather than pulling in a third party library so they can efficiently call helloWorld(). Writing single-binary apps that fit on a floppy? Who even cares? What even is a floppy? How do they call themselves programmers without css and advertising telemetry?
Back then we had constraints. That made us better programmers. We had to think about every database call and network call. No one cares about that now until it compounds to broken software - like Windows.
Yesterday I was running :
NixOS, mango window manager, 5 instances of ghostty, 2 of those running fresh terminal editor, firefox with 5 tabs and I was at 2.37gb of RAM.
All the comments excusing the RAM usage "because high-resolution screens require pixels" are missing the fact that there's this thing called GPU memory. Which is where pixels data should be. There's no way you need to store fullscreen 4K images for a weather app on anything else than the GPU: use scalable icons, render them on the GPU. No need to use actual RAM: the GPUs have had their own RAM since times immemorial and GPU rendering is a thing too.
Lots of iGPUs just end up being backed by system memory. But even then, this is a ridiculous hand wavy excuse. A 4000x2000 RGBA buffer is 32MB. That only explains 2.7% of the weather app's devastating memory footprint.
They don't want you to remember that Windows XP's minimum system requirements specified 64MB of RAM. This weather app uses 20 times more memory than an entire operating system from 25 years ago.
I wonder if this is a fair calculation including the fact that multiple WebView apps should be sharing the same libraries in memory.
If you pay 0.5-1GB to load the edge/chromium libraries but that memory is amortized over N different apps the user is likely to run, then the ”1GB for the weather app” is an unlikely worst case.
As time goes on, I become more and more convinced that OSes need some sort of OS level GC pool which all GCed languages play in rather than having the language runtime provide the GC.
A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.
This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.
These RAM prices weren't anticipated so there's been little time for software to adapt. Better monitoring could be a solution but this kind of thing wants to stay hidden.
Running the GC more often wouldn't save much. Dynamic programming languages simply allocate more objects and heavier objects especially with how we use them.
That's what the OS VMM subsystem provides... abstraction and management of the memory hierarchy to decide what RAM to use and what RAM regions gets discarded or swapped to/from disk.
If an OS were built entirely around a single instance of HiPE/BEAM similar to LING, it might be possible. For efficiency of apps, ditch GC where possible and use precise memory allocation. When that's not possible, use thread-local, immutable storage pools of objects like BEAM so GC can be concurrent and parallel. The messiest way is to do it like the JVM and other systems that throw all objects into a single pool and require pausing the world and expensive graph walks to clean up.
3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.
4. Delete the in-box Weather app icon.
Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.
(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)
As much as I hate the weather app myself, this isn't an equivalent solution. The weather app shows the temperature in the taskbar itself, without opening anything. Also, I don't keep my browser open 24/7, so it's more than just loading a single extra tab, you need to wait for the browser process itself to start up.
If you want to load weather in a browser from the taskbar instead of having it available without having to open another application, I'd recommend using dillo or some such to load wttr.in or similar. A single http request that loads fast from a comparatively simple application that also loads fast. You might even be able to load it as a .hta file.
118 comments
[ 2.2 ms ] story [ 85.5 ms ] threadReally Microsoft? Do you really need all the ads revenue from the weather app?
What’s next? Ads on the start menu?
Which matters because the things most consumers are doing on their computers haven't changed in the past 15 years. We browse the web, edit photos, message friends, and so on. AI generally runs on remote servers anyway.
For years, everyone kept saying it was fine that Electron used gigabytes of memory, because on modern PCs memory was plentiful anyway. Well, it's not plentiful anymore! Maybe it's time software developers actually used resources efficiently?
Hey, you even have an LLM to help you now!
Sure, but we're being screwed regardless. You should be disappointed that almost 2 decades on, pricing hasn't improved. You should be disappointed the reason memory costs so much is because of AI contracts that you cannot compete with.
>Maybe it's time software developers actually used resources efficiently?
At least anecdotally, I'm seeing more and more native apps being written. Sure most aren't first party products, sure some are AI generated but its better than having 11 electron apps on my computer running at the same time.
I want to upgrade to AM5 (thus DDR5). I currently have 64GB of RAM and most of the time in games (even "less demanding" games like CS2), I find my system using over 32GB of RAM. This is a Fedora system!
I think I could get away with 48GB, but 64GB is too far out of my price range.
That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?
But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.
see File pilot as an example of what is possible when competent software engineer attempts it
Real programming means writing your own javascript glue, pulling in hundreds of supply-chain-compromised js libraries that you never inspect or profile, and running the whole thing in a browser engine, while making sure to store all state in the cloud.
The modern breed of programmers who don't understand programming have switched from C and C++ to Rust and Go, so they're on the right track of using more resources to improve the developer and user experience, but they haven't gone nearly far enough. They still do dumb things like write efficient code, and profile and put effort into reducing binary and resident size. They should trust in javascript and the browser and the internet, like all good programmers do.
Zig programmers have completely lost the plot. They're of the type that tries to write "hello, world" manually rather than pulling in a third party library so they can efficiently call helloWorld(). Writing single-binary apps that fit on a floppy? Who even cares? What even is a floppy? How do they call themselves programmers without css and advertising telemetry?
They don't want you to remember that Windows XP's minimum system requirements specified 64MB of RAM. This weather app uses 20 times more memory than an entire operating system from 25 years ago.
I read this circa 2010 and it stuck with me ever since. Also, have felt this way over the years, when I see Windows users work.
If you pay 0.5-1GB to load the edge/chromium libraries but that memory is amortized over N different apps the user is likely to run, then the ”1GB for the weather app” is an unlikely worst case.
A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.
This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.
Running the GC more often wouldn't save much. Dynamic programming languages simply allocate more objects and heavier objects especially with how we use them.
If an OS were built entirely around a single instance of HiPE/BEAM similar to LING, it might be possible. For efficiency of apps, ditch GC where possible and use precise memory allocation. When that's not possible, use thread-local, immutable storage pools of objects like BEAM so GC can be concurrent and parallel. The messiest way is to do it like the JVM and other systems that throw all objects into a single pool and require pausing the world and expensive graph walks to clean up.
1. Install uBlock Origin in Edge.
2. Start Edge, browse to MSN Weather.
3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.
4. Delete the in-box Weather app icon.
Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.
(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)
If you want to load weather in a browser from the taskbar instead of having it available without having to open another application, I'd recommend using dillo or some such to load wttr.in or similar. A single http request that loads fast from a comparatively simple application that also loads fast. You might even be able to load it as a .hta file.