The tray tax: one Windows suite drops Electron for C++ and WebView2

A developer writing on dev.to has published the architecture rationale for yyzTools, a Windows productivity suite that fuses more than 40 tools into a single install, and it runs on C++/Win32 with Microsoft's WebView2 instead of Electron ^[1][2]. The part worth borrowing is not the framework preference but the operating condition behind it: the app is resident, sitting in the tray and answering Alt+Space for a command palette, clipboard history and OCR, so its footprint is billed continuously rather than at launch ^[3].

The author concedes Electron's default status is rational, given HTML/CSS/JS, cross-platform reach, and VS Code, Slack and Discord as proof it works ^[7]. His objection is arithmetic. Electron bundles a full Chromium per app, which he costs at roughly 200MB of memory and a multi-second startup, tolerable for something you open occasionally and, in his phrasing, a tax you pay every second the machine is on for something that never closes ^[5]. He sets the ceiling plainly: nobody wants a clipboard manager plus launcher eating 400MB of RAM just by being installed ^[6]. That number is about twice his per-app estimate, which is roughly what two separate Electron utilities on autostart would cost ^[1].

WebView2 avoids the bundle by rendering with the Edge engine already installed on the machine, with the runtime shipping in Windows 11 and the installer guiding Windows 10 users ^[8][9]. The claimed return is lower memory with no resident Chromium process, faster startup, smaller disk because the web runtime is shared system-wide, and native work such as file operations, process management, OCR and screen recording staying in C++ rather than crossing a JavaScript bridge on hot paths ^[16]. The structure is four layers: feature pages built with Alpine.js, a zen_api.js wrapper, a WebView2 bridge offering BindSync for synchronous returns and BindAsync for callbacks, and a C++ NativeApi layer over Win32 ^[10]. OCR and app-info use the async path ^[11]. Alpine is about 3KB with no virtual DOM ^[12], and Vite multi-entry gives each feature page its own bundle ^[13].

Now the bill. The C++ side has two JSON paths, hand-rolled strings and boost::property_tree, so the same error field can arrive as the number 0 or the string "0", and the wrapper papers over it with String(res.error) === '0' ^[14]. The author labels that documented debt and notes TypeScript cannot catch it, because it is a runtime contract and every new native method is another chance to drift ^[15]. The bridge itself is hand-written: a method-name-to-callable registry, sync and async variants, and thread marshaling of callbacks back to the UI thread, all of which Electron supplies as mature IPC ^[18]. Windows-only is the biggest constraint, with Mac or Linux requiring Electron or a full Qt port ^[17]. Alpine keeps simple pages cheap but forgoes the React ecosystem ^[19]. And the staffing constraint is real: a pure frontend team cannot extend the native side, and the author says that if you cannot staff Win32, Electron is the pragmatic call ^[20].

Three things to watch. The post quantifies Electron's cost and not its own, offering no measured idle memory or cold-start figure for yyzTools, so the case is structural rather than benchmarked ^[2]. The error-field drift is the defect class to track, since an untyped C++/JS boundary fails in the field rather than in CI ^[14][15]. And the author's own gate is narrow: resident app, Windows target, genuine need for native system access ^[21].