What If It Was All Web UIs?

A curious trend in software today is to expose a "Web UI" for programs running on both remote devices (such as a router) or local programs (such as Syncthing or Jupyter Notebooks). Here I explore this trend and think about both changes required for and implications of a future scenario in which all of our programs are presented like this.

By: TheHans255

10/16/2023

If you have ever set up home Internet routers in the past 10 or 20 years, you may have noticed a curious pattern. Usually, the router will have some sort of default WiFi network on it (named, say, linksys or TMOBILE or Google Mesh, often printed with the default password on the side of the router), and you'll need to connect a device of yours to that network, such as a phone or a computer. If you used a phone, you were likely required to download some kind of app, which would reach out to the router once you connected to it, guide you through some kind of setup process to change the name and password, and then give you the thumbs-up when you could finally log on and stream TV shows to your heart's content.

But if you used a desktop computer, there would often not be an app to download at all. Instead, you would open up your browser, and there would either be a special URL or IP address you would need to type instead (perhaps something like 192.168.2.1, or 10.10.10.1). And when you got there, you would be shown a webpage with all that same information, giving you a little hub to access your network and set your WiFi name and password, just as with a dedicated app. If the programmers were diligent enough, you could often go to that IP address with your phone too and get the same experience, all without downloading an app.

What you have just experienced is a "Web UI", and the concept has been growing far beyond routers. Web UIs are a favorite of Internet of Things devices, such as security cameras and temperature sensors, in order to both get data readings and configure settings (including network settings). And, curiously, Web UIs are also being deployed for entirely local programs - two applications, IPFS and Syncthing, which normally run in the background to synchronize files, both have web UIs you can access to configure file share settings and view statistics. And this even exists for programs that don't technically need it - Jupyter Notebooks, a program for interacting with educational programming resources, starts a local server and opens a page in your browser whenever you run it - since Jupyter can already be used on the web, we might as well reuse the same UI for a local experience, too.

And then there are, of course, all the powerful things we can already do on the Internet through the browser, and all the apps written in local Web frameworks such as Electron. Modern web UIs can run chat rooms with live updates, stream both movies and video games, play video games in surprisingly versatile circumstances, develop software, author documents and presentations, and much, much more. Clearly, the modern Web browser has turned into a powerful, viable platform for many kinds of modern app development.

So what might it take to go all the way? What if you were to create an operating environment where every program (except the browser, of course) you might want to run is shown to the world with a Web UI - if you want to see it, you open up a browser to reach it? If there are things that would need to change in order to make this work, what could we add or change in order to create the best user experience in such an environment?

To make a long story short, I think we're far from ready for that today, and don't think every program on the market should have to do this. However, with a small number of changes and some better infrastructure, I think this could work rather well and would be a great way to add flexibility to our day-to-day use of computers. Let's go through some of these considerations one by one and consider what traits BrowserOnlyOS, our fictional operating system, would need to succeed.

0. First, What Exactly Are We Talking About?

I realize that before we continue further, I should probably explain the nitty-gritty of how one of these local Web UIs actually works, and how we usually access it. Here, I will use Syncthing, a file synchronization program, as an example:

1. When a user downloads and installs Syncthing, it simply appears as an executable program on the user's computer. The user starts this program, either by double-clicking on it, running it in the terminal, or starting it as a background service.
2. As part of its operations, Syncthing will open up TCP port 8384, restricting it to the address 127.0.0.1. This means that if any program on the same computer, including a web browser, opens up a TCP connection to localhost:8384, Syncthing will respond to that and start communicating with that program. (Note that both of these can be changed to whatever you want - you can open up port 24601, for instance, or pick a different IP address or even 0.0.0.0 to expose the port to).
3. The user does just that - opens up their web browser and types http://localhost:8384 in the web browser. The web browser obliges, talks to Syncthing, and quickly pops up with a UI for configuring Syncthing.
4. The user interacts with this web UI to set which folders they want to sync and which other computers they want to connect to (each running their own copies of Syncthing).
5. From this point forward, Syncthing will now act on its own to keep those files in sync - whenever a file in one of the synced folders changes, Syncthing will copy that file to the other computers that the user configured it to sync with. This will still happen even if the browser window has been closed, or if Syncthing has been stopped and restarted without the user ever reopening the browser window. If the user wants to change up their synced folders or add a new computer, they can just go to http://localhost:8384 again and set that up.

