Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I checked this on my computers:
On Windows 10 the Weather application uses 2-4MB when not active, which climbs to around 490-550MB when active. On Windows 11 the Weather application doesn't appear to be running at all when not active and it climbs to about 540MB when active.
No where near the results presented in the article, however:
The amount of memory used could vary by region and provider used to get the weather data, so in my region it would only use half a gig, in the USA it could use a lot more.
Half a gig is still too much for a Weather application to use, even with all the images and animations that it has I would estimate it only needs to be half as big at most.
I'm puzzled by why Microsoft made this into a Web based application since they could have written something much more efficient with native code, it's not as if they needed to target multiple different operating systems, just Windows and now just a single version of it.
by daemin - > I'm puzzled by why Microsoft made this into a Web based application
The number and availability of native UI programmers compared to web devs is a rounding error.
- > By comparison, Apple's native Weather app on macOS reportedly uses less than 250 MB of RAM
That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?
by eviks - The most lightweight solution I can think of is:
curl wttr.inby thrance - https://github.com/dglent/meteo-qt
It is using 122.7 MB at present.
by RunSet - I built a weather app for myself fetching ECMWF ensemble forecasts for my home location. Running the service is 60mb plus data 39mb and another 2mb for the spaghetti charts showing temperature, clouds, precip, wind over 10 days. What do I need to do to fill the other 900mb?by loehnsberg
- The article now says for me "By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions."... which is not exactly the same wording.
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
by userbinator - Thank you. And it is a shame I had to scroll down this far in the comments for someone to point out the obvious. Even a weather app that uses "only" 250MB of RAM should never have been delivered by a semi professional software shop - 250MB is enough to store whatever they can display in full screen on a 5k display as a bitmap - 5 times.by jlg23
- My entire kde "plasmashell" which includes my wallpaper and the various widgets installed (including a weather widget) uses 560MB for a screen with 5120x1440 pixels.by cogman10
- It’s an equivalent app to make a comparison with, one from an OS company.
But yeah, I still remember when a weather app would take 10 MB and I was complaining (1999)
by nashashmi - What's worse is that the previous version of the same Weather app was fully native on Windows 10. Why would you take a perfectly working app and downgrade it like this?by hadrien01
- I hesitate to make this sound positive, but to their credit, the leadership at Microsoft who likely steered the weather app towards using the web stack at least correctly identified a major problem: there is not a single good native UI framework for Windows today.
Jeffrey Snover, creator of powershell, explained it decently well here: https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-...
Was switching to webviews the right solution to that problem? Absolutely not. But at least we can admit they were in a difficult position.
At the time this bloated weather app was probably developed, the choice that most of the rest of the shell and in-box apps were making was C++/WinRT paired with System XAML (i.e. Windows::UI::Xaml aka WinUI 2 aka UWP XAML) via the still-marked-as-experimental-in-2026 islands API (DesktopWindowXamlSource) like the taskbar/control center/file explorer/etc. Or worse, actual UWP, such as the Start Menu, Settings app, or Notification Center. This can have a decent-ish memory footprint - Control Center, for example, uses about 150MB of commit and 30MB of working set. Still not good, but not atrocious either. But even for this mediocre level of performance and efficiency, you end up paying a very high cost in terms of development time and expertise required. This stack "just works" like 70% of the time, but the other 30%, you're scratching your head figuring out where you forgot to hold a strong reference across a co_await boundary. Or figuring out why a XAML ListView corrupted its recycling pool in korea because window messages reentered a nested message loop started by XAML's outbound RPC call that's only made in the TextBlock code for east asian languages. You get a razor thin veneer of user-friendliness, i.e. MVVM, x:bind, co_await ("hey, this is just like C# + WPF!") on top of a 60% finished UI framework and a terrible programming language feature which is quite possibly one of the leakiest abstractions in the history of the world (C++ coroutines). The fact that Raymond Chen managed to write a blog series on C++ coroutines in Windows that is 60 posts long is damning: https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...
On top of all this, Microsoft's status in the industry has dropped. And they have absolutely no structured technical training program for new employees. I guess just pray you get paired with a decent mentor. So, young employees fresh out of undergrad who are asked to work in these codebases are super unproductive and make mistakes on a regular basis that cause inscrutable memory corruption bugs.
For a time, leadership was wildly flailing around trying to find some alternative to this madness. At the time when this bloated weather app was developed, the hot idea was that we should be switching to the web stack for native experiences. There was some low effort hand waving about how WebView2 would be continuously improved, we would mitigate the memory footprint by sharing webviews, etc.
My position is that there's no reasonable choice for building efficient native UX on windows today except by targeting a lower level graphics API like DirectX, Vulkan, OpenGL, or even software rendering in GDI, rather than a GUI framework. Most serious software on windows ends up going down the route of literally building their own UI framework, i.e. web browsers, office, adobe suite. If you don't mind the dated look/functionality of win32's stock common controls, that's also a decent option. I've heard that Qt is okay, but haven't tried it.
One final note: if anyone is earnestly wondering whether WinUI 3 is perhaps, finally, an end to all the bloodshed, my take is: no It is (currently) UWP XAML wearing a trenchcoat, plus a needless namespace change that broke compat, plus the baffling choice to run a copy of the compositor in-process in order to - wait for it - be able to ship WinUI 3 apps downlevel to Windows 7 and have acrylic work correctly!!! (to their credit, they have signaled that they are reversing this decision and moving back to the system compositor). WinUI 3 has the potential to be good, but appears to be too underfunded to achieve its potential.
org_chart_with_guns.jpg
by ntstatusquo - Well, this is Microsoft and Windows; it would be weird if it got better.
- In a parallel universe Microsoft would have never killed Windows phone and they would have been forced to keep these apps a little more memory/performance friendly.by ColdStream
- They probably needed an electron web app that could run the (likely ~8MB+) javascript bundle loaded by their ad provider.
Sad reality aside; when the new app released I was using an old AppxBundle of the last good version downloaded from a microsoft store archive website. Later I fully uninstalled the app as it got annoying to cancel the autoupdate for that specific app. I use a random website now.
by onurtag - 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.
by ntstatusquo - And it also ads on it.
Really Microsoft? Do you really need all the ads revenue from the weather app?
What’s next? Ads on the start menu?
by itopaloglu83 - Yeah it is actually really sad when a company the size of MS still bows down to the great god Advertising!
Avert ye eyes for there are no morals in these bad lands of Redmond!
by ColdStream - They do. Never forget, Microsoft's goal is to squeeze as much money from you as possible.by bossyTeacher
- > What’s next? Ads on the start menu?
They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...
by WakeUpPeople - Microsoft absolutely doesn't need it, but I'm guessing the weather app team (or the core filler apps team or whatever team is responsible for it) needs it to juice a metric to make some middle manager happy.
And it makes the middle manager happy because it lets that middle manager report better numbers to their superiors again.
Etc.
It's why all large dysfunctional organisations do self destructive stuff like this.
by mort96 - 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.
by cogman10 - 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.
by dominicrose - 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.
- > 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.
There’s very minimal state for a weather app. You should be able to sweep the whole thing pretty fast. You could probably statically allocate most of that state.
by goalieca - The ram usage in this case is an order of magnitude lower if you install ublock in edge, as other comments have noted. Why would a system level GC affect wasteful adtech?
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
by mwkaufma - This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal.
Then C# came and said "we can't use it, we have different needs". So did Go.
by afdbcreid - Which is what OSes implemented in system languages with automatic memory management usually do, it is an OS service.
Oberon example,
https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
Active Oberon example,
https://github.com/btreut/a2/blob/master/source/GarbageColle...
Bare metal Java, Go, .NET, Erlang, OCaml,... with bare metal deployments naturally have the runtime take the OS role.
by pjmlp - 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.
by firefoxd