[captainmuon]

Does anyone else find it crazy that the absolute size of WebCore is 38 MB? That's larger than the Linux kernel which includes a bunch of drivers.

If I understand Webkit's architecture correctly, that doesn't even include chrome (the visible UI, not Google's browser), JavaScriptCore, platform specific glue, and especially no auxilliary files (certificates, icons, the "broken image" sign, ...).

Sometimes I long for the good old days where a browser used to fit on a floppy disc (Opera).

I wonder if someone has done analysis on what features make browsers so complicated. I could imagine that 20% of the code could handle 80% of the features (as so often). You could have a 'lite' HTML subset that's targeted on rich documents, rather than rich client webapps. Something like that would be great for older computers or mobile computers.

Going a bit further, I know there is a lot of crazy stuff in WebKit... e.g. neural networks try to predict which links you'll click on, based on previous behavior, mouse movements, etc, and then the browser prefetches likely pages. There are runtimes for NaCL, pNaCL, Flash, there's a PDF browser (some of these are plugins), there is a VNC client, support for a bunch of different rendering models (layered HTML elements, Canvas, 3D), media support (codecs), support for webcams and microphones, and peer-to-peer communication, and much more. phew

I guess a large chunk of this stuff should be in the OS, so that other apps could benefit from it. And another large part of it should be in plugins, so the browser can benefit from all the codecs on the system, for example.

[anon1385]

>I wonder if someone has done analysis on what features make browsers so complicated.

There is a visualisation of the chrome binary here: http://neugierig.org/software/chromium/bloat/ I'm not sure how up to date it is now, but it gives a vague idea.

>I guess a large chunk of this stuff should be in the OS, so that other apps could benefit from it. And another large part of it should be in plugins, so the browser can benefit from all the codecs on the system, for example.

That is the case for Safari for example (using PDFKit for pdfs etc and system codecs for video and audio). Mozilla like to bundle everything with Firefox because they view Firefox as an OS itself, rather than just another application for viewing html documents. Most of the huge size and complexity in modern browsers is due to people trying to turn the browser into an operating system: https://en.wikipedia.org/wiki/Inner-platform_effect

[extra88]

I think a lot of what bulks up the rendering parts of the code is the handling of invalid web code. Not JavaScript, it's a programming language so throwing an error and stopping is expected behavior. But for HTML and CSS, browsers are expected to Do What I Mean, Not What I Wrote. If they only rendered valid code, they'd be a lot smaller.

But there are a lot of new APIs under the HTML5 umbrella. They're all accessed using JavaScript for some, a lot of the code will be in WebCore. Here's a bunch: http://www.netmagazine.com/features/developer-s-guide-html5-...

I'm sure Canvas and WebGL add a lot to WebCore.

[dragonwriter]

> There are runtimes for NaCL, pNaCL, Flash, there's a PDF browser (some of these are plugins)

Really? While Chrome has all of those built in, the other WebKit browsers don't so why would it be in the WebKit source tree (especially after the mutual purges of the Blink/WebKit split.)

Also, all of those (except maybe the PDF viewer) in Chrome are plugins, and they are PPAPI (which was Chromium specific, not used by other WebKit browsers) not NPAPI plugins, and Flash and maybe the PDF viewer aren't bundled with Chromium (just Chrome) so its really weird that anything related to them would remain in WebKit.

[captainmuon]

You're right, I mixed up WebKit and Chrome there.

[pcwalton]

NaCl, PNaCl, Flash, and PDF are not part of WebKit (unless you mean the NPAPI support needed to make it work; even if you're just talking about NPAPI, PNaCl needs Pepper, which is part of Chromium, not WebKit).

[smackfu]

Remember that the browser game is not just about features, but also about speed. And the fastest way to do something is often not the shortest code.