The API wars… who actually cares?
This is a public response to Johan Thelin’s post “The API wars – 16 years later. His blog commenting system looks a bit broken and regardless – I think its an important enough discussion to publish here. The main premise of the article is that the web APIs have won the “API war” in the context of Joel’s Spolsky’s “How Microsoft lost the API war” article from 2014 but the main winner is the globally domineering Google and we should subvert their victory by moving to the new runtime – the WebAssembly, that is better in every way.
Here’s what I had to say about that:
Regarding the main premise – what is missing from the offer of 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).
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 mind-share web applications are enjoying – all these are still useful in their own little niche solving that niche’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…
Hey! I just discovered this page – and realized that my comments are broken. 🙂
I like you perspective, and I agree. I guess my point would be that by flipping the wasm/browser around in the stack, we can preserve the discoverability (browsing experience) without requiring the browser to be the frontend used for all app contents.
So basically, having the browser install WASM application not under its own repository – instead allow it to deploy into the user’s (or system’s) WASM repository – which will be kind of like a .net GAC.
This would be similar to Google Chrome’s “Create Shortcut” tool (or “Add to home screen” in mobile Chrome – these are basically the same thing), but instead of having the application launcher lunch Chrome to run the web app, it can launch the WASM application directly.
That, I think would work just fine – lets start this project.