Mostly rendering. A bunch of images, text, UI elements. On a modern high resolution display it adds up quite quickly. You can surely cut it down a bit, but 100MB isn't absurd.

A weather widget using 8 bit color plus alpha on a 4k display show three full size images in 100mb. But I suspect that's not the ux we're talking about here, and a widget style system has no excuse.

Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.

https://wttr.in/ shows it's very possible.

The display on that page is literally broken for me, the boxes are all misaligned. It seems like it can't handle Japanese text correctly. Properly working localization in dozens of languages is one of those things that adds "bloat" to modern software that was missing in the bad old days.

Unicode doesn't require 100s of megs.

Vector icons. It can be fit under 50MBs.

Those still have to be rasterised to a pixel-based frame buffer at render/compositing time.

Yes but that space would have existed anyway for a window of that size regardless of its contents.

Quite a tasteless metaphor, no?

If I full-screen it in high enough resolution it can be excused for using 100MB temporarily.

The window in the article wasn't very big. At most it would have about 10MB of framebuffer, and the images on display would fit into 1MB uncompressed.

We can't excuse typical program waste with screen sizes. Especially when you can switch to 1080p or 720p and watch them still use massive amounts of memory.

I think this depends on your location, because in some places you really want to view a radar map. "Rain in $CITY" is practically useless for me. Still, the (static?) map in the depicted app shouldn't take 1GB.