Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Fiddling about in The Platform, part I: "browser anatomy"

As a little boy, I was already fascinated with "how things work" and "what things are made of". Screwdrivers were kept where I couldn't reach them, because I wanted to have a look inside anything electrical. I guess geeky-ness is something you are born with... I still have a strong urge to "look inside" things that intrigue me. My latest fancy is this platform everybody is talking about. I mean "platform" as in "the web as the platform" in the Web 2.0 Meme Map sketched by O'Reilly. We should really refer to it as THE Platform, because it is the platform of platforms and it is all around us. It deserves the capitals (no reference to divinity intended here, just borrowing the convention). In this post I will scratch a little bit at The Platform's surface. Doing so today reveals a rather impressive technology that renders web content to human beings and provide means for humans to interact with the web. Oddly enough, we still call this technology "Web Browser" even though it has become a major layer of The Platform. I have never built a web browser myself nor did I dissect one, but I have a fairly good idea of the basic requirements for a web browser: A web browser must be capable of:

  • retrieving information from addresses on the web,
  • interpreting that information,
  • transforming that information into something visually attractive and easy to understand and use: a user interface,
  • interpreting and following the scripts that come with the information on what to do with user generated events and other events within the context of elements of this user interface
  • and submitting information back to addresses on the web.
That's your basic web browsing machine, I think. So, as depicted below, it will at least consist of a networking component that supports the protocols for securely and insecurely retrieving and submitting data, a user interface rendering component and a scripting component for making sense of and executing retrieved scripts.


Makes a web browser look like a pretty dumb thing, doesn't it? No wonder Google made Gears, Microsoft invented Silverlight and Adobe created AIR. The common web browser is too dumb to provide in the modern internet user's needs. Today's web applications need local storage (more than the simplistic cookies common browsers support, I forgot about that one above) to be able to access certain types of content while you are offline. We also need support for cool, smooth 2D & 3D cinematic effects, of course. And we also need advanced communication components for receiving and transmitting high volume data such as high quality audio and video. Our beloved web browser has been extended with various plugins over time to achieve the above feats. You also see that browser vendors have been extending and improving their product to provide built-in support for these feats too. I have googled-up a set of blueprints of two popular Web Browsers. The architectures still look a lot like my own sketch. See for yourself:


Firefox Architecture (crudely copied and pasted this from a PDF using a screendump, so I apologize for the raunchy quality.

IE8 architecture Architecture of Internet Explorer 8 (from wikipedia).
And being the geekiest company of them all, Google decided to explain their latest baby's architecture with a cartoon. One interesting technical detail is that the above mentioned web browser vendors have (or currently work on) something that is referred to as a Virtual Machine. This VM is the engine for processing scripts of instructions. They apply things such as JIT compiling and HotSpot-like technology. These are state-of-the-art tricks to dramatically speed up the performance of these web browser's scripting engines. Hopefully, the efforts in improving the scripting engines will also improve cross-browser compatibility. Because, in spite of what Ajax frameworks promise, Ajax development too often involves manually tweaking javascript for making it work with all browsers (slightly less if you just target the popular ones). It is a pain during development and it remains a pain during maintenance. In future posts I will fiddle about some more in The Platform. Perhaps by digging deeper from the top or by poking at the foundations. Let me know if you have any requests in that respect.

About the author

M. Nankman
M. Nankman

Leave a comment

Your email address will not be published. Required fields are marked *.