Dec 7th, 2025

---

I’ve been going down a rabbit hole recently. It started with a long Reddit thread about RAM prices, AI, Electron, and whether we should "go back" to native desktop apps. The discussion hit on all the usual tension points: memory bloat, Electron vs native, accessibility, cross‑platform complexity, the web’s dominance, and how AI might change the development.

As a solo developer who builds native cross‑platform apps and cares a lot about performance, I couldn’t just scroll past. I’ve spent the last few years deliberately avoiding the "just wrap it in a browser" path, and I’m currently working on a suite of native apps. The first one, 120 AI Chat, is a fully native AI client for macOS and Windows.

So I wanted to take that Reddit conversation, run it through my own experience, and lay out where I think things actually stand.

How I see "Native" in 2025

People throw the word "native" around loosely, so here’s what I mean when I say it:

• On macOS: Swift/Objective‑C with AppKit or SwiftUI
• On Windows: Win32/WinUI/.NET UI frameworks
• On Linux: GTK/Qt or other OS‑level toolkits
• Compiled binaries, talking directly to OS APIs, not running inside Chromium

To me, "native" isn’t about nostalgia. It’s about:

• Tight integration with the OS
• Low overhead (CPU, RAM, and startup time)
• Predictable performance and behavior
• Respecting the user’s machine instead of assuming there’s always "more RAM somewhere"

In contrast, a lot of modern desktop apps are:

• Web apps written in HTML/CSS/JS
• Bundled with a full browser engine (Electron and friends)
• Cross‑platform mostly because Chromium is cross‑platform

Is this evil? No. Is it wasteful? Often, yes.

Why I still bet on Native (Even as a Solo Dev)

I read comments in that Reddit thread like:

"Time to go back to native, non‑Electron / non‑web browser apps, that do not eat up 400–2000 MB of memory?"

and I just nodded.

Performance and memory actually matter

As a solo dev, every decision I make has to pull its weight. If I can:

• Start in 150 ms instead of 1500 ms
• Use 50–100 MB of RAM instead of 400–800 MB
• Avoid spinning up a full browser engine per window

that’s not just an optimization fetish. That’s:

• Better battery life on laptops
• Less fan noise
• Less "why is my 32 GB machine lagging with four apps open?"

The Reddit thread touched on the culture we’ve developed:

"Nobody does it because the customer can buy more memory, the company can buy more memory, you can just rent a bigger VPS is often the mindset."

This is exactly the mindset I try to avoid. I don’t assume the user can upgrade. I assume they’re running a normal machine with other things going on, and my app is a guest on that hardware.

Native feels right for long‑running apps

120 AI Chat is an AI client you might have open all day while you work. For a tool like that, I care about:

• Staying snappy after hours of usage
• Not constantly chewing RAM or waking the CPU
• Feeling like "part of the system," not a foreign thing living in its own world

That’s much easier to do when your UI layer is lean and close to the OS, not a browser pretending to be a desktop app.

So why did Web/Electron win so much ground?

Because it’s not 1999 anymore, and we all know speed of development and reach matter.

One comment from that thread really captured it:

"You can’t compete with the entire human force and big companies pouring resources and education system in place to learn and use web tools."

That’s a fair point. The web gives you:

• One stack (HTML/CSS/JS/TS) that "just runs" everywhere
• Tons of libraries, frameworks, and design systems
• A huge talent pool of developers who already know the basics
• Easy distribution (the browser is the runtime)

Electron took that and said: "Here, now it’s a desktop app too."

From a company perspective, that’s almost irresistible:

• Already have a web app? Ship a desktop version with minimal extra effort.
• Need cross‑platform? Electron is cross‑platform. Done.
• Need quick iteration? The web toolchain is built around rapid change.

As a solo dev, I won’t pretend that native development is "easier" in raw hours; it isn’t. But I deliberately choose the harder road because the end result is different in kind, not just in degree.

The big web argument: Accessibility and Tooling

The Reddit thread made some strong points in favor of the web that are worth taking seriously.

A web dev wrote:

"HTML are in that way for a specific reason: provide a semantic meaning to many assistance and screen readers… HTML and CSS is a tiny piece of the web universe."

And:

"All the test capability with tools like Playwright are out of question cause you no longer have a way to do automating test on a well known platform pattern."

They’re not wrong. The browser gives you:

• A rich accessibility model (semantics, ARIA, screen readers)
• Text direction handling (LTR, RTL, partial vertical support)
• Built‑in zoom, font scaling, high contrast modes
• A common target for automated UI tests: DOM, selectors, events
• A shared mental model across OSes

And beyond HTML/CSS:

• HTTP, WebSockets, WebRTC
• WebAssembly
• An entire testing ecosystem (Playwright, Cypress, Selenium, etc.)

You get a lot "for free" by building UI in a browser.

Is native really worse at Accessibility and Testing?

This was my favorite part of the Reddit thread: an iOS developer chimed in:

"Well, I’m an iOS dev and build native applications with SwiftUI. All the points you mention are addressed there…

There’s no reason why native should be inferior to web."

I’m very much in this camp.

On modern native platforms:

• Accessibility isn’t an afterthought; it’s baked into the frameworks.

• If you use standard components and label things correctly, you automatically get:

