Why browsers are bloated

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/Scrollbar.cpp
https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
Let's reinvent the fucking scrollbar, which every goddamn platform with a UI already has, and make it behave subtly different from the native one!

Right-click a native scrollbar in some other app:
- Scroll Here
- Top
- Bottom
- Page Up
- Page Down
- Scroll Up
- Scroll Down

Right-click a scrollbar in Chrome:
- Back
- Forward
- Reload
- Save As...
...

Right-click a scrollbar in Firefox and Opera:
Absolutely fucking nothing happens!

What the fuck!? How did these terminally retarded idiots get involved in creating one of the most important pieces of software to the average user?

>>258-277
Traversing an array and calling a function on each element is something like ~5 bytes for the main loop:
array_fold_loop:
lodsd
call ebx
loop array_fold_loop

Calling a function is already 5 bytes, and then you still have to setup the parameters for it, so it's smaller and faster to just write the loop directly.

Traversing a binary tree (pre-order, nodes stored as [data, left, right]) is a bit less than 32 bytes, so it does make some sense to have this be a separate function if you're going to use it more than once:
tree_fold:
lodsd
call ebx
lodsd
test eax, eax
jz no_left
push esi
mov esi, eax
call tree_fold
pop esi
no_left:
lodsd
test eax, eax
jnz has_right
ret
has_right:
mov esi, eax
jmp tree_fold

But the tree structures I'm using for DOM/rendering can be traversed non-recursively, see http://bbs.progrider.org/prog/read/1406427616

>>269
All that looks like it's doing is essentially caching the results of rendering each subtree, which is not anything interesting.

One thing that I don’t yet understand though, is how this plays out with memory usage.

Oblivious dumbfuck... this is why software is so fucking bloated!