Notes

Workflows

Native Desktop Apps | Why a To-Do List Should Not Cost a Gigabyte

Packaged websites made simple tools heavy. What a native stack changes, what it honestly does not, and the numbers from our own Windows build.

Open Task Manager and look past the editor and the design tool. Somewhere in the list is a to-do app holding several hundred megabytes while doing nothing. Taking a note now costs more memory than an entire operating system did in 1999, and the reason is not that notes got harder.

The tax of a packaged website

Most productivity tools on the desktop are websites in a wrapper. The app ships its own copy of a browser engine, usually through Electron, and runs the site inside it. Three such tools open at once means three browsers open at once, each with its own processes, its own cache and its own idle work.

That shows up in four places.

Memory. A board that is doing nothing still holds the engine that draws it.

The delay after a hotkey. The gap between pressing the shortcut and seeing a cursor is where a thought goes missing. A cold start that takes seconds is a system you stop trusting for quick capture.

Battery. Timers, re-renders and analytics pings keep a laptop awake in small, constant ways.

Offline. Many web-first apps pretend to work offline and then fail on the parts they never cached, which is always the part you need on the train.

What a native stack changes

Native does not mean writing in C++ against Win32 any more. The modern middle ground is a compiled language for the program itself and the system's own web view for the window. Ours is Go with Wails, which uses the WebView2 runtime that Windows already has instead of shipping a second browser.

The honest numbers from our current Windows build:

TaskNote 1.0.35
Installer17.9 MB
Program on disk28.7 MB
The Go process, idleabout 31 MB
Bundled browser enginenone, the system one is used

The part we will not dress up: the window is still drawn by WebView2, so there is memory behind it that belongs to that runtime, shared with everything else on the machine that uses it. The gain is real but it is the gain of not shipping a browser, not of drawing pixels by hand.

Why speed is the feature

A capture tool is only used if it is faster than the thought. That sets three requirements.

The window appears at once. A global hotkey opens a note over whatever you were doing, you type, you close it. If that round trip is not quick, you end up writing on paper again.

It works with the network off. Local storage, in our case a SQLite file on your disk, means a train, a basement or an airline seat changes nothing.

It is quiet when idle. A utility sitting in the tray should not be a line item in Task Manager.

What we build on

TaskNote is ours, so treat this as a description rather than a review. The Windows app is a Go program with a SQLite file next to it: notes, boards and reminders on your own disk, no account, no sync, nothing to sign in to. Text is Markdown, the board is a tab away, and a line of a note becomes a card when it turns out to be work.

One thing the local file is not: an encrypted vault. The desktop database is a plain file, which is the right trade for speed and for working with no account, and the wrong one if you need protection from someone with access to the machine. That case is the web app, where notes are encrypted on your device before they reach us.

The short version

A note-taking tool should not compete with your real work for memory. The way back is not nostalgia, it is a compiled program with the system's own web view, a local file for storage, and a hotkey that answers before you have finished the sentence. The rest of that argument is local-first.

windowsperformancelocal-first

Try it in TaskNote
A kanban board next to your notes. Encrypted in the browser, local on Windows.