Skip to main content

Why I Build Windows Desktop Apps When Everyone Says ‘Just Use the Web’

Every few years, someone declares that desktop applications are dead. The future is the web, or mobile, or a combination of both. Electron applications — desktop-ish things built with web…

WI
Why I Build Windows Desktop Apps When Everyone Says ‘Just Use the Web’

COVER // WHY I BUILD WINDOWS DESKTOP APPS WHEN EVERYONE SAYS ‘JUST USE THE WEB’

Every few years, someone declares that desktop applications are dead. The future is the web, or mobile, or a combination of both. Electron applications — desktop-ish things built with web technology — represent a transitional compromise. Native desktop development is supposedly a declining skill set that serious developers should be moving away from.

I have been building Windows desktop applications for over twenty years, including throughout every cycle of this declaration. I am still building them. The reason is straightforward: certain problems are solved better by a local application than by a web service, and dismissing the entire category because web applications have become more powerful does not change that.

This article explains why I continue building Windows desktop software in 2026 — including the specific technical and user experience arguments for the approach — and what the applications I have built actually do.

What Web Applications Cannot Do (Yet) That Desktop Can

System-level access

A web application runs in a browser sandbox. It can read and write files through the file picker API (which requires user interaction for each file), can use the camera and microphone with permission, and can access certain device APIs. What it cannot do is query the Windows registry, monitor running processes, access hardware at low level, modify system configuration, or read file system attributes at the depth required for genuine system management tools.

The applications I build for system management — PC cleaning, registry optimisation, disk analysis — require access that is simply not available to a browser. They are desktop applications because the task they perform cannot be done from a browser window.

Performance for local data processing

Processing large files — scanning a drive’s directory structure, analysing audio or video files, processing batch image operations — is significantly faster in a native desktop application than in a browser-based tool that needs to either send the data to a server or work within the browser’s more constrained execution environment.

A desktop application can access system threads directly, can use native Windows media processing APIs, and does not have the memory constraints that browser contexts impose. For CPU-intensive local processing, the performance difference is real and meaningful in the user experience.

Offline operation by default

Web applications can work offline through service workers and cached assets, but offline capability is an add-on to a fundamentally connected architecture. Desktop applications work offline by default — the application and its data are local, and internet connectivity is optional. For users who need software that works reliably without internet dependence, desktop is the architecture that naturally delivers this.

Privacy through local data storage

A web application, by its nature, communicates with a server. Depending on the application, data the user processes may be transmitted to that server — for features that require server-side processing, for analytics, for AI features that require cloud computation. For applications that handle sensitive files, personal media, or private documents, many users prefer processing that happens entirely on their own hardware.

All of the applications I build process data locally. A PDF redaction tool that sends your documents to a cloud server to process them is not the same product as one that does the same processing entirely on your own computer. The distinction matters to users who understand it.

The Technology Choice: VB.NET + WebView2

My preferred stack for Windows desktop applications is VB.NET for the backend logic — system access, file processing, Windows API calls — and a WebView2 control for the user interface, rendered as HTML/CSS/JavaScript inside the desktop application window.

This combination gives the best of both worlds: native Windows system access through the VB.NET layer, and a modern, visually clean user interface through the web rendering layer. The UI can be as sophisticated as any web application, while the system capabilities are fully native.

The alternative architecture I avoid is traditional WinForms or WPF for the UI — both are fine technologies, but web rendering gives more design flexibility and produces interfaces that feel current without requiring expertise in WPF’s data binding model or WinForms’ aging component library.

Electron — the most widely used framework for “desktop” applications built with web technology — is not my choice for Windows-first applications because it ships an entire Chromium instance with each application (adding 100-200MB to the installer size) and does not provide the same depth of Windows system access as a native VB.NET application. For cross-platform applications, Electron makes sense. For Windows-specific tools that need genuine system access, it does not.

The Applications I Build and Why Each One Exists

Each application I have built for the Windows desktop started with a specific problem that existing tools were not solving correctly. A brief overview of the product line:

Aurora PC Cleaner Pro

