astronauta.dev logo astronauta.dev

We should do more with our browsers.

Aug 23, 2025 8 min read


I want to start this entry by stating two facts that could’ve biased me toward this position, but I still think the point stands:

I’m a millennial

My first real computer time was in a browser playing Flash games for hours. The family computer[1] didn’t have the hardware or the software to run most desktop games. The browser didn’t care. You opened a tab and, depending on your internet speed, you had instant access to thousands of games. Any genre. Any quality.

That made me want to build one myself. I learned ActionScript 2 and contributed to the pollution of shitty Flash games from that era.

We moved past Flash not too long ago. It had too many flaws encrusted in it, growing like a tumour, and dropping it was for the best. But it’s what ultimately kicked off my interest in web dev, which is what I do today.

Flash games

I’m a web developer

When you have a hammer, everything looks like a nail, and I see a lot of problems as browser-shaped. I’m not the only one with this bias. Most companies are moving from building native apps for the popular operating systems to full software suites that are browser only and online only.

There’s an argument to be made about why, and it’s mostly about control. In a browser they don’t have to deal (or deal much less) with licenses, cracking, updates, drivers, code signing, and a long list of native app headaches. It’s also the perfect cover to ship subscription only services instead of releasing a desktop app with a lifetime license.

Not everything is bad

The other side of the coin is that software built for the browser can be developed more cleanly. There’s only one target[2]. You can leverage the big, very mature web ecosystem of UI libraries and app tooling[3].

You don’t have to worry about library compatibility across different systems, or each OS’s weird way of handling the filesystem, or most of the host OS implementation details at all.

In addition to that, browsers have come a long way to support more “low-level” features that, while still experimental in places, open the door for new types of web applications.

Here’s the list of web technologies that I personally find useful and when/if it is supported across Chrome, Firefox and Safari, and a column if it is “universally” supported (all 3 support it):

TechnologyChromeFirefoxSafariUniversal Support
WebAssembly201720172017
Service Workers API201520162018
Cache Storage API201520152018
WebCodecs API202120242025
WebRTC201220132017
BroadcastChannel API201620152019
OPFS (Origin Private File System)202020232021
WebGPU API20232025🟡 [4]🟡
File Handling API2022🟡🟡🟡
Background Sync API2016
App Shortcuts (manifest shortcuts)2020
WebUSB API2017
Web Serial API2021
Web Bluetooth API2018

Now, this looks like a counter-point to my own argument, considering that almost half of the table is not universally supported, but if we look at the browser market share:

Desktop Browser Market Share

Worldwide · July 2025
StatCounter · Desktop · Worldwide · Jul 2025
Similarweb · Desktop · Worldwide · Jul 2025

We can see that >80% of the market is dominated by Chromium-based browsers.

Taking advantage of that

Yes, having a monopoly on internet browsers is a bad thing. It has happened at least twice in the past. But browsers are such an intricate and overly complex piece of software that, in my opinion, this behaviour is inherent to how we interact with the internet, and it’s bound to happen again if somehow Chromium loses its lead[5].

But if instead we use that to our advantage, there’s already a universal deployment target that is very capable of providing functionalities we still associate exclusively with native applications.

Real world examples

There are multiple real world examples that I’ve personally used. It’s refreshing to just open a web page and do things with your devices without installing anything.

QKM and VIA

QMK and VIA logos

Taking a quote from keeb.io:

QMK is “an open-source keyboard firmware … QMK also encompasses a suite of other tools, such as QMK Configurator and QMK Toolbox.

QMK Firmware has lots of features, like supporting multiple layers, macros, Mod-Tap, mouse keys, split keyboards, backlighting, RGB, etc., which makes it a popular choice for hobbyists.

And VIA is:

a feature in QMK that lets you change your keymap on your keyboard without needing to reflash firmware.

Now, instead of using a desktop application that interfaces with USB, VIA offers a web application that makes use of the WebHID browser API to talk to the keyboard, making it possible to configure it without downloading extra software.

This behaviour is, from my point of view, the future of application distribution, eliminating much of the pain of regular desktop applications.

Imagine a (hopefully not distant) future where you can also configure all of your peripherals through a web interface, anywhere, without having to install anything.

ESP Web Tools for Home Assistant

ESP-home logo

Home Assistant is an open source home automation platform that allows you to have smart devices, automations, and dashboards, all running locally. Focused on privacy and self hosting, and extensible through integrations and plugins.

There is a plugin called ESPHome that lets you build your own devices using ESP32 or ESP8266 boards. Useful if you want to save money, build something very specific that isn’t commercially available, or both.

ESP Web Tools is a browser-based toolkit for managing those ESP devices. It lets you install and update firmware, connect devices to Wi-Fi, open each device’s web interface, view logs, send terminal commands, and add them to Home Assistant. All through the browser.

And there’s no need to stop there: there could be a platform to share programs for your microcontroller boards and test them directly from the browser.

Or a browser-first microcontroller IDE.

Online Serial Monitor

This is an Online Serial Monitor, pretty much self explanatory, and not the only one. I’ve used it plenty of times.

There’s almost no excuse for management software for a device communicating through a serial interface not to have its own web management application.

Photopea

Photopea logo

Photopea is an online image / vector / RAW editor. I’ve used it multiple times and it is just good enough for almost anything. I prefer it to Photoshop since I’m really against subscription services, and it runs entirely in the browser.

Onshape

Onshape logo

Onshape is full parametric CAD in the browser. Sketches, parts, assemblies, drawings, no installer. You sign in, model your thing, and export the results for manufacturing or 3D printing. It handles versioning, branching, and realtime collaboration by default because everything lives in the cloud session. Performance is great for serious work because the heavy lifting isn’t on your PC.

What this proves: complex tools don’t need native installers to be useful. If CAD can live in a tab, so can more editors and eventually 3D slicers using WebAssembly/WebGPU.

Conclusion

The browser is already a capable runtime, for most workflows there is no need of installers, drivers, or admin rights. We can use native only when the job truly demands deep OS hooks, hard realtime, or huge local datasets. Everything else can live in a browser tab.

If CAD, firmware flashing, and RAW photo editing can live in the browser, more apps probably can too.

Ship links.

Kill installers.


  1. This should be an article on its own, I dont think the concept of a "Family Computer" still exists today. Owning one was so expensive that there was only one for the whole family, today each member can have multiple computers ↩︎

  2. Ideally, there are still inconsistencies in behaviours and API support between major browsers, but for better or for worse, there is only Chrome based and Safari. ↩︎

  3. Dating back to Gmail, that in 2004 popularized “AJAX” heavy XHR + JS in a single-page app. ↩︎

  4. It's coming soon ↩︎

  5. Does it count as monopoly if the underlying browser is open source? ↩︎