This blog is no longer active, you can find my new stuff at: george3d6.com, epistem.ink, ontologi.cc, and phenomenologi.cc

The universal VM we call browser

There were many attempts at standardization for the sake of running the same application code on any machine. There's clang and gcc trying to provide a common frontend for a variety of languages, standard libraries trying to abstract over machine-specific and os-specific functions, language-runtimes and fully-fledged VM's (e.g. the JVM). Not to mention the POSIX standard, Windows including a Linux VM inside and containers.

i - Dreams of universality

As far back as the 70s people might have thought that the idea of a "shared standard" for a VM or bytecode that all computers can execute would be amazing.

No more division based on environment and architecture; everyone could run the same apps.

Thousands of top engineers would have jumped at the idea of building a VM that runs on all operating systems and designing the bytecode to rule, one that most applications in the world would compile to.

So to once again prove their undying sense of humour, the gods decided that VM should follow the specs of a text-rendering engine and the bytecode should be an untyped high-level scripting language made by one bloke with no particular expertise in the area over a few caffeine-fueled nights.

Greater software theodicy scholars such as vgr, smbc and xkcd have pondered on the topic of why this happened, but my interest here is to look at how the vision of browsers and their capabilities changed over time and what are the things we can expect with high confidence over the next 10 years.

I'll quickly point out the reason why browsers became so powerful:

Competition, due to the lack of a monopoly browsers had to adhere to roughly the same standards and maintain a modicum of quality or be left behind (see IE)
Feature creep, when combined with the above and with the growth of the internet, lead to the growth in capabilities. It's impossible to remove features. It's a natural law that as a program ages it will either crumble under the weight of bugs and market demands or grow to do everything.

ii - Text rendering

The original idea of the web was surprisingly great, the kind of idea that may have been designed by an old school Unix hacker. It's premised on:

All you need to communicate is text and some multimedia; the format for this can be a simple markup language.
People should have access to the source instead of downloading a binary and be able to easily read and modify it to customize their experience and better understand the technology.

CSS came in when users cried that it looked ugly and javascript came in when programmers cried for more control.

For a while things kinda stuck to the original vision, javascript was incompatible between browsers so it was used minimally, and it was not essential for most websites.

The internet was used by tech-savvy people, which were often somewhat minimalist and signalling adverse, the kind of people who loathed paint on a turd.

I'm unsure when things changed, but I'd say it was around the 2005 to 2015 period.

iii - Javascript as compilation target

I for one always thought typed language could be great if only the types added no extra safety and the type errors were runtime rather than compile-time. I'm glad brave javascript engineers are putting in the work to make this happen. -- snarky comment on Twitter

Browsers had gained market dominance, not a single browser, but many similar browsers, shipping by default with almost every single PC, phone, laptop, tablet and sex toy.

Coinciding with this, and maybe spurred by this, people were getting bored by javascript and jquery, trying to design their own smarter, better, stronger libraries for propping up the ugly scripting language. Libraries then evolved into frameworks, frameworks then decided they are complex enough to require transpilers, transpilers mean you might as well "hack" javascript a bit more and build your own dialect of it. Transpilers grew into compilers and build files grew into static import semantics and build systems.

As far as I can tell, it took about 5 years (roughly 2010 to 2015) to go from single-file javascript to some of the most complex (and monstrous) build systems that ever existed (e.g. webpack).

These changes were not happening in a void. In the 2005 to 2015 timespan the internet went from "vaguely tech-savvy or at least odd people and kids" to "literally everyone from babies, to Amish, to old Luddites and soccer moms".

This presented a new set of challenges, openness and understandability were irrelevant, now you had issues such as users getting anxious due to lacking a load bar, targeting ads based on the trove of personal data available and making sure multimedia dopamine treadmills don't get interrupted by bad connections.

Of course, we shouldn't forget the role of internet speed getting faster, people getting more free time and people who grew up with social media getting their hands on money, and the cultural shift towards seeing voyeurism as acceptable or even virtuous.

By 2005 webpages had changed to websites, in 2015 websites had changed to webapps.

