[gloosx]

>This requires calling native APIs (e.g., Win32), which is not feasible from Electron.

Who told you that? You can write entire C libraries and call them from Electron just fine. Browser is a native application after all. All this "native applications" debate boils down to the UI implementation strategy. Maintaining three separate UI stacks (WinUI, SwiftUI, GTK/Qt) is dramatically more expensive and slower to iterate on than a single web-based UI with shared logic

We already have three major OSes, all doing things differently. The browsers, on the other hand, use the same language, same rendering model, same layout system, and same accessibility layer everywhere, which is a massive abstraction win.

You don't casually give up massive abstraction wins just to say "it's native". If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that.

[gbalduzzi]

It baffles me how much the discourse over native apps rarely takes this into consideration.

You reduce development effort by a third, it is ok to debate whether a company so big should invest into a better product anyway but it is pretty clear why they are doing this

[SPICLK2]

That might be true (although you do add in the mess of web frameworks), but I strongly believe that resource usage must factor into these calculations too. It's a net negative to end users if you can develop an app a bit quicker but require the end users to have multiple more times RAM, CPU, etc.

[pydry]

>You reduce development effort by a third

Done by the company which sells software which is supposed to reduce it tenfold?

[vlovich123]

There are cross platform GUI toolkits out there so while I am in team web for lots of reasons, generally it’s because web apps are faster and cheaper to iterate.

[falcor84]

> You reduce development effort by a third

Sorry to nitpick, but this should be "by three" or "by two thirds", right?

[eloisant]

The real question is how much better are native apps compared to Electron apps.

Yes that would take much disk space, but it takes 50Mb or 500Mb isn't noticeable for most users. Same goes for memory, there is a gain for sure but unless you open your system monitor you wouldn't know.

So even if it's something the company could afford, is it even worth it?

Also it's not just about cost but opportunity cost. If a feature takes longer to implement natively compared to Electron, that can cause costly delays.

[vintagedave]

> If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that

Value prop of product quality aside, isn't the AI claim that it helps you be more productive? I would expect that OpenAI would run multiple frontends and that they'd use Codex to do it.

Ie are they using their own AI (I would assume it's semi-vibe-coded) to just get out a new product or using AI to create a new product using the productivity gains to let them produce higher quality?

[vintagedave]

On a side note, the company I work for (RemObjects, not speaking on their behalf) has a value ethos specifically about using the native UI layers, and encouraging our customers to do the same. (We make dev tools, a compiler supporting six languages (C#, Java, Go, etc) plus IDEs.)

Our IDE does this: common code / logic, then a native macOS layer and a WPF layer. Yes, it takes a little more work (less than you'd think!) but we think it is the right way to do it.

And what I hope is that AI will let people do the same -- lower the cost and effort to do things like this. If Electron was used because it was a cheap way to get cross-platform apps out, AI should now be the same layer, the same intermediate 'get stuff done' layer, but done better. And I don't think this prevents doing things faster because AI can work in parallel. Instead of one agent to update the frontend, you have two to update both frontends, you know?

We're building an AI agent, btw. Initially targeting Delphi, which is a third party's product we try to support and provide modern solutions for. We'll be adding support for our own toolchains too.

What I fear is that people will apply AI at the wrong level. That they'll produce the same things, but faster: not the same things, but better (and faster.)

[Closi]

It's about consistency - you want to build an app that looks and functions the same on all platforms as much as possible. Regardless of if you are hand-coding or vibe-coding 3 entirely separate software stacks, getting everything consistent is going to be a challenge and subtle inconsistencies will sneak in.

It comes back to fundamental programming guidelines like DRY (Don't Repeat Yourself) - if you have three separate implementations in different languages for everything, changes will be come harder and you will move slower. These golden guidelines still stand in a vibe-code world.

[AdamN]

The gap here is that the company has the money and native apps are so clearly better. With an interactive app a company like OpenAI could really tweak the experience for Android and iOS which have different UX philosophies and featuresets in order to give the best experience possible. It's really a no brainer imho.

[pimterry]

> the company has the money

It's not about money. It's not a tradeoff in cost vs quality - it's a tradeoff in development speed. Shipping N separate native versions requires more development time for any given change: you must implement everything (at least every UI) N times, which drastically increases the design & planning & coordination required vs just building and shipping one implementation.

Do you want to move slower to get "native feel", or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins.

Once feature development settles down, polish starts to matter more and the slowdown becomes less important, and then you can refocus.

[GorbachevyChase]

Wouldn’t maintaining the different UI stacks be something a language model could handle? Creating a new front end where the core logic is already defined or making a new one from an existing example has gone pretty fast for me. The “maintenance“ cost might not be as high as you think.

[outime]

>If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that.

Exactly. Years go by and HN keeps crying about this despite it being extremely easy to understand for anyone. For such a smart community, it's baffling how some debates are so dumb.

The only metric really worth reviewing is resource usage (and perhaps appearance). These factors aren't relevant to the general population as otherwise, most people wouldn't use these apps (which clearly isn't the case).

[theknarf]

React Native is able to build abstractions on top of both Android and iOS that uses native UI. Microsoft even have a package for doing a "React Native" for Windows: https://github.com/microsoft/react-native-windows

It's weird that we don't have a unified "React Native Desktop" that would build upon the react-native-windows package and add similar backends for MacOS and Linux. That way we could be building native apps while keeping the stuff developers like from React.

[reverius42]

There are such implementations for React Native: https://reactnative.dev/docs/out-of-tree-platforms

[realusername]

React Native desktop on Linux isn't a thing, the GTK backend is abandonned.

So if you want a multiplatform desktop app also supporting Linux, React Native isn't going to cut it.

[knoopx]

the three OSes is BS, none of them cares about linux

[nineteen999]

This is such a toy webdev take. It's like you guys forget that the web-browser wouldn't work at all if not for the server half, all compiled to native code.

The browser is compiled to native code. It wasn't that long ago that we had three seperate web browsers who couldn't agree on the same set of standards either.

Try porting your browser to Java or C# and see how much faster it is then. The OS the browser and the server run on are compiled to native code. Sun gave up on HotJava web browser in the 1990's, because it couldn't do %10 or %20 of what Netscape or IE could do, and was 10 x slower.

Not everybody is running a website selling internet widgets. Some of us actually have more on the line if our systems fail or are not performant than "oooh our shareholders are gonna be pissed".

People running critical emergency response systems day in, day out.

The very system you typed this bullshit on is running native code. But oh no, thats "too hard" for the webdev crowd. Everyone should bend to accomodate them. The OS should be ported to run inside the browser, because the browser is "so good".

Good one. It's hilarious to see this Silicon Valley/Bay Area, chia-seed eating bullshit in cheap spandex riding their bikes while the trucks shipping shit from coast to coast passing them by.