A PC cleaning and system optimisation tool designed for users who want meaningful cleaning without the risk of breaking their Windows installation. The primary problem with most “free” PC cleaners is that they are either ineffective (cleaning trivial amounts of safe temporary data) or dangerous (removing registry entries that should not be touched). Aurora PC Cleaner targets the real sources of disk waste and performance degradation with a conservative, verified approach.

RegistryCleaner Pro

A dedicated registry maintenance tool that scans for genuinely orphaned and broken registry entries — not just any registry key that looks unfamiliar — and removes only what is safe to remove, with automatic backup before any changes. Built because most registry cleaners either flag too much (creating removal risk) or flag too little (missing real problems).

VividView Pro

An image viewer and browser for Windows. The problem it solves is that modern Windows lacks a capable, fast image viewer with proper format support and a browsing interface that makes sense for large collections. The Windows 11 Photos app is optimised for personal photo management, not professional image browsing. VividView Pro is the viewer for users who need to move through large image collections quickly.

DebmediaCinema

A media player and library manager built for users who maintain local media collections. Designed as an alternative to players that have become bloated or ad-supported, with clean playback, a browsable library, and proper handling of the file formats that most desktop media libraries contain.

AllInOnePDF

A local PDF toolkit covering merge, split, compress, convert, watermark, and rotate operations — all processed on the local machine without sending documents to a cloud service. Built because most PDF tools in this category are either cloud-dependent (privacy concern for sensitive documents) or trial-limited (functionality disabled until you pay per-operation).

DebMedia TS Player

A dedicated player for TS, M2TS, and MTS video files — formats produced by Blu-ray rips, AVCHD cameras, and broadcast recordings. These formats are poorly supported by general-purpose media players. DebMedia TS Player uses LibVLC for playback, providing genuine high-definition support for the formats that matter to this specific audience.

Web App vs Desktop App: When to Use Each

RequirementWeb appDesktop app
Windows system access (registry, processes)NoYes
Large file processing performanceLimitedYes
Offline operation by defaultLimited (service workers)Yes
Multi-user / collaborationYesLimited
Access from any deviceYesNo
Privacy (no data leaves machine)LimitedYes
Installation requiredNo (progressive web app)Yes
Always the latest versionYesRequires update mechanism

Neither column is universally better. The question is which set of trade-offs matches the application’s requirements. For the tools I build — system utilities, media processing, local file management, privacy-sensitive document processing — the desktop column wins clearly. For collaboration tools, content management systems, and anything that needs to work across devices, the web column wins.

The Distribution Model

My desktop applications are distributed as installer packages built with Inno Setup — standard Windows installers that handle the full installation lifecycle including registry entries, start menu shortcuts, and uninstallation. The applications are self-contained and do not require .NET Framework to be separately installed — the runtime is bundled.

This is a deliberate choice: the simplest possible installation experience. One EXE file, click through the setup wizard, application is installed and ready. No account creation. No cloud activation. No requirement to be online at the moment of installation.

Quick Summary

  • Desktop applications remain the right architecture for system-level tools, high-performance local processing, privacy-sensitive applications, and offline-first software — regardless of how capable web applications have become.
  • My stack is VB.NET (for Windows system access and business logic) + WebView2 (for a modern web-rendered UI) — delivering native system capabilities with a contemporary interface.
  • The product line covers: PC cleaning (Aurora PC Cleaner Pro), registry maintenance (RegistryCleaner Pro), image viewing (VividView Pro), media playback (DebmediaCinema), PDF tools (AllInOnePDF), and TS video playback (DebMedia TS Player).
  • Each application exists because existing tools in the category were either broken in a specific way or compromised by business models (ads, cloud dependency, per-operation fees) that underserve serious users.
  • Distribution is via standard Inno Setup installers — no account creation, no online activation, no cloud dependency at installation.

Desktop applications are not going away, and the reasons to build them — system access, performance, privacy, offline reliability — are not going away either. The full product lineup is available here for users who want Windows tools built with that design philosophy.

Let's Talk

Have a Project in Mind?

Whether it's a software challenge, an AI integration, or a course enquiry — I'm always open to a real conversation.

hello@debasisbhattacharjee.com · +91 8777088548 · Mon–Fri, 9AM–6PM IST