When you resized a window on classic Mac OS, your program had to actually like, draw the new window. Your program is spinning in a loop listening for events, you get a window-resize event. So you allocate space for the new bitmap, calculate what you need to display within the enlarged view, and then draw it. Did the user drag another window over your window, and then drag it away again? You get an event for that. Gotta draw what was there again all over again.

This is all very close to the metal. On early 68K Macs, these routines are in ROM, and are very compact with each call only 2 bytes of code, actually being actual CPU opcodes (trap instructions). So if you sequence these Toolbox invocations correctly, as a great master programmer of coroutines who never mistreats a handle as a pointer, you can render a complex scene with hundreds of polygons and a full screen of text in 200 milliseconds at 8 MHz.

But it takes 1000 lines of hand-holding the machine to do it.

Today, all of this is typically handled by instantiating a window object which draws into a private framebuffer which the system composites. That right there is tens of megabytes of RAM overhead. Then you use a thread to handle the UI and a thread to draw and etc. There's almost no boilerplate to just show a window. Perhaps one line of code. And it doesn't get overwritten by intrusive neighbour windows. Creating frameworks that can do all that bookkeeping in a flexible and general way (don't forget you want to be able to render vector fonts for any Unicode language) has a tremendous overhead.