I'm still unsure why most companies opted to use highly complex setups such as angular-typescript-webpack to handle this change in use-cases. I think the standard explanation is that, while much more cumbersome and slower than plain js, they allowed for easier transitions and team scaling.

iv - Browsers as VMs

But what about more recent years? Javascript-based language/framework/library/platform mutants are maturing and coming together, and the results are predictably mediocre.

At the same time browsers are kind of accepting they are VMs and finally exposing a decent bytecode as a compilation target in form of web assembly.

So now we can actually use a bunch of awesome languages and produce fast and beautifully architectured applications that run on browsers. With some limitations, since WASM ultimately runs on the JS runtime, but JS runtimes have gotten fairly good and are quickly improving. The main thing holding js runtimes back is javascript, wasm becoming the first-class citizen will solve that issue.

Not only that, but browsers are starting to expose more APIs that allow for more complex applications. It started with things like the local store and web sockets, but nowadays we have working prototypes and specs for raw TCP and UDP connections, GPU access, and virtual file systems.

Given that web assembly is growing and extra APIs keep being added to the browser, how long will it take until we can compile arbitrary applications to wasm?

Think for a second of a future where we can open a browser and run tf/torch, starcraft, sqlite, postgres, clang, brew, wayland, R studio, a bsd or linux VM, octave, the .NET ecosystem, vim, vscode, another browser.

Trick hypotheticals, a bunch of those already happened.

v - The future

So what should we expect from browsers a few years from now?

Obviously, I don't know. But I think there are a few scenarios that seem plausible and interesting.

The "obvious" path forward is that browsers keep advancing towards the VM route and more programming tools become available for them. Frameworks like GTK and QT will become widely used in this space, HTML and CSS will become optional, with the "standard" being for the webserver to simply deliver some gzipped bytecode that's run by the browser.

