Bob Metcalfe’s prediction about the web browser becoming an Operating System platform

In the book ‘Fire in the Valley‘ covering the history of the development of the PC (which I’m still reading for the first time, I’m down to the last couple of chapters in the 2nd Ed) towards the end of the book discussing The Browser Wars there’s an interesting passing comment about Bob Metcalfe and web browsers. I’m not sure if this was a direct quote from Metcalfe or just dramatization based on known facts, but there’s a passing note that Metcalfe commented that the web browser would become the operating system platform of the future (my paraphrasing).

Metcalfe has made a number of predictions in the past that turned out to be far from the mark, including the prediction in his column in Infoworld, Dec 4th 1995, that the internet would implode in 1996 (for more, see section on his Wikipedia entry):

(Google Books direct link)

His comment about the browser becoming the next operating system platform that was mentioned in Fire in the Valley I think is far more interesting than the above prediction because in early 1995 that would have been an incredibly bold and forward looking statement. Remember in 1995 we had only just seen a year of NCSA Mosaic which was launched in September 1993, and Netscape Communicator had only just been launched in 1994 by Marc Andreessen and company after leaving NCSA. Searching in Google Books (awesome for tracking down quotes in archived magazines and periodicals) I think this column, from February 27 1995, might have been the source referenced in Fire in the Valley. This was written a few months before Microsoft’s Internet Explorer was launched in August 1995.

“At Demo 95, it became clear the Web is our next generation Operating System”


There’s some amazing IT industry history in this column from 21 years ago; about Microsoft Bob, Windows 95 (which was yet to launch later that year) and IBM OS/2, which ” … was demonstrated doing more things at once than I would ever want to do”. However the key feature of this column was commenting on the numerous demos of web browsers and web server products shown as this industry event. From 1995, here is an amazing prediction of the web-based future yet to come:

“… these former web browsers will be euphemized as ‘operating environments’ or some such, and every OS will have one”

… this is from a time before when Windows included Internet Explorer as a pre-installed, default, application for accessing the world wide web (which later led to the anti-trust lawsuit). Continuing:

“… as their APIs mature, they will graduate – like Windows may – to becoming full-fledged OSes all by themselves … Web Browsers and servers are surely our next-generation OS”

Ignoring the possibly intentional dig at Windows becoming a ‘full-fledged OS’, the comment in 1995 that browsers might become “our next-generation OS” from the point of view of the web-enabled everything world of 2016, 21 years later, is quite amazing.

As trends have already shown in the relatively short life of the IT industry so far, these things tend to go round in circles. We’ve had centralized systems, client/server systems, distributed systems. The first versions of web browsers, like Mosaic, had little support to do anything other than retrieve static content from a remote web server and display the content to the user. As cgi-bin scripts were introduced, processing to support dynamically generated content was server-side (centralized). Fast forward to the more recent few years however, browsers have become more capable in executing client-side functionality, to the point where it’s now a common approach to off-load logic previously executed server-side and execute it client-side in the browser, allowing systems to scale to what is now called ‘web-scale’ (e.g. Facebook supporting 1 in 7 of the Earth’s population logging on to Facebook in a single day – yes, that’s 1 billion people).

If at this point today you were to ask if we have already reached the point Metcalfe was predicting where the browser has become a common operating system platform, I think it depends on what aspect of computing you look at. It’s undeniable that pretty much anything and everything is available and accessible online via a browser, from checking your bank balance/paying your bills, to booking a haircut, buying groceries, and not to mention social networking (something that in it’s online form really had no comparison before the internet and the world wide web). From a mobile perspective however, if you think about the prevalence of ‘apps’ on native platform mobile devices like Android and iOS, then the most common computing platforms of today (the majority of people access the internet from a mobile device) do still look like they are still platform specific and native, and not a shared common, browser based runtime. Unknown to your average app user however is the fact that most apps are actually hybrid apps, using a web view to load and embed web-based content within a native app.

If you take a wider view of computer usage across all device types, desktops, laptops, tablets and other mobile devices, then I think it would be a different picture, one where yes, there is a common platform provided by a browser, even if it’s different browser implementations on different devices. I can access my bank account via a web-based application for example using Safari on my Mac, using Chrome on my Android phone, using IE on my work provided Windows laptop. If you add a Chromebook into this picture, now you’ve got a device that can only access sites and applications using a browser, it is a device that is entirely browser based, where the browser is the platform.

The coming of Web Assembly

The main reason Metcalfe’s prediction as mentioned in Fire in the Valley caught my attention is because the idea of a common browser based platform is maybe closer than expected, and with current developments in browser technology, a whole lot better than just standardized support for HTML, CSS and JavaScript. Google have had Native Client (NaCl), the ability to run platform native (as a subset of x86, ARM or MIPS instruction) code within a sandbox in Chrome since around 2011. Platform Native Client (PNaCl) further developed the benefits of native platform performance by adding support for executing platform independent code. Development of asm.js and support in Firefox has been going on for a couple of years, and even gaining support by Microsoft in the Edge browser on Windows 10.

WebAssembly, a W3C standard project with involvement from all the major players, Google, Apple, Mozilla, and Microsoft, aims to define and bring a common binary executable format to the browser. Announced by Brendan Eich back in June 2015, the idea of a common runtime is of course not new. We’ve had Java’s JVM for 20 years. We’ve had .NET’s CLR for around 15 years. While Java code can execute on any platform where you have a JVM installed, Microsoft’s .NET has been more limited to only Windows. Support for other platforms is possible via the non-Microsoft provided open source project Mono. Even with Java though, each browser required the manual installation of a browser plugin.

The difference in approach with WebAssembly is that if every browser already natively supports WebAssembly as an integral part of the browser, has Bob Metcalfe’s prediction of the browser being a common runtime platform … arrived?

Fiddler – monitor HTTP requests from your browser

Fiddler is invaluable for monitoring HTTP requests from your browser. If you’re investigating HTTP header usage and the effort on caching static content, Fiddler is definitely the way to go, since using the Developer Tools in IE, Chrome or FireBug in Firefox don’t always give you an accurate picture of the actual outgoing HTTP requests. IE is the worst… its developer tool shows HTTP requests going out even though the files are being retrieved from cache. If you really want to see what’s going on then you need something like Fiddler.

To review requests against a server running locally (against localhost), there’s a number of tips in the docs here, but the simplest approach seems to be to use your own IP address (actual address, not 127.0.0.1) instead of localhost or any of the other approaches listed on this page. It works without any other changes.