Sign in Subscribe

Unifying Web and Native Systems

Daniel

• 7 min read

Marc Andreessen of Netscape announced a set of new products that would help transform their browser into what he called an "Internet OS" that would provide the tools and programming interfaces for a new generation of Internet-based applications. The so-called "Internet OS" would still run on top of Windows — being based around Netscape Navigator — but he dismissed desktop operating systems like Windows as simply "bag[s] of drivers", reiterating that the goal would be to "turn Windows into a mundane collection of not entirely debugged device drivers".
— Internet OS, Wikipedia

Intro

The Internet OS is the natural result of asking a simple question — why are there 2 platforms for applications in current-day systems; native and Web? For proponents of the Internet OS, the answer is simple; get rid of native apps, and standardize around the Web. The most prominent example of this philosophy today is Chrome OS, Google’s stripped back version of Linux, designed to run the Chrome browser exclusively.

— Chrome OS (source]

It’s worth noting that the term “OS” is a little overloaded these days, but clearly, in this sense, it is not being used to cover the lowest level hardware control (kernel, device drivers, etc.) but the user-space platform; the APIs and services that user-applications are programmed against.

I am very much in favour of such an effort. A divided world of behaviour seems wasteful, and I think a cross-device, hyperlinked environment is the stronger starting point than a single machine, hardware-oriented abstraction layer. But despite 20 plus years of focus and investment in the space, it still hasn’t taken off. Even though there’s a constant stream of now, high-quality web apps, I can’t help but feel that something is missing. I frequently have to step out of the browser environment to get things done. And it doesn’t seem as though I’m alone in that:

It’s important to ask why this is. A huge amount of effort is currently being spent to close the the apparent gap between native apps and Web apps by focusing on features like speed and minor integration points like notifications. These are important, but I don’t think that they’re at the root of the issue. Similarly, if we just start copying features blindly from existing OSs, we may end up replicating a world that is sub-optimal or a dead-end, and hamper further development.

The Problem

As mentioned in the previous post Killing Apps, I believe that a huge amount of friction in software comes at the edges of applications, where inadequate interoperability solutions means that sophisticated day-to-day work activities are slow and painful. But at least on the desktop, there are default interoperability solutions — predominantly around the file system in UNIX based OSs (exclusively so in Plan 9 and Inferno) or objects in Smalltalk. While Web applications can expose APIs, there is nothing native to the browser/server relationship that allows me to take advantage of them; if I wish to open a presentation made in Slides in another program, one (or both) of them must have been programmed to support the specific API of the other.

The problem here really feels like a prevalence of early binding, where the data that Web applications hold can’t be reused in any situation, or in any way, that wasn’t anticipated by the author. The Web’s architecture is great for client/server state transfer, but lacks a primitive, universal interface for composing services. Through the file system or object methods, multiple tools can be brought to bear on a problem, and this just isn’t possible using only the traditional browser model.

Here’s an example I was facing today; how to import historical data from one Web app into another. The suggested solution? To download a file in one app and upload in the other (or use a 3rd party app which has been explicitly designed for this transfer). If you wanted to download a lot of files, tough; it was one by one. Bottoming out to the file system like this is an okay solution in some ways, but doesn’t feel native to the Web, and again, relies on application authors to explicitly enable this option. (A desktop app would, by default, store its data on the file system somewhere).

The most important role of the system is to provide a file system

— The UNIX Time-Sharing System (Ritchie, D.M.; Thompson, K.)

The lack of a consistent, universal interface for working with data across applications has hit the browser a number of times. In its original incarnation, the Web was supposed to be a read write medium.

— Enquire (source)

Tim Berners-Lee’s Enquire, which predates his work on HTML, had Link, Add, and Edit items in the menu. Also, for many years, the W3C used to develop the Amaya browser, which allowed for the creation of any resource, including SVG.

— Amaya (source)

I’m a big believer in the intent behind these efforts, so it’s worth spending some time to think about why it failed. HTML was clearly intended to be a data storage format — resources would be saved to disk as HTML and served as is. When document editing features were dropped from browsers (leaving only form filling), there was an effort in WebDAV to rectify the situation with an additional set of interfaces. But even the WebDAV model assumes a relatively static site being served from a file system, with something like index.html in each folder.

4.5. Source Resources and Output Resources

Some HTTP resources are dynamically generated by the server. For these resources, there presumably exists source code somewhere governing how that resource is generated. The relationship of source files to output HTTP resources may be one to one, one to many, many to one, or many to many. There is no mechanism in HTTP to determine whether a resource is even dynamic, let alone where its source files exist or how to author them. Although this problem would usefully be solved, interoperable WebDAV implementations have been widely deployed without actually solving this problem, by dealing only with static resources. Thus, the source vs. output problem is not solved in this specification and has been deferred to a separate document.
— RFC 4918

Clearly, the real power of the Web turned out to be as a presentation medium rather than storage medium, where the details of the systems behind the sites were completely hidden, and HTML just used to serve up the interface. The situation now is that quite sophisticated, dynamic apps can be built in JavaScript, but they’re the very definition of late bound. If an author comes up with a great interface for editing an image, say, that has to be included by every site author going forwards, and if there are competing ones with different strengths and weaknesses, then the user isn’t able to pick which they would rather use.

Some companies, such as Google, have one solution — Google Drive. This is a cloud-native file system, and their applications, and those of 3rd parties, may use it as an interoperability backplane. It clearly addresses some issues here, but it isn’t standardised and deeply embedded in the browser (File > Save). Most importantly, though, it feels like an abdication of imagination; a cloud file system is better than nothing, but I’m not convinced that it’s the ultimate solution. Just getting the browser back to where desktops were 40 years ago does not feel like progress.

Solution

In casual conversation with friends, there seems to be a pervasive thought that the Web is deficient, but I don’t see a huge amount of effort to fix it, barring cosmetic work around the edges.

Of those who are working on solutions, there seem to be a spectrum of approaches between two extremes — one would be to tear down the Web and rebuild a more coherent system that natively allowed late binding of behaviour over different sources of data, and the other would be to embrace the Web, warts and all, and look for incremental advances, or interfaces that could be standardized, that allow us to move forward while preserving what’s worked.

Alan Kay, on the mailing list for the VPRI project, is evidently in the first camp:

For example, one of the many current day standards that was dismissed immediately is the WWW (one could hardly imagine more of a mess).

But the functionality plus more can be replaced in our "ideal world" with encapsulated confined migratory VMs ("Internet objects") as a kind of next version of Gerry Popek's LOCUS.

The browser and other storage confusions are all replaced by the simple idea of separating out the safe objects from the various modes one uses to send and receive them. This covers files, email, web browsing, search engines, etc. What is left in this model is just a UI that can integrate the visual etc., outputs from the various encapsulated VMs, and send them events to react to. (The original browser folks missed that a scalable browser is more like a kernel OS than an App)

— Alan Kay, VRPI Mailing List

For the other path, the most fascinating track that I’m aware of is Webstrates. It fundamentally uses the core concepts of the Web, but with just a few small tweaks, it not only solves interoperability but also tackles the app/document divide that a simple file based approach reintroduces.

All of which might lead to optimism about the future of the Web, but there are some fundamental blockers in place. The recent trends in browsers seem to be ever larger and more complex codebases supporting a mish-mash of services and APIs. This complexity means that only a few large organisations can really back browser development, and there are many vested reasons (link to recent DRM news from EFF) why they might want to see this trend continue. Or perhaps the industry is cyclical and, like the IE6 era, this is just a pause before a wave of creative innovation that fundamentally moves the Web forward, and finally establishes the Internet OS as a solution to competing user-space platforms.

Sign up for more like this.

Enter your email
Subscribe