The biggest change here would be custom communication protocols via TCP, this could allow for greater efficiency and avoid some of the blindspots in SSL, but it would lead to an inability by browser vendors to enforce encryption (though in practice it might be easy enough to just sniff packages going out and try to detect if any encryption is used, and if it isn't, warn the user).

It would allow for greater decentralization, as applications in of themselves could become fully-fledged platforms. Think of an application that gets downloaded through the normal protocols, but then uses TOR for all further messages, maybe even giving you the option of using your computer as a node, or a crypto client that runs in the browser, or an application that is essentially a gateway to a whole private-net of its own. It might also fuel the worrying trend of websites like facebook being synonymous with "the internet" for many people.

The web development environment would become more fractured, but the idea of js+html+css as a lingua franca is already long gone. So would this hurt in any way? It would be very good for teams that want to create a very unique product and have enough money or talent. It would be very good for developer salaries since this kind of schism is almost always positive, things become harder to accomplish, old skills become useless, new devs enter a market hungry for their ability to learn. I think it would hurt the market for "generic but not generic enough to use WordPress" applications... but I'm not sure that's necessarily a bad thing, from a consumer perspective.

Would we go as far as browsers replacing operating systems... maybe on some machines, though all projects aimed at this have had no luck thus far. That being said, every single application I have open right now, besides my terminals, runs on either electron or firefox. Is it so far-fetched for a better electron to come through and for popular Linux distros to essentially replace their GUI with it? I don't think so. Is it far-fetched to think that browsers will just have an option to run electron apps in the near future for the sake of resource efficiency? Not really. So we might get in a situation where the stack becomes something like bootloader->kernel->browser. The biggest hurdle would be increased security requirements if browsers applications can start asking for sudo permission.

If this seems far-fetched, consider the incentives an application dev has nowadays in terms of the environment they want to work with. Choosing browsers as your environment means:

Loads of community support
Almost everything is open source
Loads of job market demand
Lack of libraries (which in a popular enough environment can be a driver of interest, rather than a detractor, people can now reinvent the wheel and get famous in the process)
Easy to use APIs
Anyone can get almost instant access to your application

I'm sure there's some smart 18-year-old app dev out there that's not developing for browsers, but while not unanimous, browsers as targets are now the norm for the young generation.

Things like chrome-os kinda failed because they tried to do something that's obviously "the new thing" before people realized it. This is the case with many innovations, from palm pilot to GUIs to mouses, to myspace.

But the fact that many people are already putting resources behind browsers as OSes and failing mainly due to user interest rather than technical limitations is a good sign.

vi - Roadblocks

I think there are a few potential "roadblocks" to this future of browsers as mono-applications. I use quotes because I don't think that browsers becoming universal-VMs or a new OS spec is necessarily good... I don't think it's necessarily bad, it's just the mindless hands of Moloch shaping the world, it's a force of nature, not something any individual or organization can control. Whether it ends up as a good thing or a bad thing is a matter left to historians. But are there things that could stop it?

The most likely is a browser monopoly. The IE monopoly days didn't see the kind of progress we are now. But there's certainly a push from certain companies (Google) toward trying to "own" a lot of the internet, and it's not like they'd have to monopolize everything at once, as long as all browsers run on chromium they pretty much have full control already, they can just focus on killing Mozilla and then slowly morph chromium in such a way that all other browsers are forced to follow google's corporate interests.

Another one would be state-mandated browsers. This might sound far-fetched, but now that the US has done all the innovating there's little stopping various countries from just banning US companies and implementing their own clones. China has already done this, by "heavily encouraging its citizens" to use part-government-owned companies for everything from search, to email, to chat, to forums. TOR and VPNs can make it relatively hard to enforce any policy. Are gov mandated browsers going to be a thing? I doubt it, even China seems to have failed (or not tried) enforcing their government-owned browser, with QQ (tencent) and UC (alibaba) making up only about 20% of the market share. But it's something to keep an eye out for.

Web assembly not being further developed, or a major browser dropping support would also be fatal. This doesn't seem to be the case, with wasm standards being adopted very quickly and uniformly. But wasm is still in its infancy.

Another would be companies refusing to switch to wasm based solutions and making dev teams stick to standard frameworks like Angular and React. This seems unlikely given the interest behind language+frameworks like Google's Flutter, which would benefit a lot from compiling to wasm. Even more importantly, angular and react both encourage typescript usage, and with typescript already being compileable to wasm, you can get "language leak" via things like configuration tools and libraries, the same way Groovy, Scala, Clojure and Kotlin "sneaked into" companies with a Java-only policy and slowly started taking over.

There's of course the possibility of a grassroots movement of people realizing that spending hours engaging with multimedia in ever more alluring formats is not only making them unhappy but taking aways their very individuality, allowing algorithms to dictate their innermost desires and control their emotions. The one amazing feature of the internet, open information and the ability to safeguard information for future generations, is being taken away. So why give heed to flashy web apps instead of sticking to the less predatory and more useful "old-school" inte... I'm just pulling your leg, this won't happen, don't worry :)

vii - Preparation

Overall, I fail to see any major roadblocks in the face of this shift.

I myself am trying to learn a bit about the common wasm based stacks widely used today, and even flirting with translating an app I half-built into a rust library that will allow it to run on the browser via wasm.

It's likely to soon to learn about the capabilities of these new "VM browsers". Much like learning angular 11 years ago would have been fairly useless. But if you've got time, it can't hurt. Even if you never plan to be an app developer (I certainly don't) it's the kind of thing that could be fairly valuable when hiring app developers, and it's a way of understanding the kind of problem and constraints an app developer will have 5 years from now.

I'm roughly 50-60% confident in a 5-year future marked by multi-lingual (via compilation to wasm) browsers with code that can request hardware access mirroring that of a user without sudo privileges; A browser that's more powerful than a JVM. If anyone wants to take me up on the other side of that bet I'd be very happy to discuss some slightly more concrete metrics around it.

The one thing that I'm unsure of is how smartphones play into all of this. Android phone makers seem very happy with the idea of browser-based apps, while apple is mostly refusing to allow them on its AppStore. There's this convergence happening, where on phones/tablets more apps are using browser runtimes, while on laptops/pcs more companies are opting to deliver web apps instead of normal apps/programs.

One thing I'd also be interested to see is support for wasm outside of browsers, basically allowing it to be a normal "frontend" for common compilers. Granted, I think it's too browser-specific for this to make any sense, but the specs could be extended, and the same thing could have been said about javascript, but node did take the world by storm.

Published on: 2021-07-14

Reactions: