When a desktop app beats a web app

We build far more web apps than desktop ones, and that's the correct ratio — a browser tab is cheaper to ship, update, and support than an installed binary. But a handful of situations still make desktop the right call, and they're specific enough to check for rather than argue about in the abstract.

Offline as the default state, not the exception

A point-of-sale register, a field-service tool, a warehouse scanner app — these run in places where "offline" isn't an edge case you handle with a banner, it's the normal operating condition with occasional connectivity as the bonus. A desktop app with a local database and a sync layer treats that as the default. A web app can get there too, with a service worker and IndexedDB, but it takes deliberate engineering to make "works with no connection at all" actually true rather than "works until the tab reloads."

Hardware a browser only half-trusts

Barcode scanners, receipt printers, card readers, global keyboard shortcuts, direct file-system access — browsers have slowly gained APIs for some of this (WebUSB, WebSerial), but permission prompts and inconsistent support across browsers make them fragile for a tool a business runs every single working hour. A desktop app talks to that hardware directly, without asking a browser's permission model to cooperate first.

Electron vs. Tauri, in practice

Electron ships a full Chromium and Node runtime inside every app, which means a bigger install and more memory used, but also the most mature ecosystem — almost every library and native integration you'd want has already been wired up by someone. Tauri uses the operating system's own webview and a Rust backend instead, which produces a dramatically smaller binary and lower memory footprint, at the cost of a younger ecosystem and the occasional cross-platform rendering inconsistency, since it isn't literally the same rendering engine on every OS the way Electron is.

The tell that you don't actually need desktop

If "offline" in your requirements really means "should survive ten seconds of spotty Wi-Fi," that's a web app problem, solvable with proper caching and optimistic UI — not a reason to take on a separate desktop build, a separate update mechanism, and a separate support burden. We ask the offline requirement to be specific before we agree it justifies desktop: how long, how often, and what happens to unsynced data if the device is lost. Vague answers usually mean a web app was the right call all along.