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 are 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 
Some rights reserved by Pink Sherbet Photography)
Comments on this entry are closed.
Not an OS. But it is more of an intellectual framework.
The Web platform is a framework, but it avoids some of the problems classic OO frameworks have because Web applications don’t subclass framework classes.
You can have integrity and robustness with a framework — you can run the framework implementation in a sandbox; the sandbox communicates with the outside world using a limited “kernel interface” which provides integrity.
The current brower programming model is not unlike the original Classic Mac programming model. Well, OK the Mac Color Classic. In fact my preferred framework for browser applications (as opposed to “web pages”) is Cappuccino, which is essentially NeXTStep circa 1988. I suspect the browser model will become even more kernel OS-like as it becomes more concurrent and more supportive of multiple languages, “native”-ish cloud services, etc.