• Screen reader support

• Dynamic font scaling

• Respect for system colors and themes

• RTL support

• UI testing can hook into the accessibility tree (e.g., Xcode UI tests, Windows UI Automation, etc.)

The difference is:

• On the web, all this is unified through the browser.
• On native, it’s platform/framework-specific.

So no, native does not have to be inferior in accessibility or testing. But as a native dev, I have to be disciplined about using the system’s capabilities properly instead of inventing my own weird custom widgets that ignore them.

The RAM thing: Cheap memory made us lazy

One Redditor said bluntly:

"Reality is that relatively cheap memory has made us developers less focused on actually optimizing beyond specific cases."

I agree.

• Memory got cheaper.
• CPUs got faster.
• SSDs got ridiculous.
• So the culture shifted from engineering to shipping.

And now AI is sucking up RAM and VRAM at industrial scale, memory prices are a bit more volatile, and desktop users are watching 16–32 GB machines feel sluggish because each app thinks it’s entitled to a few hundred MB "just in case."

I don’t think we’re going back to the days of 4 MB of RAM and hand‑tuned assembly. But I do think we’re entering a period where software that respects the machine will stand out again.

That’s very much the philosophy I’m baking into 120 AI Chat and the other apps I’m working on:

• Memory budgets are real.
• Start time matters.
• Idle behavior matters.
• "It’s fine, just buy more RAM" is not acceptable.

How AI changes the equation

There was an especially ironic observation in the thread:

"Ironically, the thing that got us in this bad spot, is the solution by itself. I do not manually work on HTML/CSS anymore, this is done by LLMs…

The way we see development has already changed, and the old meta is by itself becoming obsolete."

Historically, one of the strongest arguments for the web was:

• Everyone already knows it
• The ecosystem is massive
• Repeating all that work natively is too expensive

But AI is starting to erode that barrier:

• LLMs can generate SwiftUI, Qt, WinUI, GTK, etc., not just React components.
• AI can scaffold cross‑platform native UIs that respect accessibility best practices.
• You can literally say: "Create a settings window with tabs, full keyboard navigation, screen reader support, and RTL layout" and get a reasonable first pass—even if it’s not perfect.

So if I, as a solo dev, can lean on AI for boilerplate and patterns, the "but building complex native UI is too hard" argument starts to lose some weight.

That doesn’t mean it’s magically easy—but it’s much more reachable than it was even a few years ago.

What I’m building: 120 AI Chat and a native suite

All of this is not just theory for me—I’m actively making the bet.

I’m building a suite of native desktop apps, starting with:

120 AI Chat

A native AI chat client for macOS and Windows.

My goals for it are very much shaped by everything above:

• Native UI on each platform, not a browser wrapper

• Fast startup, low memory footprint

• Responsiveness even with long chat histories and lots of context

• Deep OS integration:

• System theming

• Native shortcuts and menus

• Proper notifications

• Built with accessibility in mind, not as an afterthought

Could I have built it as a web app in Electron and been done faster? Almost certainly.

But then I’d have:

• A generic-looking browser shell
• Hundreds of MB of overhead
• Another copy of Chromium running on your machine
• All the usual trade‑offs I’m explicitly trying to avoid

I’d rather ship something that feels like it belongs on your desktop, not like a webpage squeezed into a native window.

Where I think this is going

After reading that Reddit thread and reflecting on my own work, here’s where I think we’re heading:

1. Native isn’t going away

There will always be:

• Tools that need every ounce of performance (IDEs, DAWs, 3D tools, editors)
• Utilities that need tight OS integration
• Apps users keep open all day where resource usage actually matters

For those, native will continue to be the best tool in the box.

1. The web isn’t going away either

Web tech is unbeatable for:

• Reach (if it runs in a browser, it runs almost everywhere)
• Content and document‑heavy experiences
• Products that live or die on SEO and linkability
• Apps where onboarding friction must be near zero

Electron and similar approaches will remain attractive for "we have a web app and want a desktop version now."

1. We’ll see more hybrid approaches

I think we’ll get more of:

• Native shells with embedded web views for some panels
• Lightweight "runners" with just enough UI engine to handle layout, text, accessibility, but not a full browser
• Native cores with web‑powered extensions or plug‑ins

The interesting sweet spot is:

Native where performance + integration matter, web‑style engines where accessibility + layout + testing matter.

Final thoughts

Reading that Reddit thread crystallized something I’ve been feeling for a while:

• We overcorrected toward "web everywhere, Electron everything."
• Cheap hardware let us be sloppy.
• The pendulum is slowly swinging back toward caring about performance and resource usage again—especially as AI competes for the same hardware.

As someone who builds native cross‑platform apps and obsesses about performance, I’m happy to be on that side of the swing.

Will the web still dominate a huge chunk of apps? Absolutely.

Should everything be a web app wrapped in a browser engine? I don’t think so.

My approach is simple:

• Use native when it lets me build something fast, integrated, and respectful of the user’s machine.

And in the meantime, I’ll keep pushing forward with my suite of native apps—starting with 120 AI Chat—because I genuinely believe there’s still a lot of untapped value in doing desktop the "old‑fashioned" way, with modern tools and modern expectations.

---