DEV Community: yyzTools

v1.1.0: Mouse Gestures, a One-Click Desktop Tidy-Up, and Your Own LLM for Translation

yyzTools — Sun, 04 Oct 2026 08:34:25 +0000

Release notes for yyzTools v1.1.0.2000 (Sep 25, 2026), plus the design argument behind the headline feature: the command palette owns the keyboard — mouse gestures give the mouse the same deal. One trigger, one grammar.

Five days after 1.0.9 shipped space-bar file preview, v1.1.0.2000 is out. The headline is mouse gestures; the quieter updates (custom LLM translation, a one-click desktop organizer, OCR quality-of-life) are the ones I suspect daily users will feel most. Full list first, then the design argument.

What's new in 1.1.0.2000

Mouse gestures — hold the trigger button, draw a stroke, an action runs: simulated hotkeys, window control (minimize/maximize/close), volume, launch an app, switch tasks, web search. On by default, off in Settings → Mouse Gestures.
Dock: one-click desktop organize — the dock gained a button that sweeps scattered desktop icons into dock categories.
Custom LLM translation engine — Settings → Translate → Translation engine → Custom LLM. Point the translator at any OpenAI-compatible endpoint: your own key, your own host, your own model.
Quick OCR & Screenshot: regular hotkeys — they now behave like first-class system features instead of palette-only actions.
Quick OCR: partial text copy — select and copy just the lines you need from recognized text; the window can be dragged from any blank area.
OCR & Quick OCR: "merge sentences" — an option that joins fragmented recognition output back into readable lines.
Dock: drag items across categories — plus popup polish.
Lightning System Optimizer: rule-handling refinements.
App usage stats: fixed incorrect LockApp.exe durations after sleep/hibernate.

The design argument: the mouse needed its own keyboard shortcuts

The command palette in yyzTools has one rule: a single hotkey (Alt+Space) plus a grammar (type f for files, c for clipboard, p for processes...). Users remember one trigger and a vocabulary, not forty hotkeys.

Keyboards got that deal. The mouse never did — the mouse's "shortcuts" are pixel targets in corners (close, minimize, the taskbar's far end), each one a small aiming exercise.

Gestures give the mouse the same structure: hold one trigger, draw one stroke. Direction is the grammar. ↓ is minimize for me, ←→ is task switch, and the stroke takes less time than moving the cursor to a title-bar button. The action set (hotkeys, windows, volume, apps, tasks, search) deliberately mirrors the palette's — anything the keyboard grammar can express, the mouse grammar can too.

Two policy choices worth stating:

On by default, one-click off. A feature that intercepts mouse buttons must be trivially removable. If you live in middle-click-drag apps (Blender, CAD), Settings → Mouse Gestures is one toggle away.
Strokes over letters. Straight-line strokes (up/down/left/right and combos) — not drawn characters. Strokes survive sloppy input; letter recognition punishes exactly the hurried users who want the feature.

Why custom LLM translation is a privacy feature, not an AI feature

The translator has always been the one part of yyzTools that must touch the network — translating text means asking someone who knows both languages. Until now, that someone was a fixed public service.

Now it's whoever you say: any OpenAI-compatible endpoint. A local model behind Ollama or LM Studio, a corporate gateway, a provider you've actually read the privacy policy of. The request goes where you point it, which turns "where does my selected text go?" from a trust question into a configuration question.

For an otherwise local-first suite, that's the right shape for AI features: the capability is welcome, the endpoint must be yours.

The desktop organizer: the desktop is a surface, not a landfill

One-click organize exists because desktops accumulate: screenshots, downloads, that one folder you keep meaning to sort. The dock can now sweep icons into its categories in one pass — files into a files category, shortcuts into their apps — leaving the desktop usable as, well, a desktop.

It pairs oddly well with the gestures release. Between "draw a stroke to minimize everything" and "one click to tidy the desktop," v1.1.0 is quietly the release about surfaces: less digging through piles, more staying where you are.

As always: free, no account, no telemetry; network calls belong to features that inherently need one, and translation now goes to the endpoint you choose. Windows 10/11, 12 languages, 387 command modules. Setup 175 MB, portable 166.8 MB, incremental updates after that. yyztools.com.

What would you bind to a stroke? I'm collecting bindings worth shipping as examples — drop yours in the comments.

Space-Bar File Preview Everywhere: Borrowing macOS Quick Look's Best Trick for Windows

yyzTools — Sat, 03 Oct 2026 15:44:26 +0000

I build yyzTools — a free, local-first Windows toolkit that folds 40+ tools into one installer. The 1.0.9 release added system-level space-bar file preview, and the interesting parts are the trigger chain (borrowed with credit from QuickLook), the "one preview control, four entry points" rule, and what falls through to a hex viewer.

macOS users have had this since 2009: select a file, hit space, see it. Hit space again, it's gone. No app launches, no focus stolen, no ceremony. Windows never shipped an answer, and the third-party attempts all stop one step short — they preview in Explorer, but the moment you find the file somewhere else (a search tool, a disk analyzer), you're back to double-clicking.

yyzTools 1.0.9 (Sep 20) ships space-bar preview, and the design rule that shaped it was: preview has to work at every point where you meet a file, or it doesn't really work anywhere. This post is about the three engineering decisions that made that rule affordable.

1. The trigger: listen, don't intercept

The obvious implementation is a global keyboard hook (SetWindowsHookEx) that grabs VK_SPACE when Explorer has focus. The obvious implementation is also the one that breaks scrolling: Explorer already uses space (scroll down in details view), and a hook that swallows the key to open a preview has now degraded every file manager it touches.

What shipped instead is a read-only listener on RawInput:

