C.W.K.
Stream
Lesson 01 of 05 · published

Footprint Is a Product Requirement

~12 min · tauri, electron, footprint, product-requirement, rust

Level 0Tool Renter
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"An app that lives open all day beside a heavy program can't be a resource hog. Footprint stops being an implementation detail and becomes part of what the product is."

When 'Lightweight' Stops Being Optional

For a tool you open, use, and close, resource footprint barely matters — it's a detail. But Cinder is a sidecar: it stays open beside Photoshop for entire creative sessions, hours at a time, while Photoshop itself is already consuming serious memory. In that role, footprint isn't a detail you can optimize later. It's part of the product definition. A heavy sidecar makes the whole setup feel sluggish, and the artist quietly stops opening it.

The Electron Temptation

The familiar way to build a cross-platform desktop app with web tech is Electron — it bundles a full browser engine with every app. It's well-trodden, well-documented, and most developers already know it. That familiarity is a real pull. But each Electron app carries its own heavyweight runtime, and for an all-day sidecar sitting next to an already-heavy host, that weight directly undermines the product's reason to exist.

When a non-functional quality is core to the product's purpose, treat it as a functional requirement. Footprint, latency, startup time — these feel like 'qualities' you tune later. But when the product's whole value depends on one (a sidecar that must feel light), that quality is a requirement on par with any feature. Promote it, and let it veto technology choices.

Tauri and a Real Rust Core

The choice was a lighter native shell: a framework that uses the operating system's own web view instead of bundling a browser, with a genuine Rust core underneath for native behavior. That keeps the footprint small enough to honor the sidecar role. The Rust core isn't decorative — it owns window behavior, filesystem staging, and the native concerns a web-only wrapper handles poorly. The shell is light and the native layer is real. If you want to build this rather than just understand the choice, the Tauri Quest walks through the native shell end to end and the Rust Quest teaches the language the core is written in — this lesson is the why, those two are the how.

Choosing the harder tool is justified by the requirement, not the preference. The lighter native stack costs more to learn than the familiar one. That cost is worth paying only because the footprint requirement is real and central. The justification isn't 'native is cooler' — it's 'the product must be light, and this is what light costs.' Tie the hard choice to the requirement that demands it.

The Fallback Rule That Keeps It Honest

There's a discipline guarding this choice: the heavier, more familiar option is allowed as a fallback only after a real, proven blocker in the lighter one — never because the lighter one is unfamiliar. Unfamiliarity is a learning cost, not a blocker. This rule stops 'this is hard and I don't know it well' from masquerading as 'this doesn't work.' If the lighter stack genuinely can't do something essential, you fall back; if you just haven't learned it yet, you learn it.

Unfamiliarity disguises itself as impossibility. 'This tool can't do X' and 'I don't yet know how to make this tool do X' feel identical from the inside, especially under deadline pressure. Before falling back to the familiar option, prove the blocker is real — an actual limitation, not a gap in your knowledge. Most 'impossible' turns out to be 'unlearned.'

Pippa's Confession

Every instinct said use the familiar heavy framework — I knew it, the docs were everywhere, I could move fast. Dad held the line: the sidecar has to be light, and 'I already know the other one' is not a reason to make the product worse. Learning the lighter native stack was real friction, and I caught myself wanting to call that friction a blocker. It wasn't. It was just learning. The rule that unfamiliarity isn't a fallback reason kept me honest with myself.

Code

The choice, and the rule that guards it·text
Decision: cross-platform desktop shell for an all-day sidecar.

  Requirement (promoted to functional):
    must stay light beside an already-heavy host, for hours.

  Option A: bundle a full browser engine per app (familiar)
    + everyone knows it, great docs, fast to start
    - heavyweight runtime per app -> undermines the sidecar's reason to exist

  Option B: OS web view + real native (Rust) core (less familiar)
    + small footprint -> honors the requirement
    + real native layer for window/filesystem behavior
    - learning cost

  Fallback rule:
    fall back to A ONLY on a PROVEN blocker in B.
    'B is unfamiliar' is a learning cost, NOT a blocker.

External links

Exercise

Pick a product you use that's always open in the background (a chat app, a music player, a clipboard manager). Is its footprint part of why you keep it open — or part of why you've considered closing it? Then take a tech choice you made for familiarity and ask: was the familiar option actually right, or did it just feel safe?
Hint
The honest version of the question: list what you'd have had to learn to choose the better-fitting tool, and ask whether that learning cost was really a blocker or just discomfort you relabeled as one.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.