Syncthing is a very natural choice for a Web UI - most of the work the program does is in the background, and the only time the user needs to interact with it is when they need to configure it. And the nice thing about making it a Web UI is that a user can install Syncthing on a device without a monitor or keyboard, such as a cloud server or a Raspberry Pi they tuck into a bookshelf, and then set it up from a different device that does have a keyboard and monitor (such as the one they use for work every day).

What we're talking about in this hypothetical future is one where every program is like this - making sure we change the ports each time, we simply replace Syncthing in the above steps with, say, your email client, or Microsoft Word(TM), or Adobe Photoshop(TM), or even a video game like Epic Games' Fortnite(TM). Obviously, the way the browser windows interact with the programs might change, with different data lifecycles and different jobs for programs when they don't have browser windows running on them, but the basic principle is the same for every program in this scenario that isn't already a browser.

I. Wait, Isn't This Just ChromeOS?

More or less, yes! ChromeOS is an operating system designed to run on cheap devices - instead of something like Windows or macOS, which have lots of programs for computers to run locally, ChromeOS pretty much only comes with Google Chrome and a basic desktop, with the expectation that the user will use the Internet for anything useful they might want to do. And in our largely Internet-connected world, this works great for most people - the most popular social networking sites, for instance, were designed for browsers, and both Google and other software developers have created ways to edit documents and collaborate on files through the browser.

The main difference between ChromeOS and this BrowserOnlyOS I'm imagining here is that the host computer would also be expected to be perfectly capable of running powerful, intensive apps on its own, just without them putting forward any of their own windows. One user of BrowserOnlyOS could run their entire office suite on their powerful, 16-core rig and connect to it locally, while another user, perhaps on a mobile phone, could connect to the office suite on a different computer, perhaps over the Internet or to that powerful 16-core rig the other user owns. Both of them do it the same way: once their favorite programs are up and running, either locally or remotely, they put the right URLs into their browsers to view them.

II. Wait, You Expect Me To Use Port Numbers Instead of, You Know, Real Program Names?

Hopefully, no!

Currently, admittedly, though, yes. Whenever you want to open a web service on your local machine, you first need to specify a port number between 1 and 65535. There are a few well known ports for extremely general apps (such as 80 for HTTP and 22 for SSH), but everything beyond that is completely arbitrary, and there's a lot less information that you can convey in a 4-5 digit number than you can in, say, a name like "Microsoft Word.exe" or "print_third_quarter_earnings_reports.sh". Not to mention that multiple programs might want to open the same ports and you might have to decide who gets what number.

However, Unix and Unix-like operating systems (and Windows, as of 2020) have an alternate mechanism that brings back the advantages of descriptive file names and permissions: the Unix socket. Instead of opening a port on localhost, programs can instead create a special kind of file called a "socket". Like any other file, that program can put the file in any directory it wants (for instance, its home directory, or a working directory), and give it any descriptive name it wants instead of resorting to a port number (for instance, syncthing instead of 8384). And then, like a port, any program that would connect to a TCP socket on the same computer can instead connect to that file, and then treat that file exactly like a TCP server/client connection until it's done. Due to this convenience, it's likely that our BrowserOnlyOS would implement Unix sockets as well, even if it were neither Windows- nor Unix-based.

Of course, sockets do have a limitation: since they are based on the filesystem rather than the network, you can't connect to them directly from a different computer. However, not only would connecting over ports continue to work just fine, it would also not be hard to forward a socket from a remote computer to either a port or a socket on a local computer or vice versa - SSH, a secure remote access program, already has tools for doing exactly this through it's -L and -R command line options.

The only real obstacle to widespread use of Unix sockets is that the URL standard doesn't yet have a good way to specify them. The standards body for URLs has not yet settled on a standard, but a few ad-hoc solutions do exist, and it would be easy for BrowserOnlyOS to choose one of them, then use the official standard when it finally is settled on.

(As an aside, running programs behind long-lived sockets also allows an interesting opportunity: instead of forcing programs to always be running behind their sockets, you could have the OS watch them with a simple proxy, and start up a program and transfer socket control to it when the socket is opened - hence, you could start up a program on your computer simply by navigating to its socket).

III. Wait, Isn't HTML/CSS/JavaScript Terrible?

Kinda, yeah. The worst parts of HTML, like the <blink> and <marquee> tags, are deprecated, though a lot of the weird parts of JavaScript, like how this behaves, still work (though "use strict" and modern linters help). There's also the huge, sprawling Wild West of packages that is NPM, and it can feel like there's a new JavaScript framework every week.

