follow Follow Thread Here is a fact-based summary of the story contents: Try something different:
Installing Windows apps used to feel exciting. A tiny, 5 MB installer could give you a blazing-fast music player, a rock-solid text editor, a powerful image viewer that opens instantly, and barely touches your RAM. There’s a reason why an MP3 player that rocked 28 years ago still rocks today.
Somewhere along the way, native Windows apps quietly slipped into the background, replaced by Electron, PWAs, and «containerized» web UIs. And Windows users are now left wondering what happened.
What "native" actually meant on Windows
Classic Win32 and UWP defined the look, feel, and speed we took for granted
Credit: Yadullah Abidi / MakeUseOf
On Windows, a «native app» meant it was built directly on the platform’s own frameworks, such as Win32, MFC, .NET with WPF or WinForms, and more recently, UWP (Universal Windows Platform) or WinUI. These spoke the OS’s language, they used the system’s controls, respected its conventions, and leveraged APIs as efficiently as possible.
That’s why so many classic Windows apps feel absurdly fast and lightweight. Tools like Notepad++, Winamp, Paint.NET, foobar2000, Everything Search, and countless others could run smoothly on ancient hardware, open in a blink, and use only a few megabytes of RAM. They ran well on Windows because they were built for it.
Today, a lot of new desktop software is effectively a single-page website wrapped in a desktop shell.
Electron and the web-everywhere mindset
Why developers embraced web tech—and what users lost in the process
Instead of writing a separate app for Windows, macOS, and Linux, developers can now build one web app in HTML/CSS/JavaScript and ship it everywhere thanks to Electron. It bundles a Chromium browser engine and Node.js into a desktop runtime, running web code as a native application.
From a developer’s perspective, this is great for a number of reasons. You only have to maintain one codebase for all three major desktop platforms. You can hire web developers instead of three platform-specific teams. Iteration is faster, UI changes are easier, and there are tons of existing web libraries that make development easier on a familiar stack.
When you consider the advantages, it’s no surprise that so many big-name apps with this route. Slack, Discord, Figma’s desktop client, Obsidian, Notion, and most recently, WhatsApp all lean on Electron or similar web technologies.
So what’s the problem? Convenience for developers should mean they spend time working on features that add value instead of ensuring system compatibility. Except that convenience comes at a direct cost to users.
The performance tax users pay
RAM spikes, sluggish UI, battery drain: the quiet cost of web-wrapped apps
Every Electron app is more or less shipping its own browser. Open multiple Electron apps simultaneously, and suddenly several Chromium instances are sitting in your PC’s memory. On a powerful machine with plenty of RAM, you might not feel a difference. But on a budget laptop or an older PC, the performance hit can be miserable.
Apart from high memory use, programs take longer to open as they wait for the runtime to load, UI elements don’t always look or behave like native controls, system themes and scaling can be hit-or-miss, keyboard shortcuts can be inconsistent, and keeping several embedded browsers running in memory isn’t going to be kind to your laptop’s battery.
Credit: Yadullah Abidi / MakeUseOf
Not all Electron or web-based apps are bad. A classic example is Visual Studio Code. It’s an Electron app, one of the best code editors around, and even the perfect writing app you can use. It’s extremely capable and reasonably optimized for what it does. The point here isn’t to say that Electron is bad; it’s more that this approach has made it easier for developers to stop caring about optimization.
Windows might be encouraging this shift
Tooling that subtly favor web-first apps
Microsoft hasn’t done much to discourage this shift either. In fact, its own technologies have been shifting towards web-based approaches. Edge’s WebView2 lets developers embed the Edge engine directly into desktop apps. The Microsoft Store has tons of packaged web and Electron apps. Even Microsoft’s own products like Teams and elements of the Office ecosystem lean on web technology.
Credit: Yadullah Abidi / MakeUseOf
To make matters worse, traditional Windows UI frameworks are getting increasingly fragmented and confusing. Frameworks like Win32, WPF, UWP, WinUI 3, and MAUI constantly keep changing to the point where it becomes extremely difficult for smaller developers to maintain a separate Windows codebase. If you already know React, why would you waste time fighting XAML? And if the Store happily accepts Electron apps, why fight the platform and make a native tool when you can ship to three platforms at the same time?
Native Windows apps often had a kind of finesse that’s hard to replicate in a world of increasingly generic web UIs. They were tailored to the platform, extracted every bit of performance regardless of the hardware, and integrated well with system features like shell extensions, global hotkeys, file associations, drag and drop functionality, the notification system, and even the taskbar, among other aspects.
The moment you compare any well-made native Windows app to an Electron or web-based counterpart, you’ll instantly notice a big difference in performance, especially on lower-end hardware.
Related
This Windows app is Microsoft’s biggest failure in years
Remember Control Panel? Yeah, I miss it too.
Posts 12 By Amir Bohlooli Jul 2, 2025
There are still excellent native Windows apps being built and maintained today. Tools like Everything Search, ShareX, AutoHotKey, EarTrumpet, and tons of other open-source utilities are living proof that modern native software is still faster, focused, and better integrated into the OS.
Could native Windows apps make a comeback?
Only if users start prioritizing what matters
Native Windows apps haven’t disappeared completely. They’re just being slowly crowded out by the economics of development. Regardless of whether it’s one person or a highly-skilled team of developers, it’s much simpler, more stable, and more secure to maintain fewer codebases. It makes debugging and shipping faster, and for companies, it means they need to spend less money hiring native specialists.
The hardware we own also keeps getting stronger, and somewhere along the lines, it became good enough to tolerate these apps running without affecting the user experience. Besides, when the platform owner itself is embracing web-driven tooling, why wouldn’t an external developer do the same?
For users, however, the result is a desktop full of apps that look similar, eat too much RAM, are slow to start, and behave like browser tabs that forgot they’re living on a PC.
Bringing native apps back isn’t about cracking down on Electron or hating on web technologies. It’s about balance, about more developers choosing a native or hybrid approach where it matters most, and more appreciation for performance as a feature. For software that lives on the desktop, runs all day, or targets power users, performance and good OS integration still matter.
