Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Codex App

openai.com

Post reply on HN
Print view View original

551–560 of 671 posts

Re: The Codex App

#551

Post by ethbr1 »

SPICLK2 wrote: post #527
gbalduzzi wrote: post #462

Earlier quoted context omitted.

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

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.

> multiple more times RAM, CPU, etc.

Part of this (especially the CPU) is teams under-optimizing their Electron apps. See the multi-X speedup examples when they look into it and move hot code to C et al.

Re: The Codex App

#552

Post by ttsalami »

SPICLK2 wrote: post #527
gbalduzzi wrote: post #462

Earlier quoted context omitted.

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

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.

It might be a cynical take, but I don't think there is a single person in these companies that cares about end user resource usage. They might care if the target were less tech savvy people that are likely to have some laptop barely holding up with just Win11. But for a developer with a MacBook, what is one more electron window?

Re: The Codex App

#553

Post by mycall »

vlovich123 wrote: post #469
gbalduzzi wrote: post #462

Earlier quoted context omitted.

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

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.

Cross platform GUIs might does have the same of support and distributed knowledge as HTML/CSS/JS. If that vendor goes away or the oss maintainers go a different direction, now you have an unsupported GUI platform.

Re: The Codex App

#554

Post by nineteen999 »

gloosx wrote: post #451
OlympicMarmoto wrote: post #220

It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blende…

>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…

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.

Re: The Codex App

#555

Post by SPICLK2 »

icoder wrote: post #537
SPICLK2 wrote: post #527

Earlier quoted context omitted.

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.

Especially given how fast things progress, timeline and performance are a tradeoff where I'd say swaying things in favour of the latter is not per definition net positive.

There's another benefit - you don't have to keep refactoring to keep up with "progress"!

Re: The Codex App

#556

Post by falcor84 »

gbalduzzi wrote: post #462
gloosx wrote: post #451

Earlier quoted context omitted.

>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…

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

> You reduce development effort by a third

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

Re: The Codex App

#557

Post by prodigycorp »

sunaookami wrote: post #536
prodigycorp wrote: post #497

Earlier quoted context omitted.

Thx for the correction. Changed a couple weeks ago. https://decodeclaude.com/ultrathink-deprecated/

Nice blog, this post is interesting: https://decodeclaude.com/compaction-deep-dive/ Didn't know about Microcompaction!

If you're a big context/compaction fan and want another fun fact, did you know that instead of doing regular compaction (prompting the agent to summarize the conversation in a particular way and starting the new conversation with that), Codex passes around a compressed, encrypted object that supposedly preserves the latent space of the previous conversation in the new conversation.

https://openai.com/index/unrolling-the-codex-agent-loop/ https://platform.openai.com/docs/guides/conversation-state#c...

Context management is the new frontier for these labs.

Re: The Codex App

#558

Post by rubymamis »

rjh29 wrote: post #485
tombert wrote: post #427

Earlier quoted context omitted.

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and native platform to write GUI apps? Presumably that could abstract away which bullshit Microsoft framework they came out with this week. I haven't touched desktop application programming in a very long time and I have no desire to ever do so again after trying to l…

Qt is still pretty good, but it's dated in comparison to newer frameworks like Flutter and React Native. No hot reloading of changes, manual widget management vs. React where you just re-define the whole UI every frame and it handles changes magically, no single source of truth for state, etc.

That's false, see QML hot reload[1].

[1] https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-...

Re: The Codex App

#559

Post by prodigycorp »

miki123211 wrote: post #549
prodigycorp wrote: post #382

Earlier quoted context omitted.

If you're using 5.2 high, with all due respect, this has to be a skill issue. If you're using 5.2 Codex high — use 5.2 high. gpt-5.2 is slow, yes (ok, keeping it real, it's excruciatingly slow). But it's not the moronic caricature you're saying it is. If you need it to be up to date with your version of a framework, then ask it to use the context7 mcp server. Expecting training data to be up to date is unreasonable f…

TBH, "use a package manager, don't specify versions manually unless necessary, don't edit package files manually" is an instructions that most agents still need to be given explicitly. They love manually editing package.json / cargo.toml / pyproject.toml / what have you, and using whatever version is given in their training data. They still don't have an intuition for which files should be manually written and which…

Agree, especially if they're not given access to the web, or if they're not strongly prompted to use the web to gather context. It's tough to judge models and harnesses by pure feel until you understand their proclivities.

Re: The Codex App

#560

Post by rubymamis »

FooBarWidget wrote: post #507
nine_k wrote: post #487

Earlier quoted context omitted.

Qt means C++. I'll take Typescript over C++ for a GUI task any day. Qt is also pretty memory-hungry; maybe rich declarative (QML) skinnable adaptable UIs with full a11y support, etc just require some RAM no matter what. And it also looks a wee bit "non-native" to purists, except on Windows, where the art of uniform native look is lost. Also, if you ever plan extensions / plugin support, you already basically have it…

I don't get this HN worship of Qt. Have you ever used Qt apps on macOS? They don't feel native at all. They feel sort-of native-emulating in the same way wxWidgets apps on macOS feel: they use native controls but all the little details including design language are off. I'm not saying this is a huge problem for me even if it bothers me personally. But if you're here on HN advocating native over Electron, then it seem…

This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps.

[1] https://get-notes.com/

Post reply on HN