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

Open a to-do app on a desktop today and you are usually opening a browser. Not the one with your tabs in it: a second copy, shipped inside the program, started again for every such tool you run. The window you see is a web page in a wrapper, and everything that costs, from the wait after a hotkey to the battery, follows from that.

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.

A second browser per app. Three such tools open at once means three engines running at once, each with its own processes and its own idle work, none of them sharing anything with the browser already open beside them.

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 the window drawn by the WebView2 runtime that Windows already ships, so there is no second browser inside the app.

The honest numbers from our current Windows build:

The part we will not dress up: the window is drawn by WebView2, and the processes it starts for our window hold a few hundred megabytes of their own. Not shipping a browser saves the download, the disk and the update, and it saves nothing at all on memory. Quick to open and honest about its footprint is the claim; light in RAM is not.

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.

What it costs over a year, not on the first day

Install size is the number everyone quotes and the least interesting one. The costs that accumulate are elsewhere.

Updates. A wrapped app ships its browser again with every release. A weekly update cycle on a hundred megabyte bundle is several gigabytes a year down your connection, and on a metered one that is real money. Our installer is 17.9 MB because the engine is not in it; an update is the program, not the program plus Chromium.

Disk, quietly. Several wrapped apps on one machine means several copies of nearly the same browser, each with its own cache directory that grows. Nothing warns you, and the day you look you are missing ten gigabytes with no single culprit.

The runtime question. Using the system's web view moves a dependency rather than removing it: WebView2 has to be on the machine. On Windows 11 it already is, on Windows 10 it usually is, and when it is not our installer fetches it once, after which every app built this way shares that one copy. That is the trade in plain terms: one engine on the machine instead of one engine per app.

Battery on a laptop. Timers, re-renders and background pings keep a machine awake in small constant ways, and a browser engine idling is not free. This is the part hardest to measure honestly, so we will not put a number on it, but it is the reason a tray app that does nothing can still show up in the battery report.

How to tell what you are running

You can check any app on your machine in about a minute, without taking anyone's word for it.

Look at the processes. Open Task Manager and expand the app. A wrapped web app shows a cluster of child processes with a browser's name on them: one for the main window, several for renderers and GPU work. A program drawn natively shows one.

Look at the install size. A hundred megabytes and up for a text tool means a browser came with it. Twenty means it did not.

Time the cold start. Close it completely, open it, and count until you can type. Under a second is a tool you will use for capture; four seconds is a tool you will stop reaching for.

Turn the network off and open it. This is the one that separates a desktop app from a web page in a frame. If the window comes up empty or asks you to sign in, what you have is a browser with the tabs hidden.

None of these are moral failings of the people who build with web technology, and this piece is written by a team that uses it too. They are simply the costs, and knowing which ones you are paying is the point.

The short version

A capture tool earns its place by being there before the thought has finished. The way to that is not nostalgia, it is a compiled program with the system's own web view, a local file for storage, and a window that opens without asking a server first. The rest of that argument is local-first.