I Just Found Out My Rust Code Can Run In A Browser

(And It Changes My Whole Plan)

I was talking through a problem I’ve had for years, and an offhand comment completely reframed it for me. I want to share it, because if you write code that other people need to run, you have this same problem whether you’ve named it or not.

The problem I kept running into

I write in AutoHotkey, Rust, Python, and C++. I love all four. They’re fast, they’re capable, and they let me build genuinely useful things.

They also share one giant problem: somebody has to install an exe.

Have you ever built something great, handed it to someone, and watched it die right there? I have. Over and over. Here’s what actually happens:

• Their work computer is locked down and IT says no
• Antivirus flags it because it’s an unsigned exe from a guy on the internet
• They get the “unknown publisher” warning and nope right out
• They’re on a Mac, and my AutoHotkey script may as well be written in Latin
• They just plain don’t want to run a random exe, which honestly is fair

Notice something about that list? Almost none of it is about my code. It’s all distribution. The tool works fine. It just never gets to run.

So I looked at Progressive Web Apps

A Progressive Web App (PWA) is just a web page built so it can be installed like an app. You open a URL. If you want, you add it to your home screen or dock and it gets its own icon. It works offline. There’s no installer, no admin rights, no antivirus warning.

Great. Problem solved, right? Except I had a real hesitation, and maybe you’re already thinking it too: that means writing everything in JavaScript and giving up the languages I’m actually good at.

That’s where I was wrong.

WebAssembly, or WASM

I’d genuinely never heard of this until recently, so if it’s new to you, you’re in good company.

Browsers run JavaScript. About ten years ago they quietly added a second thing they can run: a compact binary format called WebAssembly, or WASM for short. Rust, C, C++, Go, and a bunch of other languages can compile to it.

Here’s the analogy that made it click for me. Think of a shipping container. It doesn’t matter whether you’re shipping bananas or bolts. You load it into the standard container, and every port in the world knows how to unload it, because the container is the standard, not the contents.

WASM is that container. I compile my Rust into it, and every modern browser knows how to run it. It doesn’t care that it started life as Rust.

So the thing I thought was a tradeoff isn’t one. A PWA isn’t me abandoning my stack. It’s a new place to ship my stack to. ⚡

Is it actually fast, though?

This was my next question, and I want to give you the honest answer rather than the hype version.

WASM is typically somewhere between 1.1 and 2 times slower than the same code compiled natively. Not the same. Slower. Anyone who tells you it’s identical to native is overselling it.

But that’s the wrong comparison, because native Rust can’t run in a browser tab at all. The real comparison is against JavaScript, which is the alternative for that job. And there, WASM is usually several times faster for heavy work.

So I keep most of my speed and I gain the ability to reach people I could never reach before. I’ll take that trade every day.

Real tools that already run this way

This isn’t theoretical. A lot of serious software has already been compiled to WASM, and you can just use it:

• SQLite, so you can open a real database file in a tab
• ffmpeg, for converting and trimming video
• DuckDB, for running SQL over millions of rows
• Tesseract, for OCR
• Python itself, through a project called Pyodide
• Whisper, for speech to text, running entirely on your own machine
• Doom. Obviously Doom. It’s always Doom.

What we can build, and what we honestly can’t

This is the part I want to be straight about, because it’s where I see people get excited and then hit a wall.

WASM makes code fast. It does not make the browser tab powerful. Everything still runs in the browser’s sandbox. There’s one rule that decides everything:

Look at that right-hand column and you’ll notice something: that’s basically the list of things AutoHotkey is best at. Hotkeys, running in the tray, poking at other windows. So this isn’t AutoHotkey in a browser, and it never will be. Anyone promising you that is selling something.

It’s a different tool for a different job. AutoHotkey still owns my desktop. This is for reaching everybody else.

One catch worth knowing about

WASM itself runs everywhere. Windows, Mac, Linux, iPhone, Android, every modern browser. No exceptions worth worrying about.

But the ability to pick a whole folder and write files back to it is Chrome and Edge only. Not Safari, not Firefox, not on an iPhone. It does work on a Mac or on Linux, as long as they’re in Chrome or Edge.

Don’t get me wrong, that’s a real limitation. But compare it to what I have today: “you must be able to install an exe on Windows.” Going from that to “you need Chrome or Edge” is a massive upgrade in who I can reach. And locked-down corporate machines almost always have one of those two.

The part that surprised me most

I went into this thinking “no install” was a convenience thing. Nice to have. Saves a few clicks.

It turns out it’s bigger than that. Think about an analyst at a bank or a hospital who needs to open a 2GB file. They can expense a fifty dollar tool on a company card without blinking. What they cannot do is get an exe through an IT security review. That takes months, if it happens at all.

So a tool that runs in their browser isn’t competing on features. It’s the only option that’s actually available to them.

Same story for school Chromebooks, library computers, contractors on a client’s laptop, and anyone on a Mac who I’ve never been able to help at all. That’s a lot of people I’ve been writing off without really thinking about it.

What I’m doing next

I’ve got the toolchain installed and I’m starting small on purpose. First up is a boring little test: point it at a folder, hash every file in Rust compiled to WASM, find the duplicates, and time it against a JavaScript version doing the same thing.

Not glamorous. But it answers the questions that matter before I sink real time in: does the toolchain work, is the speed genuinely there on normal hardware, and does the folder permission prompt feel okay to a regular person or does it scare them off?

If that goes well, a handful of small single-purpose tools follow. One job each, done well. I’d rather ship five tiny things that work than one big suite that half works.

One thing I’ve learned over the years: the fastest way to kill a good idea is to plan it for six months instead of testing it in an afternoon. Life is an experiment. Try it, measure it, and let the results tell you whether to keep going.

How about you?

Have you ever built something useful and then watched it go nowhere because the other person couldn’t install it? Or been on the other side of it, stuck on a locked-down machine wanting a tool you weren’t allowed to have?

I’d genuinely like to hear about it. What tool would you want if the install problem just went away? Tell me and it might end up on my build list.

Now on with the show.

P.S. If you take one thing from this: the languages you already know are probably worth more than you think. I assumed reaching browser users meant starting over. It didn’t. It meant learning one new way to package what I’d already built. That’s a much smaller hill to climb, and it’s the kind of thing worth checking before you talk yourself out of something.