RawInput, not a hook. The preview manager registers for raw keyboard input in its own process. It sees the space press; it never consumes it. Explorer's native space behavior keeps working.
The trigger chain idea is borrowed from QuickLook (the open-source Windows one — QL-Win/QuickLook, GPL). Credit where due: their space-up/space-down handling and auto-repeat suppression is documented in their source, and I followed the same approach rather than rediscovering it.
A one-second suppression after typing. If the focused window recently received character input (you just renamed a file, you're in the search box), space is a spacebar, not a preview toggle. The listener waits for the input context to go quiet.
Focus and selection tracking. A 500 ms poll follows the current selection in the active file manager; when focus leaves file-management surfaces, the preview hides itself.

On by default, off in Settings. A feature that types in file managers has to be removable in one click, or it's malware-adjacent.

2. Getting the selected file: one interface, seven file managers

"Which file is selected" sounds trivial until you leave Explorer. The selection probe (ExplorerSelection) speaks several dialects:

Explorer & desktop — Shell COM (IShellWindows / IFolderView2), the honest way.
Directory Opus — their official dopusrt IPC, because DOpus is its own universe and they document the door.
Everything, Multi Commander, IDM, FilePilot, DeskBox — each with its own probe.

Same interface behind all of them: GetSelectedPath() or nothing. The preview doesn't care which app is in front; it cares whether something answered.

3. One preview control, four entry points

This is the part I'd defend hardest. The preview window is a single WinFilePreview surface with one non-negotiable behavior: it never steals focus. It shows with SW_SHOWNOACTIVATE, which is what lets the arrow keys in the file manager keep moving the selection while the preview follows along — select file, space, arrow, arrow, each one re-rendering. That follow-along loop is the entire value of Quick Look, and it dies the moment the preview takes keyboard focus.

Inside, rendering is a WebView2 host with one front-end module per file type:

Images (jpg/png/gif/webp/svg...), zoom and rotate
~57 text/code extensions with CodeMirror syntax highlighting
Markdown, PDF (paginated)
Office: docx/xlsx/pptx first page — no Office install needed
Video (mp4/webm/mov/mkv) and audio (mp3/wav/ogg) play inline
3D models (gltf/glb/fbx/obj/stl/ply/dae) — interactive, you can rotate them
CAD drawings (DXF) — parsed and rendered client-side
Anything unrecognized falls through to a binary hex view, not a blank window

The 3D/CAD line matters more than it looks: most Windows previewers don't have it, and for anyone working with game assets or mechanical drawings, "space to spin the model" is the whole feature.

And the entry points: Explorer (and the third-party managers above), the built-in Lightning File Search, the Lightning Disk Space Analyzer, and the command palette's file module. Same key, same window, same behavior. The search → preview → Enter-to-open loop is where it pays off daily: you stopped opening files to check if they're the right files.

What it doesn't do

Honest limits, so nobody's surprised: archives don't list their contents (they fall to the hex view), PSD/RAW aren't rendered, odd encodings can garble, and huge videos take a second or two before the first frame. AVI/WMV/FLV depend on what WebView2's codec set will decode.

yyzTools is free, no account, no telemetry — the only network calls in the suite are features that inherently need one (translation, update checks). Windows 10/11, 12 languages, 387 command modules, yyztools.com. Questions about the RawInput chain, the DOpus IPC, or the focus-preserving window are welcome in the comments.

One Index, Four Tools: What Happens When Your Search Engine Becomes a Platform

yyzTools — Fri, 18 Sep 2026 13:47:22 +0000

I build yyzTools — a free, local-first Windows toolkit that folds 40+ tools (command palette, file search, clipboard history, OCR, batch processing) into one installer. The 1.0.8 release ships four new maintenance tools, and they all share one unusual design decision: none of them scan your disk. They ask an index that's already there.

The tool that was secretly an engine

Back in 1.0.5 I wrote about replacing Everything with a homegrown search engine: read the NTFS Master File Table directly, store the metadata columnar, snapshot it to disk, load via mmap. The resident index for a million-plus files ended up at a few megabytes, and queries stayed Everything-compatible.

That engine runs as a Windows service. The service holds the volume handles (reading raw $MFT needs more than a standard user token), keeps the snapshots fresh from the USN journal, and answers queries over named pipes. The GUI never elevates.

For a year, that service had exactly one consumer: the file search window. Which always felt a bit wasteful. A fresh MFT snapshot is effectively a complete catalog of every file on your disk — the treemap above is 533 GB across 1,108,909 files, drawn before you could have finished reading a progress bar. Every disk utility that starts by walking directory trees is re-deriving information the index already has.

So 1.0.8 is the release where three new tools stopped deriving it.

Consumer #1: the disk analyzer that never scans

Space analyzers are famous for their progress bars. WinDirStat, TreeSize, all of them — you launch it, pick a drive, and watch a tree walk grind through a few hundred thousand directories before anything useful appears.

Ours has no progress bar because there's nothing to watch. The analyzer sends a dirsize query to the service and gets sizes back from the snapshot — a first pass over a volume is the time of one IPC round trip. "Drilling down" is just asking about a subdirectory, which is another round trip. The client keeps no state at all; there's nothing to invalidate when files change, because nothing was cached.

The interesting UI part is a squarified treemap (Bruls et al. — the layout algorithm, not a vibe). Folder area is proportional to bytes, anything below 0.75% of the view gets merged into an "other" tile so the map stays readable. Right-click gives you recycle-bin delete, permanent delete, copy path, or open in Explorer — and the delete path validates that the target is inside the current result set before it acts, because a treemap tile is a view of data, not a file handle.

Consumer #2: the file cleaner with a budget

The new cleaner covers 152 rules in eight categories: system, browsers, apps, AI tool caches, containers, development artifacts, project build outputs, and a "large files" bucket that's really a size:>50MB aggregate query grouped by extension. That last one is a good example of how rules and queries blur: a rule that would take a recursive scan minutes is, over the index, one aggregate call.

The scan reuses the service's dirsize/aggregate queries. No directory walk, no per-file stat() storm.

One design choice I want to defend: this cleaner deletes permanently. It does not use the recycle bin, because cleaning 8 GB of build artifacts into the recycle bin doesn't clean anything — it just renames the problem. But permanent deletion needs to earn trust, so it runs behind four gates:

Whitelist roots — five built-in roots plus detected project roots are never touched.
Protected segments — name-level protections, including chat application database files (the ones that hold your message history).
Reparse points are never followed or deleted — a junction or symlink is a boundary, not a shortcut through it.
Process re-check — if a rule targets an app's cache, the app must not be running before its files go.

Riskier rules ship unchecked by default. The checklist has three-state semantics (parent / partial / all), the list goes read-only mid-clean, and you can stop at any time — the report logs what it stopped with, honestly, as "stopped".

Consumer #3: the search window grew a native UI

The file search window itself moved from WebView2 to ImGui on DX11. Nothing against the browser engine, but a search results list wants to scroll a hundred thousand rows without caring, and Dear ImGui does that on a UI thread that sleeps in WaitMessage when nothing is happening. The window now follows the system theme and language in real time — it listens for the same ImmersiveColorSet broadcast Windows sends when dark mode flips.

The engine underneath didn't change: bigram inverted index, USN catch-up, 5–30 MB resident. The status bar in the screenshot below is the whole pitch in one line — search service online (live index), results: 255 (155 ms).

The plumbing nobody sees but everybody feels

Three front ends plus the existing batch tools now hit one service over named pipes. The concurrency model matters more than it sounds: interactive searches get their own slot, and heavy queries (dirsize/aggregate) get three more, assigned to client processes LRU-style so a third tool degrades gracefully instead of colliding. The two groups never preempt each other — a long cleanup scan can't abort your ad-hoc search, and vice versa; within a slot, a newer request from the same client replaces its own stale one, which is exactly the "user already typed something else" case.

One subtlety worth keeping: the front end can't distinguish "indexed" from "truth" — the snapshot is only as fresh as the last USN catch-up. For search that's fine. For a tool that's about to delete files, it isn't, which is why the cleaner re-validates through the normal filesystem layer before anything destructive, and why the analyzer's delete path confirms the target exists where the treemap says it does.

flowchart LR
    A[FileClean rule] -->|"aggregate query"| S[Named pipe]
    B[DiskSpace drill-down] -->|"dirsize query"| S
    S -->|"own slot per group<br/>no cross-preemption"| C[Service answers<br/>from mmap snapshot]

What I'd take from this

The general lesson, if there is one: when you own an index, every new tool has a much shorter spec. The cleaner's "scan" feature is a query. The analyzer's entire engine is an IPC client. The hard part — reading NTFS fast, storing it small, keeping it fresh — was paid once, and four tools now amortize it.

There's a product lesson in there too. 1.0.8 looks like "four new tools" in a changelog, but from the inside it's one capability (a resident disk catalog) finding three more users. If you're building a suite, the features that compose like this are worth more than the ones that bolt on.

yyzTools 1.0.8 is free, no account, no telemetry — the analyzer and cleaner work entirely from local data, and the only network calls in the suite belong to features that inherently need one (like web translation). Windows 10/11, 12 languages, at yyztools.com. Happy to answer questions about the treemap layout, the IPC slot design, or the safety model in the comments.

You Can Write Desktop Tools in Plain HTML/CSS/JS — Here's the SDK That Lets You

yyzTools — Mon, 07 Sep 2026 02:36:52 +0000

I build yyzTools — a free, local-first Windows productivity suite (command palette, clipboard history, OCR, file preview, batch processing — 40+ tools in one install). Today's post isn't about the app itself; it's about the module SDK I just opened up, because the development model is the kind of thing frontend developers keep telling me should be impossible: **one static webpage + one JSON file = a native desktop tool window.* No C++. No build step. No packaging.*

The demo first

Download the sample project, unzip it, and you get two folders — Web/ and Modules/. Copy them next to yyzTools.exe, restart, and hit Alt+Space. Type sdk:

A 760×540 native window opens. It's a full-disk file search app — instant results, Everything-style syntax (ext:pdf size:>100mb), double-click to open files.

Behind that window:

Web/SDK_Sample/
  index.html       # plain DOM, data-i18n attributes
  filefinder.js    # all the logic (vanilla JS, zero deps)
  filefinder.css   # styled entirely with --zen-* variables
  i18n.js          # string dictionary (zh_cn / en)
  lib/
    zen_api.js     # the ONLY library — the native API wrapper
Modules/SDK_Sample.zenmod   # one JSON declaring the window

No package.json. No node_modules. No bundler. It's 2026 and I'm shipping an SDK whose sample runs without a toolchain — deliberately, and the reason matters.

How the window gets born: it's declared, not built

The part of desktop development that scares everyone off was never business logic — it's windows. Message loops, DPI awareness, taskbar integration, hotkey registration. The SDK's answer is to make the host a data file:

{
    "id": "sdk_sample",
    "type": "web",
    "url": "SDK_Sample/index.html",
    "width": 760,
    "height": 540,
    "layoutType": 34,
    "icon": "fas fa-search"
}

The host reads this at startup and creates a native window with a WebView2 control pointing at your page. And because the module now exists in the app's registry, it inherits the whole suite's infrastructure for free:

Command palette search — localized across all 12 UI languages
Global hotkey binding
Dock mounting
Theme integration — the host injects --zen-* CSS variables; your page follows the app's light/dark mode with zero prefers-color-scheme media queries

You write the feature. The host absorbs the decade of Win32 plumbing.

## Talking to the system: the ZenAPI bridge

Your webpage gets system powers through a window.Zen bridge, consumed via an official ZenAPI wrapper class:

import ZenAPI from './lib/zen_api.js';

// Full-disk search (async — runs on a background thread)
const res = await ZenAPI.searchFile('invoice ext:pdf', 200);
if (!ZenAPI.isOk(res)) { /* unified error check */ }

// Open the file / reveal in Explorer
await ZenAPI.openFile(fullPath, false);
await ZenAPI.openFileLocation(fullPath);

// Persist your own config (narrow-grained patch, not full rewrite)
await ZenAPI.setConfig({ sdk_sample: { history } });

One design detail worth stealing for anyone building a JS bridge: searchFile is asynchronous, and the native side implements a search slot — a new request displaces any in-flight one (the old Promise resolves empty). Combined with 300ms input debounce and a monotonically increasing sequence number on the frontend to discard out-of-order responses, rapid typing neither floods the background thread nor flashes stale results. In interactive search, the correct semantic for concurrent requests is overwrite, not queue — the opposite of what server-side intuition tells you.

The API surface goes well beyond search: file dialogs, chunked reads for large files, clipboard, screenshot → OCR pipeline, spawning external programs, invoking other module windows. The full reference is published in 12 languages — including which interface returns isDir as a 1/0 number rather than a boolean, because hand-rolled JSON paths and property-tree paths serialize differently. Documenting the type traps is the difference between docs people trust and docs people tolerate.

Debugging: just open it in a browser

This is the part that sells frontend developers. Double-click index.html — it opens in your normal browser. There's no window.Zen there, so ZenAPI.call goes down the exception path and returns error: -1, but your layout, styles, debounce, and rendering logic all work normally. Iterate the UI in the browser; hop into the real host only for native integration. The degradation path was designed in from day one.

The honest security section

The native API is fully open to module developers: file read/write/delete, process creation, window control, clipboard. No permission prompts, no sandbox, no undo.

That's a trust-model decision, not an oversight. This SDK targets developers building tools for themselves or their team — the deployment unit is "copy a folder", the distribution radius is people who already trust you. If an attacker can write to your modules directory, they can already drop an exe; disguising it as a .zenmod gains them nothing. Sandboxing buys you nothing here and costs every module author a permissions negotiation they don't need.

If I ever build a public module store, this design gets rebuilt — different trust model, different security requirements. Match the security to the trust model, not to a checklist.

Why bother

If you write web pages at all, here's the pitch: your existing skillset now produces desktop tools with a native window, global hotkeys, tray integration, and a theming system — for the cost of one folder and one JSON. The internal tool you'd otherwise ship as "open this localhost link" can be a real window in the palette.

Docs (quick start + full API reference): yyztools.com/sdk.html
Sample project download: same page
The app: free forever, no accounts, no telemetry, Windows 10/11

The sample is a genuinely pleasant read — four files, an hour, including the debounce/race handling. If you build something with it, drop it in the comments; good ones may make it into the built-in catalog.

The Local-First Tax: What It Actually Costs to Refuse the Cloud

yyzTools — Thu, 03 Sep 2026 13:03:38 +0000

I'm building yyzTools — a Windows productivity suite (clipboard history, OCR, file search, app usage stats) that is aggressively local-first by design. No accounts, no telemetry, no cloud sync. This post isn't about the product. It's about the real costs of the stance.

The pitch vs. the tax

"Local-first" is a compelling pitch: your data stays on your machine, no cloud dependencies, no breach exposure, works offline. It resonates with privacy-conscious users and with developers who've seen what happens when a cloud service sunsets your data.

But the pitch hides real costs. After building a local-first tool for years, here's the tax I've paid—and what I'm still not sure is worth it.

The costs

1. Multi-device sync is genuinely gone

"Copy something at work, see it at home" is the cloud clipboard's killer feature. I can't offer it without violating the core principle (data leaves the machine). My users—and I—work around it by manually syncing the local storage directory with a file-sync tool.

That feels like 2005. The cloud clipboard isn't popular by accident; cross-device sync is genuinely useful. Telling users "just sync the DB folder yourself" is a real regression in convenience.

2. Local models are heavy

The OCR engine (RapidOCR's ONNX models) ships in the installer. The app is ~600MB. A cloud OCR tool is a 5MB app + a server. Users with small SSDs or slow connections notice.

There's no way around this with local-first: a capable local model has weight. The trade is "data stays local" for "installer is large." I've made peace with it, but it's a tax.

3. No network effects

Cloud tools get sticky because your data is there, your collaborators are there, your history is there. A local tool has none of that. Retention is purely "does this work well enough day to day?"—which is fragile. A user can walk away any time, taking nothing with them.

For a solo dev without a marketing budget, this is a slow grind. Cloud tools compound (data lock-in); local tools don't.

4. The convenience/privacy framing is mostly a false binary

"People will trade privacy for convenience" is the industry line. In my experience, users don't perceive the trade at all. They hit "allow" and use the cloud tool. The local-first stance is invisible until something goes wrong (a breach, a policy change, a sunset), at which point it's too late—the data is already gone or compromised.

You're selling insurance against a low-probability event. Most users don't buy insurance they can't see.

5. The user is responsible for backups

Cloud tools hide backup responsibility. Local-first puts it on the user. I document the storage path and recommend syncing it, but I can't force it. If a user's drive dies and they didn't sync, their clipboard history is gone.

This is philosophically correct ("it's your data, you own the responsibility"), but operationally it's a support burden and a UX cliff.

Where I drew the line

Not everything can be local. Translation, downloads, opening URLs—these are network by nature. The question is how to handle the network features honestly.

My rule: the network feature's data destination is explicit and user-chosen. Translation sends data to the service the user picks in settings (DeepL, Google, etc.), not a fixed yyzTools server. The user knows where their text goes because they chose the service. No hidden relay.

This is a middle path: local-first for the data that can be local (clipboard, OCR, search, stats), explicit-and-chosen for the data that can't (translation). It's not pure, but it's honest.

The no-account stance

Accounts aren't just "friction." They're a privacy design decision:

Account → behavior tied to identity → you're processing personal information, with all the compliance that implies
No account → no identity → behavior can't be linked to a person → no personal information processing

yyzTools has no accounts, no telemetry, no behavioral collection. This isn't "saving a registration step"—it's a structural choice that removes the possibility of identity-behavior linkage. For users in regulated environments (enterprise, healthcare, government), this is a feature, not a limitation.

For personal users, it's invisible. Nobody installs a clipboard manager thinking "glad there's no account." They notice the absence only when a cloud tool's breach headlines hit.

Is it defensible?

I keep going back and forth.

The case for: privacy regulations are tightening (GDPR, data residency laws). As breaches accumulate and cloud trust erodes, the local-first stance ages into relevance. The users who care are a minority, but they're loyal. The stance differentiates in a market where "free + cloud + ads" is the default.

The case against: 95% of users don't value it until it's too late. The convenience tax (no sync, large installer, no collaboration) is felt daily; the privacy benefit is felt never (until a breach, which probably won't happen to them). You're paying a real daily cost for an insurance most users will never collect on.

I don't have a conclusion. I have a stance and a tax bill, and I'm still calculating whether the exchange is worth it.

What I actually want to ask

I'd love to hear from both sides:

For users who've tried local-first tools and reverted to cloud: what was the breaking point? Sync? Collaboration? The lack of a web UI?
For users who run local-first and wouldn't go back: what makes it worth the convenience cost for you?
For builders: is local-first a defensible long-term position, or a boutique stance that 95% of users don't value? Does it only make sense in regulated industries, or is there a broader market?
The middle path—local for what can be local, explicit-chosen cloud for what can't—is it meaningfully different from a cloud tool, or just a cloud tool with better labeling?

I'm not here to sell you on local-first. I'm here because I'm honestly uncertain whether it's a defensible position or a philosophical luxury, and I'd value outside perspective.

I'm building yyzTools — a free, local-first Windows productivity suite. No accounts, no telemetry, no cloud sync. Website: yyztools.com. The "no sync" tax is real; I use a file-sync tool myself.

Why I Replaced Everything With a Homegrown MFT Search Engine (Memory: Hundreds of MB a Few MB)

yyzTools — Wed, 02 Sep 2026 13:21:47 +0000

I build yyzTools — a free, local-first Windows productivity suite that folds 40+ tools (command palette, clipboard history, OCR, file preview, batch processing) into one installer. This post is about the 1.0.5 release, where I did something that sounds insane: I removed my dependency on Everything — the gold standard of Windows file search — and wrote my own engine.

The setup

For about two years, file search in yyzTools was powered by Everything. And let me be clear: Everything is phenomenal. Sub-second full-disk search, a mature query syntax (ext:pdf size:>100mb dm:today), battle-tested by millions of users. Integrating it was one of the best decisions I made early on — instant world-class search for free.

But there was a catch that grew more annoying with every release: Everything is designed to be used standalone. Its index lives in its own service process. On a machine with a lot of files, that index holds hundreds of MB of RAM, resident from boot to shutdown.

For a standalone search tool, that's a perfectly reasonable price. But yyzTools is a resident suite — the whole point is that it sits quietly in your tray until you hit Alt+Space. Every MB of resident memory lowers the threshold at which users uninstall you. And search is the heaviest feature in the suite.

So the conflict was structural: the dimension Everything optimizes least for (being embedded in someone else's memory-sensitive app) was exactly my core requirement.

In 1.0.5, I replaced it. Index memory went from hundreds of MB to a few MB. Query syntax stayed Everything-compatible. Here's how.

Wrong turn #1: the "official" API is a trap

When you start researching full-disk enumeration on Windows, you find FSCTL_ENUM_USN_DATA. Documented, blessed, gives you every file's FRN (file reference number) and parent FRN. Seems like the obvious choice.

I implemented it. 1.34 million files, 120 seconds to enumerate. Rejected.

The problem: USN records are a change journal, not a catalog. They don't carry file size or timestamps — so for every single file you have to call back with FSCTL_GET_NTFS_FILE_RECORD to fetch the full MFT record. A million random reads by FRN. That's not slow code; that's a wrong-shaped data channel.

The Everything way: read $MFT directly

Everything and WizFile don't use that API for full enumeration. They open the volume device (\\.\C:, read-only) and read the $MFT byte stream directly. The Master File Table is NTFS's census book: every file and directory is one fixed 1024-byte record, stored sequentially, containing name, size, and timestamps. Scan it linearly and you get everything in one pass of sequential IO:

// 1. Parse the $DATA run list of $MFT's own record (VCN→LCN mapping)
static bool ParseMftRuns(BYTE* mftRec, int len, std::vector<int64_t>& lcns, ...);

// 2. ReadFile the volume handle in chunks, per run
// 3. Fix up each 1024-byte record, extract $FILE_NAME / $DATA attributes

Two details worth knowing if you go this route:

Hard links: one MFT record can carry multiple $FILE_NAME attributes (one per link, each pointing at its own parent directory). Each one must become a separate row in your index, or link results silently go missing.
Permissions: reading the volume device needs more than a standard user token. That's why the engine runs as a separate process backed by a Windows service — the service holds the volume handle, the main app consumes queries over IPC, and the GUI never elevates.

Where the memory went: columnar storage

The full-enumeration part was honestly the easier half. The interesting question was: you now have 1.34 million rows of metadata. How do you hold them in RAM for a few MB instead of a hundred-plus?

The naive layout is an array of objects:

struct FileEntry {
    uint64_t frn, parentFrn, size;   // 24 B
    int64_t  mtime;                 // 8 B
    std::string name;               // 32 B + heap allocation per file
    bool isDir;                     // 1 B + 7 B padding
};

Padding, per-string heap allocations, allocator headers, terrible cache locality. That's your hundred-plus MB right there — not because anyone wrote bad code, but because the layout itself is that size.

The engine stores rows columnar instead — separate tight arrays, one per attribute, plus an interned name pool:

std::vector<uint64_t> frns;      // full 64-bit FRNs (sequence<<48 | index)
std::vector<uint64_t> sizes;
std::vector<uint32_t> mtimes;     // Unix seconds — 1970..2106 fits in 4 bytes
std::vector<uint32_t> nameOffs;   // offset into the blob
std::vector<uint32_t> nameLens;
std::vector<uint8_t>  isDirs;
std::vector<char>     nameBlob;   // UTF-8 pool, no NUL terminators, deduplicated

Every frontend developer knows this instinctively: it's the difference between [{name, size, mtime}, ...] and one TypedArray per column. SoA beats AoS when you scan.

The merciless details that stack up:

Interned names. "New folder", "package.json", "index.js" appear tens of thousands of times each. One copy in the blob; every row is just an 8-byte offset+length slice.
uint32 Unix-seconds mtimes. Halves the time column; 1970–2106 is plenty.
Lowercase names that aren't there. Case-insensitive search needs a lowercased name — but most filenames are already lowercase. Each row carries a flag bit: if the folded name is byte-identical to the original, the lowercase view just reads the original blob. Saves nearly an entire second name pool.
Derived columns aren't persisted. The parent FRN you need for path reconstruction is derivable from the parent-row column at query time, so the snapshot simply doesn't contain it.

Same data, different layout: hundreds of MB becomes a few MB. Structure, not optimization.

Staying fresh: USN journal catch-up — and a subtle trap

Full builds are one thing; filesystems keep changing. NTFS ships a change journal (USN records, monotonically increasing). The engine stores an anchor (JournalId, NextUsn) and periodically replays new records.

The trap I hit so you don't have to: the anchor must be taken before enumeration starts, not after it finishes.

My first version grabbed the current USN after the full scan — logically airtight, right? Wrong. The scan takes seconds. Save a file during the scan and it may not be on disk when your read passes its directory, yet its USN is already below your anchor. The journal replay skips it forever. The index is silently missing a file, no error, no recovery.

Store the pre-enumeration anchor. Replay may redundantly re-apply a change that the scan already caught — idempotent, harmless. Missing is not.

Also: journals get trimmed and recreated. The anchor's JournalId detects that; on mismatch, abandon incremental catch-up and do a full rebuild. Correctness always outranks cleverness.

Persistence: mmap snapshots

Rebuilding on every boot is wasteful, so the index snapshots to disk per volume and loads via mmap — O(1) open, column pointers point straight at mapped pages, zero copies. The query-accelerating structure (an ASCII bigram inverted index, VByte-delta compressed) is materialized into the snapshot, so loading requires zero rebuilding.

Two Windows-specific footnotes for anyone doing this:

After mmap-loading, call PrefetchVirtualMemory. Otherwise the first full scan pulls tens of MB in random 4 KB page faults (measured: ~6 s on my C: volume) while the OS pages things in lazily.
A file you have mmap'd cannot be replaced. Atomic snapshot replacement (MoveFileEx over the old path) fails with gle=5 while your own process still holds a mapping of the old file — even though you're "just" swapping the path. Release your own mapping first, and guard the column-pointer swap with a reader-writer lock so in-flight queries don't race the swap.

The scorecard

	Bundled Everything	Homegrown (1.0.5)
Index memory	Hundreds of MB (external service)	A few MB
External dependency	Third-party install/bundle	None
Query syntax	Everything's	Compatible (`ext:pdf`, `size:>100mb`, `dm:today`)
Control	Black box	End-to-end

Was it worth it? For this product, yes — search is the palette's core experience, and resident memory is the metric that decides whether a tray app survives on someone's machine. The rule of thumb I'd offer from this round:

Don't build a wheel where the existing one is already optimized for you. Build it when your core requirement is exactly the dimension the dependency doesn't optimize for.

Everything is perfectly optimized for being Everything. It was never going to be optimized for being inside something else.

This shipped in yyzTools 1.0.5 — free, no accounts, no telemetry, Windows 10/11, at yyztools.com. The same release also added a quick OCR-translate pipeline (screenshot → recognize → translate, all offline via the local RapidOCR engine). Happy to dig deeper into any part of this in the comments — the parallel-scan worker pool has a genuinely fun stack-lifetime crash story if anyone wants it.

yyzTools: 40+ Windows Productivity Tools in One Install — Local-First, Free Forever

yyzTools — Wed, 02 Sep 2026 13:14:35 +0000

Tired of juggling a dozen separate utilities — a launcher, a clipboard manager, a translator, an OCR tool, a file previewer, a screenshot app, a batch renamer...? yyzTools fuses them all into a single, native Windows application with a shared data layer and unified keyboard shortcuts. No plugins. No accounts. No telemetry.

The Problem

If you're a Windows power user, your efficiency toolkit probably looks something like this:

Need	Typical tool
App launching	PowerToys Run / Flow Launcher
File search	Everything
Clipboard history	Ditto / Windows built-in
Translation	DeepL + browser extension
OCR	Online tool / Umi-OCR
File preview	QuickLook
Screenshots	Snipaste
Batch renaming	Separate utility
JSON formatting	Browser tab
Regex testing	regex101.com
Base64 encoding	Browser tab

Each tool has its own shortcut, its own settings panel, its own update channel — and crucially, none of them talk to each other. You can't pipe clipboard history into OCR, or send OCR output directly to translation, or push translation results back to the clipboard. Every cross-tool workflow requires manual copy-paste intermediation.

The Solution

yyzTools (Yes Your Zen Tools) takes a different approach: fuse 40+ productivity tools into a single install, sharing one data layer, one set of keyboard shortcuts, and one visual language.

Current version: v1.0.3.1300
Platform: Windows 10 1809+ / 11, 64-bit
Price: Free forever, no account required
Languages: 12 (English, Simplified Chinese, Traditional Chinese, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Italian)
Website: yyztools.com

Architecture: C++ + WebView2

yyzTools uses a hybrid architecture that's worth understanding as a developer:

┌─────────────────────────────────────────┐
│     Frontend (Alpine.js + vanilla JS)   │
│   cmdplate / ocr / translate / ...      │
│   Unified via web/lib/zen_api.js        │
├─────────────────────────────────────────┤
│      WebView2 Bridge Layer              │
│   BindSync → synchronous return          │
│   BindAsync → async callback (OCR only)  │
├─────────────────────────────────────────┤
│         C++ NativeApi Layer              │
│  FileManager / ProcessManager /          │
│  ClipboardManager / OcrManager /        │
│  DownloadManager / CmdManager ...        │
├─────────────────────────────────────────┤
│            Win32 System API              │
└─────────────────────────────────────────┘

Key design decisions:

WebView2 over Electron: Uses the Windows-built-in Edge engine, no bundled Chromium, lower memory footprint
Alpine.js (3KB) over React/Vue: No virtual DOM overhead, no heavy build chain
Vite multi-entry: Each feature page is an independent bundle
Frontend updates without recompiling C++: UI changes ship as frontend dist, no .exe rebuild needed

The JS ↔ C++ bridge is straightforward:

// Frontend calls go through ZenAPI wrapper, never raw window.Zen
class ZenAPI {
    static isOk(res) {
        return String(res.error) === '0';  // Normalizes both number 0 and string "0"
    }
    static async getConfig() {
        return await window.Zen.getConfig();
    }
}

// C++ registration in NativeApi::SetupBindings()
m_bindManager->BindSync("getConfig", [this]() { return this->GetConfig(); });
m_bindManager->BindAsync("ocrRecognition",
    std::bind(&NativeApi::OcrRecognition, this, _1, _2));

All methods return a JSON object { error, errorMsg, ... }. error === 0 means success.

Core Features

Command Palette — One Search Box for Everything

Alt + Space brings up the unified entry point. Prefix-based domain switching:

Prefix	Searches	Replaces
(none)	Apps, system commands, settings, command modules	PowerToys Run
`f`	All files (Everything SDK)	Everything
`p`	Running processes	Task Manager
`w`	Windows	—
`b`	Browser bookmarks	—
`c`	Clipboard history	Ditto
`>`	Command line	Terminal

Also includes instant math: type 128*0.85 or sqrt(144)+3^2 and the result appears in real-time, press Enter to copy.

Supports pinyin search for Chinese app names — typing weixin or wx finds WeChat.

Clipboard History + Cross-Feature Pipeline

Text and image clipboard history with:

Pin images to desktop as floating windows (great for reference screenshots)
Pipeline: select a text entry → send to translation; select an image → send to OCR

This is the "fusion" advantage — no manual copy-paste between tools.

Local OCR (RapidOCR)

Screenshot-to-text using the local RapidOCR engine:

Fully offline — no cloud API, no upload, no latency
Chinese-English mixed recognition
Pipeline: Screenshot OCR → one-click translate → one-click copy to clipboard

File Preview

Spacebar to preview without launching any app:

Word / Excel / PowerPoint / PDF
Images / Videos / Audio
Code files (syntax highlighted)
Archive files (browse directory tree)
DXF drawings

Developer Tools

Built-in utilities that replace browser tabs:

Tool	What it does
Regex tester	Real-time match highlighting, group viewer
Encode/Decode	Base64 / URL / HTML / Unicode / Hex / Morse
Hash calculator	MD5 / SHA-1 / SHA-256 / SHA-512 for text and files
Crypto	OpenSSL-based symmetric/asymmetric encryption, key generation
Data conversion	JSON ↔ YAML ↔ XML ↔ TOML ↔ CSV, hex/case/width conversion
Data generation	UUID v4, ULID, random strings, batch test data

Batch Processing — Three Heavy-Duty Engines

Engine	Powers	Capabilities
ImageMagick	Image batch	Resize, crop, format convert, watermark, compress
FFmpeg	Video batch	Transcode, trim, extract frames, compress, extract audio
pdfcpu + Ghostscript	PDF batch	Merge, split, watermark, compress, encrypt/decrypt

Plus a batch rename tool with preview: sequential numbering, find-replace, regex, case, EXIF date.

Screenshots + Recording

Region screenshot: Select area, copy or save
Scrolling screenshot: Scroll to capture long pages/documents
Pin to screen: Pin screenshots as desktop sticky notes
Screen recording: Record screen + audio, optional webcam overlay, auto zoom-follow on mouse, keystroke display, one-click export

Command Module System (.zenmod)

379 built-in command modules across 5 categories:

Category	Count	Examples
System	257	All Windows Control Panel functions
AI Tools	55	ChatGPT, DeepSeek, Gemini, Claude, Qwen, etc.
Apps	47	Volume control, shutdown, screenshot, etc.
Internal	21	Translation, OCR, download, calculator, etc.
Web	2	OneNote, Microsoft To-Do

Extending is trivial — drop a JSON file into the Modules/ directory:

{
    "id": "my-tool",
    "type": "app",
    "name": { "en": "My Tool", "zh_cn": "我的工具" },
    "desc": { "en": "Quick launch", "zh_cn": "快速启动" },
    "cmdPath": "yyzBrowser.exe",
    "cmdArgs": "--url=https://example.com --size=800x600"
}

No compilation, no restart. The command appears in the palette immediately.

Dynamic Wallpaper + Desktop Effects

Windows Composition API places web pages and videos below the desktop icon layer — no icon obstruction, no click interference. Game mode pauses all effects to free resources.

Design Philosophy

Local-First

All data processed locally:

Clipboard history → local storage
OCR → local RapidOCR model, no cloud API
File search → local Everything index
App usage stats → local records
File preview → local parsing

Only translation (calls translation service API) and update checks require network.

Free Forever

No paywalls, no premium tier, no trial countdown
No account registration required
No identity collection, no user profiling, no behavioral telemetry
No ads

Delta Updates

Each component (main binary, frontend pages, command modules, FFmpeg, OCR models) is packaged independently. Updates download only the changed sub-packages — a frontend-only update might be a few hundred KB, not a full 1GB reinstall.

Comparison

	yyzTools	PowerToys	uTools	Flow Launcher
Architecture	C++ + WebView2	C# + WPF	Electron	C# + WPF
Feature source	All built-in	All built-in	Plugin market	Plugin market
Translation	Built-in	None	Plugin	Plugin
OCR	Built-in (offline)	None	Plugin	Plugin
Batch processing	ImageMagick/FFmpeg/pdfcpu	None	Plugin	None
File preview	Office/PDF/code/archive	SVG/PDF/MD	Plugin	None
Data pipeline	Clipboard→OCR→Translate→Copy	None	No shared data layer	None
Extension method	JSON file (zero compile)	C# plugin	Plugin market	C# plugin
Price	Free	Free	Paid tier	Free

The key difference isn't feature count — it's integration. yyzTools features share one data layer and can pipe into each other. The others are either loose collections of independent tools (PowerToys) or plugin platforms where plugins don't share state (uTools).

Getting Started

Download: yyztools.com
Requirements: Windows 10 1809+ / 11, 64-bit
Cost: Free, no registration
Languages: 12 (English, Chinese Simplified/Traditional, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Italian)

Quick start:

Download and install from yyztools.com
Press Alt + Space to open the command palette
Type a feature name or app name to search
To add custom commands, drop a .zenmod JSON file into the Modules/ directory

If you use 3+ of the tools yyzTools covers (clipboard manager, translator, OCR, file previewer, batch renamer, screenshot tool, regex tester, etc.), it's worth trying as a single replacement rather than maintaining a fragmented toolkit.

Website: yyztools.com · Free forever · Local-first · 12 languages

Shipping Stock CLIs as Subprocess Instead of Static-Linking SDKs

yyzTools — Sun, 23 Aug 2026 06:30:53 +0000

I'm building yyzTools, which bundles 9 third-party engines (OpenSSL, FFmpeg, ImageMagick, pdfcpu, Aria2, 7-Zip, RapidOCR, Everything...). I chose to spawn them as subprocesses rather than static-link their SDKs. Here's why—and the cost.

The conventional approach
When your app needs OpenSSL crypto, FFmpeg video processing, ImageMagick image ops—you reach for the SDK. Link libssl, link libav*, link libMagick. One binary, no external deps, fast function calls. It's the textbook answer.

I did the opposite. yyzTools ships the stock CLI binaries (openssl.exe, ffmpeg.exe, magick.exe, pdfcpu, aria2c, 7z) and spawns them as subprocesses. The C++ layer is a thin loop: build args → CreateProcess → read stdout → wrap as JSON → return. It doesn't know what -gravity southeast or sm4-cbc means. It just passes the algorithm name through.

Why I went this way

Upgrades without recompiling This is the big one for a desktop app. OpenSSL ships a CVE, or adds sm2/sm3/sm4 support in 3.x. If you've static-linked, you recompile the whole app, run full regression, re-release, and every user reinstalls.

With the subprocess model, I drop in a new openssl.exe. Zero C++ changes. The update is a few-MB delta, not a full reinstall. For a product where users won't tolerate reinstalling for a library bump, this is the deciding factor.

No symbol conflicts
OpenSSL, zlib, libpng—multiple libraries want to own these symbols. Static linking them all into one binary is a recipe for "which inflate did I just call?" With subprocess CLIs, each tool brings its own dependencies in its own process. No conflict.
Transparent supply chain
openssl version, ffmpeg -version—auditing which version of each tool is live is trivial. It's an independent binary. Far easier than digging symbols out of a statically-linked blob.
Free crash isolation
If ffmpeg.exe misbehaves, it exits non-zero and my host wraps that as an error. My main process keeps running. A static-linked bug can take down the whole app. The process boundary is a free fault domain.
Algorithm support is "front-end list + docs", not C++ rebuild
Because the C++ side just passes algorithm names through, adding a new hash algorithm means adding a line to the front-end's ALGORITHMS list and updating docs. NativeApi doesn't change. I covered sm2/sm3/sm4 in a day this way.

The cost
This isn't free. Let's be honest:

Per-call fork overhead
Spawning a process is ~tens of ms. For "compress this folder" or "hash this file," fine. For "verify 10,000 HMACs in a loop," brutal. You'd never build a high-throughput crypto service this way. I knew this going in—yyzTools hashes one file at a time, not a stream of requests. Low frequency is the prerequisite for this pattern.

Large-file hashing is slower
A static SHA256() call streams bytes in-process. The subprocess model means bytes cross the process boundary. For a 4GB ISO, you feel it. Acceptable for my use case; unacceptable for a backup service.

The stdout contract is the weak point
CLIs emit human-readable output, not machine-readable JSON. I hand-rolled a stable parser for each CLI's output. When a CLI upgrades and changes its output format, the parser can break. Easier to debug than a static ABI change (the CLI just fails loudly), but it's a maintenance surface.

I wish there were a standard "CLI emits JSON" convention. Some tools have it (gh, kubectl), many don't (openssl enc's output is a mess to parse). The inconsistency is the real friction.

Process lifecycle management
You own timeouts, zombie handling, cancellation. A static function call doesn't hang. A subprocess can. I had to build a work-queue with concurrency limits (don't spawn 200 magick.exe for 200 images) and cancellation. That's extra code you don't write for a static link.

Where I'd draw the line
This pattern fits when:

Low-frequency calls — desktop tools, not services
Fast upstream upgrades matter — security CVEs, new algorithms
You want transparent supply chain — auditable binaries
The CLI is mature and stable — FFmpeg, OpenSSL have decades of CLI stability
It fails when:

High throughput — a TLS server, a per-request crypto service
Large streaming I/O — backup, media transcoding at scale
The CLI output is unstable — you'd spend your life chasing format changes
I use the subprocess model for the 9 bundled CLIs in yyzTools. If I were building a media server or a crypto API gateway, I'd static-link (or use a proper service). The pattern is frequency-dependent.

A pattern worth naming
I haven't seen this called out as a named pattern, but it shows up: VS Code ships ripgrep and calls it. Many Electron apps bundle CLIs. The principle—"ship the stock CLI, spawn it, parse stdout"—is a middle ground between static linking and microservices.

Position on the dependency spectrum:

Static link Subprocess CLI gRPC service
Perf fastest (function call) medium (fork + IPC) slowest (network)
Upgrade cost recompile + regression drop a file redeploy service
Crash isolation none process boundary network boundary
Cross-language compile-time binding natural natural
Best for high-throughput core low-freq trusted capability cross-machine
The subprocess-CLI slot is underused. For a desktop app bundling many third-party capabilities, it's often the right slot.

The honest takeaway
If your tool calls a third-party engine a few times a session (not thousands of times a second), and you care about fast upgrades and transparent supply chain, shipping the stock CLI as a subprocess beats static-linking. You pay per-call latency and a parser to maintain; you gain zero-recompile upgrades and crash isolation.

Don't use it for hot paths. Do use it for "I need OpenSSL/FFmpeg/ImageMagick occasionally, and I don't want to recompile when they patch a CVE."

I'm building yyzTools — a free, local-first Windows productivity suite. Website: yyztools.com. The 9 bundled CLIs are OpenSSL, 7-Zip, FFmpeg, ImageMagick, pdfcpu, Aria2, RapidOCR, Everything, and Ghostscript.

Why I Built a Windows Desktop App with C++ + WebView2 Instead of Electron

yyzTools — Fri, 21 Aug 2026 08:40:17 +0000

I'm building yyzTools, a Windows productivity suite with 40+ tools fused into one install. This is the architecture decision I get asked about most.

The default path

When a developer today wants to build a desktop app, the default reflex is Electron. It's rational: HTML/CSS/JS, cross-platform, mature ecosystem (VS Code, Slack, Discord proved it works). If your team is frontend-heavy, it's almost a non-decision.

I didn't take that path. yyzTools is C++ (Win32) + WebView2 + Alpine.js + Vite. Windows-only. No bundled Chromium.

This post isn't "Electron is bad." It's "for a resident, lightweight, multi-feature desktop tool, Electron's costs outweigh its benefits, and here's what I picked instead."

Why Electron didn't fit this project

The key word is resident. yyzTools is a tool you install once and it sits in your tray, running every time you hit Alt+Space for the command palette, grab from clipboard history, fire OCR. It's not an app you open and close—it's always there.

Electron's model is "bundle a full Chromium per app." For an app you open occasionally, the ~200MB memory and multi-second startup is tolerable. For something that's always resident, it's a tax you pay every second the machine is on.

Nobody wants a clipboard manager + launcher eating 400MB of RAM just by being installed.

The alternative: WebView2 + a C++ host

Microsoft's WebView2 is a control that renders web content using the Edge engine already installed on Windows. No bundled browser. The runtime ships with Windows 11; on Windows 10 the installer guides the user.

So my stack:

C++ / Win32 host — owns the window, system calls, process management, all native work
WebView2 — renders the frontend pages using the system Edge
Alpine.js (~3KB) — frontend framework, no virtual DOM, no heavy build chain
Vite multi-entry — each feature page (command palette, OCR, translate, download...) is an independent bundle

The architecture is a four-layer sandwich:

Frontend pages (Alpine.js + vanilla JS)
        ↓  via web/lib/zen_api.js (unified wrapper)
WebView2 bridge layer
   BindSync  → synchronous return (most methods)
   BindAsync → async callback (OCR, app-info)
        ↓
C++ NativeApi layer (FileManager / ProcessManager / ...)
        ↓
Win32 system API

The frontend never calls window.Zen directly. It goes through a ZenAPI wrapper class that normalizes return values—the C++ side has two JSON paths (hand-rolled strings vs boost::property_tree) where the same error field can be number 0 or string "0". The wrapper does String(res.error) === '0' to paper over it. (That's documented debt, not a hidden clever trick.)

What this buys

Lower memory. No Chromium process resident. The main process is a thin C++ host plus the system Edge it borrows.
Faster startup. No spinning up a fresh Chromium instance.
Smaller disk. The web runtime is shared across the system, not bundled per-app.
Native when needed. File ops, process management, OCR engine calls, screen recording—all C++, no IPC to a JS-land bridge for hot paths.

What it costs

Let's be honest about the tradeoffs, because this isn't a free lunch:

Windows-only. WebView2 is Microsoft's. If you want Mac/Linux, you need Electron or a full Qt port. yyzTools targets Windows, so this is fine—but it's the biggest constraint.

A hand-written bridge. Electron gives you mature IPC for free. With WebView2 you hand-roll the JS↔C++ channel (a "method name → callable" registry, sync/async variants, thread marshaling for async callbacks back to the UI thread). It's not hard, but it's code you own and maintain.

No type system on the boundary. The error field type drift I mentioned isn't caught by TypeScript—it's a runtime contract between C++ and JS. I normalize at the wrapper, but every new native method is a chance to introduce a new type mismatch. A typed IPC (like tRPC over a real protocol) would be safer; I chose simplicity.

Alpine.js means no React ecosystem. Alpine is great for "many simple pages" (which a productivity suite is). But if I wanted a complex single-page app with a rich component library, I'd miss React's ecosystem. The pages here are intentionally simple—search box, settings panel, result grid—so Alpine fits.

You need C++ people. A pure-frontend team can't extend the native side. This is a real org constraint. If your team can't staff Win32 expertise, Electron is the pragmatic call, period.

When you'd make the same call

I'd pick this again specifically when all four are true:

The app is resident (tray, autostart, always-on) — the memory tax compounds
Windows is the target — WebView2 is Windows-only
You need native system access — file/process/clipboard/OCR, where C++ beats a JS bridge
You have C++ capacity — someone can own the host and bridge

If any of those is false, Electron (or Tauri) probably wins. yyzTools happened to clear all four, so the C++/WebView2 path was correct here. It would be wrong for a cross-platform app, or a resident app with no native API needs, or a team of pure-frontend devs.

The takeaway

"Electron vs native" isn't a moral question—it's a fit question. The reflexive "always Electron" is wrong for resident, native-heavy, Windows-targeted tools. The reflexive "never Electron" is wrong for cross-platform or frontend-heavy teams.

The useful question to ask when you start a desktop project: is this app resident, and does it need native system access? If yes to both and you're on Windows, the C++ + WebView2 path is worth the C++ staffing cost. If no, Electron's defaults will serve you faster.

yyzTools is the former. Your project might be the latter. Pick on fit, not on what's trendy.

I'm building yyzTools — a free, local-first Windows productivity suite. Website: yyztools.com. I write about the architecture decisions behind it.