Yesterday, I was asked to troubleshoot a computer that was having trouble displaying an image in the preview pane. At first, I thought the issue might be due to a missing “.JPG” extension, but as I investigated further, I found the problem was much deeper. The Start button was unresponsive, the search box wouldn’t accept input, and restarting Explorer didn’t help. Virus scans from the command line revealed nothing, and the system settings were missing entirely.

I tried rolling back to restore points, but the most recent one revealed a corrupted drive, and even after repairs and multiple restore attempts, the problem persisted. A system recovery that reinstalled the OS while keeping the files also failed. In the end, I had to fully restore the drive, wiping everything not backed up on the network. The process took two days, and it was frustrating not only because of the time lost but also knowing that some data was likely gone for good.

Future Operating Systems

In the near future, people may no longer need traditional computers to store and process information as we do today. Many previously standalone software programs, like email, news readers, desktop publishing, graphic design, and 3D modeling, are now available as free online services. As a programmer, I see how web browsers have evolved to offer standardized APIs that tap into a computer’s 3D graphics card, audio generation, microphone, webcam, GPS coordinates, storage options, peer-to-peer communication, and more.

We’re reaching a point where the primary function of a computer is to run a web browser. Many companies now store user profiles, downloads, documents, and desktop files on networked drives, making data recovery as simple as logging into another device. Once traditional computers are no longer necessary, concerns over system infections may fade away, as users could just switch devices and retain access to all their files without disruption.

Limitations

The primary limitations we face today stem from the constraints of browser APIs. While there is little a computer can do that a web browser cannot, browsers operate in sandboxed environments with strict security measures to protect the underlying system.

One major limitation is the lack of comprehensive USB support. While the experimental WebUSB API provides some access to USB devices, many device communication protocols are undocumented and often considered proprietary by manufacturers. This forces developers to reverse-engineer these protocols to make devices work with browsers. Another challenge is facilitating data transfers between browsers on different devices without relying on an internet account, by using technologies like Bluetooth, NFC, or WiFi. Typically, this requires a server to mediate the connection. For example, while AirDrop lets me select a device to transfer a photo from my phone to my computer and then upload it in a browser, web browsers alone cannot yet handle direct transfers like this. The Bluetooth API is still in development and doesn’t allow browsers to broadcast themselves as Bluetooth devices, while Web NFC only supports one-way communication. WebRTC could enable WiFi-based communication, but it still needs a server to initiate the connection between devices.

There are also unconventional ways to achieve device communication, such as using the webcam, Canvas API, and Barcode Detection API to read QR codes generated by each device, or using the Web Audio API with oscillators and audio analyzers for audio-based data transfer. However, these methods are slow and involve complex techniques like multifrequency phase keys, error correction, and interleaving. Even in quiet environments, noise can interfere, requiring error detection and packet retransmission to ensure reliable communication.

While not strictly a limitation, the file system is a significant factor in the challenges of relying solely on web browsers. When downloading or uploading files, browsers interact with the local file system. To enhance security, we might see a shift towards cloud storage as the default location for file storage and uploads. While local storage could still be an option, making cloud storage the default would simplify recovery from system issues.

Seeing the Future

In the mid-90s, I first encountered HTML as a basic tool for placing images on web pages. I was accustomed to more structured languages like PILOT and LOGO, which I used to draw shapes with precise instructions. HTML seemed like a simple way to tell a browser where to position images using a single line of text.

Before CSS, I mistakenly believed HTML was a visual design language. It’s actually a language for organizing content. My prior experience with programming languages, which focused on basic UI elements like dragging and dropping images, led me to this misunderstanding. Older text-based languages often required detailed geometric instructions.

PNGs, with their support for transparency, were still in their early stages. Internet Explorer, during the browser wars, offered limited support for PNG transparency, forcing developers to load them as objects instead of standard images.

<object data="image.png" type="image/png">
  <img src="fallback.gif" alt="Fallback Image">
</object>

PNG support gradually improved over time. GIFs, though they had transparency, were limited to either fully transparent or opaque pixels and a 256-color palette. While I enjoyed animated GIFs, their transparency and color restrictions were frustrating. I often wanted smooth rounded corners and ended up creating black and white images with smooth edges. I would programmatically manipulate the palette afterwards to transition between any two colors I desired.

Early JavaScript was limited in its capabilities. As browsers allowed both JavaScript and VB Script to interact with the Document Object Model (DOM), developers began to replicate common operating system dialog controls. This trend was further fueled by the brief appearance of Scriptlets, which resembled Active X controls and Java Applets. I spent time developing custom color pickers and other user interface elements.

I found the source code for these controls and shared them on my personal GitHub account, Lewies-Code-Library-PSC. I used to post code to Planet Source Code (PSC). These projects are outdated and were created during a time when web browsers lacked many of today’s standard input controls (like <input type="number" />).

At this point, I envisioned a future where web browsers would replace traditional operating systems. I imagined computers booting directly into a browser instead of a standalone OS.

Google Chrome

Around 10 years ago, Google introduced its Chromium operating system, which was essentially a web browser-based OS. Google Chromebooks initially struggled to gain popularity despite their low cost. I purchased one and found it challenging to develop applications on it at the time. I recall learning Dart for this purpose. Unfortunately, I lost the laptop during a late-night drive from Virginia to Florida after receiving news about my mother. Today, Chromebooks are ubiquitous in schools.

While Chromebooks can be helpful for kids’ needs, I find them limiting for development and device connectivity. Others have attempted to create their own web-based operating systems, but they often fall short of Chromebooks. These alternatives lack the wide range of applications, libraries, installers, and file sharing options available on Chromebooks. They often seem like experimental projects.

Chromebooks, backed by a major tech company like Alphabet (aka Google), which also owns the Chrome web browser, are likely the first to successfully compete with traditional operating systems. Google also owns the Android Operating System, which shares some of the same challenges but has advantages like Bluetooth, NFC, and direct Wi-Fi communication between devices.

The Path Forward

If web browsers widely adopt Bluetooth, USB, device discovery, peer-to-peer communication, and cloud storage as the default option, the demand for personal computers could decrease. This is especially true if vendors publish more communication specifications for their devices. Even if a system is compromised, the low cost of replacing the device and the ease of setting up accounts on a new one would make the inconvenience minimal.

Concerns

One potential issue is vendor lock-in. Personally, I tend to stick with the same web browser for years until something significantly better or more popular comes along. However, it seems like every browser vendor now wants users to log into their platform to use the browser. I could easily see Google pushing users to rely solely on Google Drive for file storage, Microsoft doing the same with OneDrive, and Dropbox competing for a share. To avoid this, there will need to be efforts to ensure compatibility across multiple services.

Ideally, I’d like a browser that lets me log into multiple accounts and services, allowing me to choose which service or account I want to use for loading or saving files. Being able to select from different profiles across various services is important to me, especially since I work with clients who have different preferences for the services they use. Having the flexibility to access any of those services in a single browser makes it easier to stick with software I’m comfortable with. In general, I prefer to separate the services from the browser itself.

Privacy is also a concern, particularly if logging into the vendor’s account becomes a requirement to use the browser. While there are already many regulations around privacy and data sharing, this adds another layer of complexity.