Of course, as messy as they are, they're still quite capable, and both native JavaScript and framework-based JavaScript can create rich, highly customizable UIs and applications. Even if HTML, CSS, and JavaScript aren't your cup of tea, there also two main ways of bypassing them - the <canvas> tag, which allows drawing bitmap graphics (including hardware-accelerated ones powered by WebGPU), and WebAssembly, which allows compiling applications in many languages into a sandboxed, low-level execution target. This means, in practice, that you could keep using any UI framework or language you love and it would still run on the Web - even the C/C++-based Win32, which can be seen working in this Web-emulated copy of Windows 95.

IV. Wait, Wouldn't Video Games Be Slow And Bad?

For lower-end games, not at all! Due to the <canvas> tag and WebGPU, anything with lower-end or mid-range performance requirements can run just fine in the browser. Many public game engines, including Godot and Unreal, can export directly to the Web, so any game that supports the platform can still be played the same way.

For higher-end games that need all the processing power they can get, another solution is possible: running and rendering the game off-screen, and streaming the video and audio to the browser window. The concept is exemplified in platforms like Amazon Luna, Microsoft xCloud, and the ill-fated Google Stadia, and while these platforms are rife with ethical questions about game ownership, there's not much reason why the same principle couldn't be used for a program running on the same computer as the browser.

Unfortunately, there is still some lost processing power due to two factors: the browser, with all of its extra features, is still running alongside the game; and then, instead of rendering directly to the screen, each frame has to be copied off of the graphics card back into the CPU's memory and into the browser's memory, which introduces some lag that would not be there otherwise. Effective cooperative multi-tasking can help resolve the first issue (if the game leaves enough time before V-Sync, the OS can use the rest of the time to get the frame into the browser), and it might also be possible to create an abstraction over WebRTC, a Web standard for streaming video to allow the game to stream directly to the Canvas's rendering area, thus resolving the second issue.

V. Wait, Wouldn't This Mean Google Chrome Would Run Everything?

And that, admittedly, is the biggest problem with this supposed WebUI-only future right now. As ubiquitous as the Web is today, it's impossible to deny that, as of this writing, 65% of the world's total browser share is run by Chromium, a browser engine run by Google Chrome. The second-most used browser, Safari, only has its current 20% browser market share because all browsers on iOS are just Safari, or at least WebKit, in disguise. As of 2020, Microsoft Edge, which previously ran on its own engine, switched to Chromium as well and gives it another 5% of the market share.

In order for a BrowserOnlyOS to have a remotely egalitarian future (one that isn't ruled by the single large advertising firm that Google is), there need to be multiple, healthy sources of browser competition in terms of not just outer-shell experiences (which Chromium definitely has), but also underlying engines. The next-highest browser, Firefox, represents such an engine, and I also want to call out the Ladybird Project, a project to develop an independent browser from scratch as part of SerenityOS.

VI. Wait, Does This Apply To My Files, Too?

It actually does! And I think this last bit potentially represents the coolest, most transformative part of what our hypothetical BrowserOnlyOS would represent.

This is because all of our main utility programs, including our file browser, system settings, text terminal, and honestly anything besides the web browser itself (and probably your desktop wallpaper) can be accessed behind sockets - and you can put those sockets wherever you want and put whatever programs you want behind them. If you want a nice, normal file browser, you might set up a socket like http://[localhost:/browse]/ and get a rich file browser app that you can use to move through directories, copy files, and open editors (or even just directly navigate to files!).

But there's nothing stopping you from replacing all that with a nostalgic 90s home page, complete with animated GIFs and ugly lines and a huge list of hyperlinks to all your favorite apps - apps which, due to them living behind well-named and long-lived sockets, would never need to have their links changed. You could also write a custom interface in VR using the Web XR API, or perhaps something that simply connects you quickly to all of your favorite social media apps and your creative tool suite.

Of course, you would probably want at least a built-in file browser and simple editor through a browsername://files URL (in the same vein as about://settings or chrome://inspect) so that you could still always edit your default setup if anything goes horribly wrong.

So, would our hypothetical BrowserOnlyOS be a great choice for the future of personal computing? Probably not, or at least not yet. But a lot of the pieces are there - HTML, CSS, and JavaScript are very capable platforms for building applications, and Unix sockets provide a robust solution for communicating between a browser and an underlying, high-performance application. All we would really need is a good way to access a socket from the browser, and a good selection of browser engines to choose from.

That latter problem wouldn't really be a problem for a prototype. And as for the former, it wouldn't be hard at all to just pick an ad-hoc standard and run with it. Maybe I'll come up with that prototype one day - who knows?