The API wars – 16 years later

It is more than 16 years since Joel Spolsky wrote How Microsoft Lost the API War. The bonds of the win32 API lock-in is broken and the free web is here to take over.

The web has come a long way in the past 16 years. Richer APIs, dramatic performance improvements, and an ubiquity that surpasses anything else that we as a human race have experienced. Easy of deployment is king and the easiest deployment of all is to simply browse to a web page.

Creating web apps has always been riddled by browser compatibility caveats. Various services have been around to test rendering across browsers and versions, and frameworks to address common scenarios have evolved to create a write-once, deploy-everywhere story.

The modern web browser has become our universal runtime environment. It is what Java and .net aspired to on a crazy scale. However, it is not only a runtime environment. It is the perfect client server setup to provide everything as a service.

With the focus shifting from the browser to the actual contents, the value of controlling your own browser engine has become less and less attractive, and last week, Mozilla begun what I think is the final downward spiral of the last alternative to the Google led Chrome family of browsers.

(There are so many things I’d like to say about this. For instance, you should know about the Mozilla manifesto, as well as their funding being secured for the next three years. But I digress).

A browser engine is a hugely complex beast these days. An incredible number of backwards compatibility hacks, while ensuring high performance on both rendering and Javascript execution. Add a broad range of APIs for integration into the native host platform. Combine that with privacy and security concerns, and the code base is starting to turn into a beast.

Now, it seems that Google controls the leading browser engine and thus, holds the direction of the web as we know it in their hands. Google has not only won the search, contents, and personal data collection wars. They also won the API war.

Having a single, almost monopolistic entity controlling all these aspects of life makes me feel very uncomfortable.

I’ve started my own personal de-googling journey, and I know that there are many others doing the same. Taking back ownership over their email, shifting from Google Drive and Google Apps to alternatives such as Nextcloud. But also moving from platforms such as Twitter to federated alternatives such as Mastodon.

A lot of this is probably seen as nostalgia from an earlier generation growing old. The web has moved on and many parts of what I love about the internet are no longer in broad use. For instance, small forums are migrated to Facebook groups, IRC is taken over by freemium alternatives such as Slack, RSS feeds become less and less common, and so on. The web is being centralized and has been so over the past decades.

However, I believe that the tide can be turned.

On the contents side, early adopters are moving to federated and self-hosted services where data lock-in is impossible. Privacy concerns become more common outside of the technology sector. What is needed is great alternatives that are easy to deploy. Examples that I use are Nextcloud, ttrss, fripost, and Signal.

But what can be done about the API war?

An attractive possibility, in my view, is the raise of WebAssembly. It enables the deployment of complex applications into the browser, really turning the browser into the universal run-time environment. It does so for compiled languages and at great performance.

What about deploying a bare bones wasm run-time environment, and then deploy the browser into it. That way, the complex beast that is the browser of today, turns into a much more manageable animal that is the wasm run-time.

What would this change? Short-term, very little. Even if the Chrome engine is compiled to wasm and executed inside an outer shell, the experience and value is still delivered through a very complex code base controlled by one of the most dominant companies in human history.

Long-term, it would mean that the ease of deployment would apply to not only the web, but to the wasm run-time. We would shift from the HTML/CSS/JS world to a wasm world.

Not only would this mean that the universal run-time becomes smaller and more manageable to maintain by multiple parties, it also opens the opportunity to shift to a optimized way to run software (the hardware requirements of the modern browser isn’t really environmentally friendly – it drives energy usage, as well as hardware obsolesce).

Now, all that is needed is time. An idea without execution, is merely a dream. I might be a dreamer, but I think that this is the way forward.

One thought on “The API wars – 16 years later”

  1. Regarding the main premise – what is missing from the offer or using a WASM runtime as the deployment target and deploy a browser on top of that, is a mechanism to replace the main reason that the browser DOM API has won the API war: application discovery.

    The “browsing” part of a web browser is the reason the web application ecosystem has exploded: it is so much easier not only to build your application and deploy it, but also have it discovered by billions of potential users. This is such a paradigm shift that even Win32 applications have been relying on it for discovery since the invention of Tucows (circa 1993, if their web site is to be believed).

    The idea for having WASM as the runtime to deploy applications, without offering a truly compelling discovery experience is doomed to failure as much as the Flatpak and Snap runtimes are doomed to failure, and before them AppImage and 0install (remember that?) failed (i.e. failed to dominate even a tiny fraction of the mindshare web applications are enjoying – all these are still useful in their own little niche solving that nische’s small little problems).

    I’m afraid the web browser is here to stay: not because it won the API war – nobody actually cares about that – but because it has won the discovery war. A tool to replace the web browser has to solve the discovery problem in a more compelling way than a web browser, and in the world of Facebook and Twitter, I’m afraid that this crown can only be taken over by a global company that can afford to not only fund the expensive development of a huge piece of software but also market it globally and distribute it for free. I don’t see anyone unsitting Google in that respect – the last chance to do that was the propagation of the smart phone, and Google has won that as well (it was a bit touch and go for a while, with multiple contenders and even Microsoft in the fray, but except for a small enclave of rabid iPhone users, that war is done as well). A new device and UX paradigm might pose another opportunity in the future: AR glasses, Holographic projections, DNI – those are still up for the taking, but I doubt we will see Google not winning those…

Comments are closed.