Comparative Study of Popular Desktop Application Development Technologies: Electron, Tauri, NW.js, Flutter for Desktop, and Wails

Introduction

Cross‑platform development remains a hot topic, aiming for "write once, run anywhere" to reduce development cost and accelerate product iteration. Popular solutions include mobile frameworks (React Native, Flutter, Weex), mini‑program frameworks (Taro, Uniapp), and desktop frameworks (NW.js, Electron, Flutter for Desktop, Tauri, Wails).

Desktop Framework Overview

NW.js – Based on Chromium and Node.js, allowing direct Node.js module calls from the DOM. Official site: https://nwjs.io/, GitHub: https://github.com/nwjs/nw.js, language: Node.js + any front‑end framework.

Electron – Combines Chromium and Node.js with IPC communication. Official site: https://www.electronjs.org/, GitHub: https://github.com/electron/electron, language: Node.js + any front‑end framework. Differences from NW.js include entry point (HTML vs. JavaScript) and Node integration method.

Tauri – Uses Rust for the backend and a WebView for the UI. Official site: https://tauri.app/, GitHub: https://github.com/tauri-apps/tauri, language: Rust + any front‑end framework. It offers smaller binaries and lower memory usage.

Wails – Go‑based backend with a WebView front‑end. Official site: https://wails.io/, GitHub: https://github.com/wailsapp/wails, language: Go + any front‑end framework.

Flutter for Desktop – Uses Dart and the Skia rendering engine, providing high performance but requiring careful stability considerations.

Architecture Principles

Modern browsers and Chromium use a multi‑process architecture (browser, renderer, plugin, network, GPU). Electron inherits this model, exposing native APIs in both main and renderer processes and integrating Node.js via IPC.

Key components of Chromium architecture include RenderProcessHost , RenderProcess , RenderView , and ResourceDispatcher .

Electron Process Model

Two main processes: the main process (window management, lifecycle, native APIs) and the renderer process (UI rendering using any front‑end framework).

Tauri Process Model

Also multi‑process: a single main process manages one or more WebView processes.

Inter‑Process Communication (IPC)

Electron uses ipcRenderer.invoke with ipcMain.handle for bidirectional calls, and ipcRenderer.send with ipcMain.on for one‑way messages.

Tauri provides a JavaScript API ( @tauri-apps/api ) that abstracts IPC, allowing direct calls from the renderer.

Practical Comparison: Navigation Launcher

Both Electron and Tauri are used to build a simple launcher (similar to Alfred/Spotlight) that opens URLs based on user input. Core features:

No window frame (borderless).

Dynamic height based on content.

Global shortcut (Ctrl/Command + K) to show/hide.

Keyboard navigation and opening URLs in the default browser.

Implementation highlights:

Electron: configure frame: false in BrowserWindow options; adjust height via IPC from renderer to main.

Tauri: set fullscreen: false and decorations: false in tauri.conf.json ; adjust height using @tauri-apps/api/window API.

Global shortcuts: Electron registers in the main process; Tauri registers directly in the renderer via the JS API.

Packaging

Electron commonly uses electron-builder for multi‑platform builds. Tauri provides a built‑in CLI command yarn tauri build .

Performance comparison (memory usage, binary size) shows Tauri’s advantage over Electron, while NW.js lags behind both.

Conclusion

• NW.js is largely superseded by Electron. • Tauri offers a promising, lightweight alternative with a modern Rust‑based backend, though it has a learning curve. • Electron remains the most widely adopted solution due to its extensive ecosystem and community support, but developers must manage performance optimizations.