Story

I’ve been working on a browser-based image editor written in C++, and when I tell my friends about it, the most common reactions I get are “Huh???” and “Why???” ...Let’s break it down.

First: Wait, how does C++ run in the browser? I’m not just tossing raw C++ into a browser tab. The browser only knows how to speak 2 languages: JavaScript and WebAssembly. WebAssembly (WASM) is a bytecode language that is interpreted in the browser. The trick is to write C++ functions and compile them to WASM using Emscripten. Javascript still controls the DOM, so WASM can’t do everything - you’ll have to call the C++ functions from JavaScript.

If Javascript and WASM need to work together, they’ll need a way to communicate and transfer data! To do this, JS allocates shared buffers, writes data into it, then calls into C++ using ccall. The C++ function processes the data and returns control to JS, which can then read from the shared buffers.

C++ compilers typically mangle function names by encoding additional information—like parameter types—to support features like function overloading and prevent naming conflicts. To make C++ functions accessible from JavaScript, I used “extern C”, a directive that tells the compiler to preserve the original function names and disable name mangling.

And yes, if you mismanage memory allocation or forget to free, you can cause undefined behaviours your browser app

Second: Why go through all this trouble? Image editing—especially with real-time filters, frequent canvas updates, and support for dozens (or even hundreds) of layers—is computationally heavy. JavaScript alone may not keep up, especially when you're pushing for high performance and smooth UX.

Why? Because JavaScript is an interpreted language—it’s read and executed line by line at runtime, which adds overhead. WebAssembly, on the other hand, is a lower-level bytecode. When you compile C++ to WASM, you get the benefits of LLVM's compiler optimizations along with the portability of the web.

So even though WASM is still technically interpreted, it's much closer to machine code and runs at near-native speed. That means complex image processing operations—like applying custom filters or merging high-resolution layers—can happen fast, without freezing the browser or dropping frames. The end result? A frontend that feels like a native desktop app, but runs in your browser.

For anyone who's interested, here's the GitHub repo! https://github.com/alicehe2003/ImageEditor

This project was inspired by how Figma is built!

https://www.linkedin.com/posts/alice-he-95406b293_github-alicehe2003imageeditor-web-based-activity-7340407818077859842-r3FK?utm_source=share&utm_medium=member_desktop&rcm=ACoAAEcFpZABjEOydMovU7l8KMPjazq9tzhE9Rc