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?

>>95
It's a start, at least...

children: Vec<Node>

That's not really the best choice for the DOM tree, as simple as it may look - arbitrary position inserts and deletes, and thus "find next sibling"/"find previous sibling", are going to be far more common than indexing operations.

The article about parsing is just one big facepalm. At least use a state machine for the tokeniser... I see now, this is written in an id10t-proofed language that's missing goto so they have to bend over backwards to do anything truly simple and efficient with it. In the old thread I mentioned I had a full HTML5 parser written in C in a 24KB binary, consisting of 12KB tokeniser and 12KB tree construction. I've rewritten the tokeniser in Asm since then, and it's now... less than one kilobyte!!! At ~70 states, with around a dozen bytes per state on average, maybe that's not so surprising after all.

Tree construction is a bit trickier since the full number of possibilities is basically {text, n types of tags open/close, comment, doctype, EOF} * 23 "insertion modes", but many of these cases are identical so there's a lot of redundancy (e.g. DOCTYPE tokens are basically ignored in everything but the initial IM - considering that 16 tokeniser states are needed just to parse these, it's rather wasteful.) At the moment my tree construction is 66 functions in ~2K lines of C with the bulk of the code being switch()s; when I have the time I should try to shrink that too. Encoding the state data in arrays instead of directly in code might help...

I haven't written any CSS parsing code yet so I'll not make any estimates nor comments on that third article.