What Building a Drawing App Taught Me About Performance
Performance issues don’t show up immediately, they build up quietly until your assumptions stop working.
What It Takes to Build a Canvas App
10 parts, in reading order.
- Part 1
- Part 2
Inside the Rendering Engine of a Canvas App
Rendering isn’t just about drawing shapes. It’s about controlling how much work happens per frame.
- Part 3
Why Freehand Drawing Becomes a Bottleneck
Freehand input looks simple, but the amount of data it generates can quickly overwhelm your rendering system.
- Part 4
Real-Time Collaboration Is Not Just Sending Updates
Two people editing the same canvas is not a networking problem. It's an agreement problem.
- Part 5
Writing a Binary WebSocket Protocol by Hand
What actually goes over the wire in a collaborative canvas, and why the ready made library didn't fit.
- Part 6
Cursors Are Not Part of the Document
Presence looks like the easiest feature in a collaborative app. It has the tightest constraints of anything in the system.
- Part 7
What Happens When One Client Can't Keep Up
Every broadcast loop contains an assumption that send() works. Backpressure is what you build when it doesn't.
- Part 8
The Server Forgets Everything and That's Fine
Rooms live in memory and get thrown away. The client is the persistence layer, which changes what reconnecting means.
- Part 9
Undo Is a Stack of Your Own Mistakes
Ctrl+Z is trivial in a single user app. Add one collaborator and the obvious implementation starts erasing other people's work.
- Part 10
Ten Posts Later: What I'd Do Differently
Looking back at a collaborative canvas app, the decisions that held up, the ones that didn't, and what's still broken.