HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
alicehe2003
ImageEditor
JavaScript2025–2025
alicehe2003 / ImageEditor

ImageEditor

Web based video editor using JavaScript, C++, and WebAssembly.

2Distinct people
3Mentions
0Explicit recommenders
6GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Web based video editor using JavaScript, C++, and WebAssembly.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by 6-hour interval3 dated mentions

Observed mentions: 2025-06-17 00:32:52 UTC to 2025-06-24 01:19:42 UTC.

0122025-06-17 00:00:00 UTC to 2025-06-17 06:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsJun 17, 00:002025-06-17 06:00:00 UTC to 2025-06-17 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-17 12:00:00 UTC to 2025-06-17 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-17 18:00:00 UTC to 2025-06-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-18 00:00:00 UTC to 2025-06-18 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-18 06:00:00 UTC to 2025-06-18 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-18 12:00:00 UTC to 2025-06-18 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-18 18:00:00 UTC to 2025-06-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-19 00:00:00 UTC to 2025-06-19 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-19 06:00:00 UTC to 2025-06-19 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-19 12:00:00 UTC to 2025-06-19 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-19 18:00:00 UTC to 2025-06-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-20 00:00:00 UTC to 2025-06-20 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-20 06:00:00 UTC to 2025-06-20 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-20 12:00:00 UTC to 2025-06-20 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 20, 12:002025-06-20 18:00:00 UTC to 2025-06-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-21 00:00:00 UTC to 2025-06-21 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-21 06:00:00 UTC to 2025-06-21 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-21 12:00:00 UTC to 2025-06-21 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-21 18:00:00 UTC to 2025-06-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-22 00:00:00 UTC to 2025-06-22 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-22 06:00:00 UTC to 2025-06-22 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-22 12:00:00 UTC to 2025-06-22 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-22 18:00:00 UTC to 2025-06-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-23 00:00:00 UTC to 2025-06-23 06:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-23 06:00:00 UTC to 2025-06-23 12:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-23 12:00:00 UTC to 2025-06-23 18:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-23 18:00:00 UTC to 2025-06-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-24 00:00:00 UTC to 2025-06-24 06:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJun 24, 00:00

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jun 17, 00:002025-06-17 00:00:00 UTC2025-06-17 06:00:00 UTC211
Jun 17, 06:002025-06-17 06:00:00 UTC2025-06-17 12:00:00 UTC000
Jun 17, 12:002025-06-17 12:00:00 UTC2025-06-17 18:00:00 UTC000
Jun 17, 18:002025-06-17 18:00:00 UTC2025-06-18 00:00:00 UTC000
Jun 18, 00:002025-06-18 00:00:00 UTC2025-06-18 06:00:00 UTC000
Jun 18, 06:002025-06-18 06:00:00 UTC2025-06-18 12:00:00 UTC000
Jun 18, 12:002025-06-18 12:00:00 UTC2025-06-18 18:00:00 UTC000
Jun 18, 18:002025-06-18 18:00:00 UTC2025-06-19 00:00:00 UTC000
Jun 19, 00:002025-06-19 00:00:00 UTC2025-06-19 06:00:00 UTC000
Jun 19, 06:002025-06-19 06:00:00 UTC2025-06-19 12:00:00 UTC000
Jun 19, 12:002025-06-19 12:00:00 UTC2025-06-19 18:00:00 UTC000
Jun 19, 18:002025-06-19 18:00:00 UTC2025-06-20 00:00:00 UTC000
Jun 20, 00:002025-06-20 00:00:00 UTC2025-06-20 06:00:00 UTC000
Jun 20, 06:002025-06-20 06:00:00 UTC2025-06-20 12:00:00 UTC000
Jun 20, 12:002025-06-20 12:00:00 UTC2025-06-20 18:00:00 UTC000
Jun 20, 18:002025-06-20 18:00:00 UTC2025-06-21 00:00:00 UTC000
Jun 21, 00:002025-06-21 00:00:00 UTC2025-06-21 06:00:00 UTC000
Jun 21, 06:002025-06-21 06:00:00 UTC2025-06-21 12:00:00 UTC000
Jun 21, 12:002025-06-21 12:00:00 UTC2025-06-21 18:00:00 UTC000
Jun 21, 18:002025-06-21 18:00:00 UTC2025-06-22 00:00:00 UTC000
Jun 22, 00:002025-06-22 00:00:00 UTC2025-06-22 06:00:00 UTC000
Jun 22, 06:002025-06-22 06:00:00 UTC2025-06-22 12:00:00 UTC000
Jun 22, 12:002025-06-22 12:00:00 UTC2025-06-22 18:00:00 UTC000
Jun 22, 18:002025-06-22 18:00:00 UTC2025-06-23 00:00:00 UTC000
Jun 23, 00:002025-06-23 00:00:00 UTC2025-06-23 06:00:00 UTC000
Jun 23, 06:002025-06-23 06:00:00 UTC2025-06-23 12:00:00 UTC000
Jun 23, 12:002025-06-23 12:00:00 UTC2025-06-23 18:00:00 UTC000
Jun 23, 18:002025-06-23 18:00:00 UTC2025-06-24 00:00:00 UTC000
Jun 24, 00:002025-06-24 00:00:00 UTC2025-06-24 06:00:00 UTC101

What Hacker News says

3 sources
This summer, I set out to write a web-based image editor in C++ using WASM. (You can read more about it in my last post!) One of the biggest performance bottlenecks? Merging layers. The intuitive algorithm: process the final image layer by layer, iterating through each pixel position (x,y). My friend proposed an alternative algorithm, that in theory sounded much better… A tempting alternative (that didn’t work): process the final image pixel by pixel, evaluating all layers at once. This approach initially seemed like a great idea - in the worst case, both of these algorithms process every single pixel in every single layer. In the average case, the second algorithm can skip over entire regions of pixels on lower layers. But in practice, the performance was worse. When I was iterating layer by layer, there was no significant processing tim
Read the rest
e that was noticeable by the human eye. Using the pixel by pixel algorithm, the image took more than 30 seconds to appear. Same worst-case time complexity, but way worse performance in practice. Why? CPU cache misses. The first method processes entire layers at a time. This means that it uses sequential memory access, leading to more cache hits, and so an overall better runtime. The second method jumps between layers for each pixel. This causes random memory access, creating more cache misses, and so a significant delay to access data. What I learned In theory, both layer-wise and pixel-wise merging have the same worst-case complexity. But in practice, memory access patterns make all the difference. By aligning your algorithm with how the CPU cache works—favouring sequential over random access—you can unlock massive speedups. Sometimes, the "intuitive" way just fits the hardware better. https://github.com/alicehe2003/ImageEditor
In [dead]

What does it mean to use C++ in the front end?

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 pro
Read the rest
cesses 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-we…
14 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.