In my post, The Browser is a Transitional Technology, I wrote that I thought  web browsers were really Personal Computing Era applications and that browsers were unlikely to continue to exist as such as we move deeply into the Ambient Computing Era. However,  I expect browser technologies to have a key role in the Ambient Computing Era. In Why Mozilla, I talked about the inevitable emergence of a universal application platform for the Ambient Era and how open web technologies could serve that role. Last month I gave a talk where I tried to pull some of these ideas together:

For slides, 14-19 I talked about how when you remove that PC application facade from a modern browser you have essentially an open web-based application platform that is appropriate for all classes of ambient computing devices.

Today Mozilla announced an embryonic project that is directed towards that goal.    B2G or (Booting to the Web) is about showing that the open the web application platform can be the primarily platform for running native-grade applications.  As the project page says:

Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include — and in places exceed — the capabilities of the competing stacks in question.

One of the first steps is to directly boot devices into running Gecko, Mozilla’s core browser engine.  Essentially the devices will boot directly into the browser platform, but without the baggage and overhead of a traditional PC based web browser.  This is essentially the vision of slide 17 of my presentation.  The “G” in B2G comes from the use of Gecko, but the project is really about the open web. Any other set of browser technologies could potentially be used in the same way.  As the project web site says: “We aren’t trying to have these native-grade apps just run on Firefox, we’re trying to have them run on the web.”

This project is just starting, so nobody yet knows all the details or how successful it will be.  But, like all Mozilla projects it will take place in the open and with an open invitation for you involvement.

Recently I’ve had some conversations with some colleagues about how Web IDL is used to specify the APIs that browsers support for web applications.  I think our discussions raised some interesting questions about  the fundamental nature of the web app platform so I wanted to raise those same questions here.

Basically, is the browser web app platform an application framework or is it really  something that is more like an operating system? Stated more  concretely, is the web app platform most similar to the Java or .Net platforms or is it more similar to Linux or Windows?  In the long term this is probably a very important question.  It  makes a different  in the sort of capabilities that can be made available to a web app and also in the integrity expectations concerning  the underlying platform.

In a framework, client code directly integrates and extends the platform code. This allows client code to do very powerful things but the cost of this is that client code can do things that results in platform level errors or even failures. Modern frameworks are pretty much all defined in terms of object-oriented concepts because those concepts permits the client extensibility that is the primary motivation for building a framework. Frameworks generally have to trust their clients because they frequently have to pass control into client code and their is no way they can anticipate or validate everything client code might do. Frameworks are great from the perspective of what they allow developers to create, they are less great in turns of robustness and integrity.

In an operating system, client code almost never directly integrates with the platform code. Client code is limited to a fixed set of actions that can be requested via a fairly simple system call interface. In the absence of platform bugs, client code can’t cause platform level errors or crash the platforms because the platform carefully validates every aspect of every system call request and never directly executes untrusted client code. Operating systems don’t trust their clients. Successful operating system API are pretty much all expressed in terms of procedure calls that only accept scalars and simple structs as arguments because such arguments can be fully validated before the platform uses them to perform any action. Operating systems are great from a robustness and integrity perspective but they don’t offer much direct help to clients that need to do complex things.

Historically, there have been various attempts to create operating systems that uses framework style object-oriented client interfaces. All the major attempts at doing this that I am aware of have been dismal failures.  Taligent and Windows Longhorn are two notorious examples. The problem seems to be that the power and extensibility that comes with framework style interfaces is in direct conflict with robustness and integrity requirements of an OS. It is very difficult and perhaps impossible to find a comprise that provides sufficient power, extensibility, robustness, and integrity all at the same time. Systems like Taligent and Longhorn also have had significant durability issues because one of the ways they  tried to balance power and integrity was by describing their APIs in terms of static recursive object-oriented typing which are very hard to evolve in an backwards compatible fashion over multiple versions.

This begins to sound a lot like the way Web IDL is being used to describe web app APIs.  It has framework style APIs but browser implementers would like to have OS style system integrity and robustness.

One way OSes have addressed this issue is by using a  kernel.  The kernel is a small part of the overall platform that is very robust, has high integrity, and exposes very stable APIs.  The majority of the platform is outside the kernel.  In general, bugs or misuse of  non-kernel code may crash a application but it can’t crash the entire system. One way to think about large application frameworks like Java and .Net is that they out the low integrity but high leverage outer-most layer of such a kernelized design.

So what is the Web App platform. Is it a framework or is it an OS? I think it needs to be designed mostly like a framework.  However, there probably is a kernel of functionality that needs to be treated more like an OS.  That kernel is not yet well identified. It probably needs to be.  Otherwise, the designer of the web application platform run the risk of going down the same dead-end paths that were taken by the designers of “object-oriented” OSes like Taligent and Longhorn.

(Photo Attribution Some rights reserved by Pink Sherbet Photography)

Combining Mirror Facets

April 29, 2011

In my last couple posts I introduced idea of using Mirrors for JavaScript reflection and took a first look at the introspection interfaces of my jsmirrors prototype. In this post I’m going to look at the other reflection interfaces in jsmirrors and how they are mixed together to provide various levels of reflection privilege. When [...]

Read the full article →

Looking into Mirrors

April 27, 2011

In my last post I introduced the programming language concept of Mirrors and mentioned jsmirrors, the prototype I’ve been working on to explore using mirrors to support reflection within JavaScript.  In this post I’m going to take a deeper look into jsmirrors itself.  I had three goals for my first iteration of jsmirrors: Define basic [...]

Read the full article →

Experimenting with Mirrors for JavaScript

April 25, 2011

A common capability of many dynamic languages, such as JavaScript, is the ability of a program to inspect and modify its own structure.  This capability is generally called reflection. Examples of reflective capabilities of JavaScript include things like the hasOwnProperty and isPrototypeOf methods. ECMAScript 5 extended the reflection capability to JavaScript via functions such as [...]

Read the full article →

Why Mozilla?

March 25, 2011

As somebody who is on record as believing that web browsers are a transitional technology, people occasionally ask me why I decided to go to work for a “browser company” like Mozilla. You can find a big part of the answer here: As we move deeper into The Next Era of Computing there are still [...]

Read the full article →

The SPLASH Submission Clock is Ticking

March 10, 2011

I’ve previously written about the SPLASH Conference and why you might consider writing for it. Now, is the time to get serious as April 8, 2011 is the submission deadline for the major SPLASH conference tracks. If your aren’t familiar with SPLASH, here is how the SPLASH website describes itself: Since 2010 SPLASH is the [...]

Read the full article →

A JavaScript Optional Argument Hazard

February 24, 2011

My recent post on testing for negative 0 in JavaScript created a lot of interest.  So today, I’m going to talk about another bit of JavaScript obscurity that was also inspired by a Twitter thread. I recently noticed this tweet go by: This was obviously a trick question.  Presumably some programmer expected this expression to [...]

Read the full article →

Testing for -0 in JavaScript

February 16, 2011

A few minutes ago I saw a tweet go by from my colleague, Dave Herman (@littlecalculist): For background you need to know that JavaScript Number values have distinct representations for +0 and -0.  This is a characteristic of IEEE floating point numbers upon which the specification for JavaScript numbers is based.  However, in most situations, [...]

Read the full article →

The Browser is a Transitional Technology

January 31, 2011

In the graphic for my Third Era of Computing post I have two pairs of lines labeled “Transitional Technologies”. In my model, a transitional technology is a technology that emerges as a computing era settles into maturity and which is a precursor to the successor era. Transitional technologies are firmly rooted in the “old” era [...]

Read the full article →