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

561–570 of 671 posts

Re: The Codex App

#561

Post by JoBrad »

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…

They don’t look native on Windows, either.

Re: The Codex App

#562

Post by heystefan »

jacksondc wrote: post #447
heystefan wrote: post #212

Earlier quoted context omitted.

I don't think this is true. Try running `/skills` or `/context` in both and you'll see.

Hey, Conductor founder here. Conductor is built on Anthropic's Agents SDK, which exposes most (but not all) of Claude Code's features. https://platform.claude.com/docs/en/agent-sdk/overview

Thanks for clarifying, just wanted to point out it's not 1 to 1 with CC. Happy user of Conductor here btw, great product!

Re: The Codex App

#563

Post by rubymamis »

pitched wrote: post #550
72deluxe wrote: post #532

Earlier quoted context omitted.

But desktop C++ isn't difficult or slow to write... It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe. It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases…

The part that takes time in UI isn’t wiring up components, it’s the small changes like something is a pixel to the right or that gap is two pixels wide. Changing those in a C++ project means recompiling and that adds up to significant overhead over a day of polishing the UI. If C++ was able to get builds out in less than a second, this wouldn’t be an issue. People value performance in their own tools more than the to…

In modern Qt you don't write UI in C++ anymore - you do that in QML. It is far simpler to create amazing pixel perfect UIs with drooling-inducing animations in QML. I wrote a blog post that talks a bit about this[1].

[1] https://rubymamistvalove.com/block-editor

Re: The Codex App

#564

Post by outime »

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…

>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).

Re: The Codex App

#565

Post by rdslw »

markbao wrote: post #317
pama wrote: post #251

Earlier quoted context omitted.

My main take is exactly the opposite. Why not build everything with a simple text interface (shell command) so the models learn to use these tools natively in pretraining. Even TUI like codex-cli or claude code are needless abstractions for such use cases and make full automation hard. You could add as many observability or input layers for humans as you want but the core should be simple calls that are saved in hist…

TUI is easy to train on, but hard to use for users. Part of the reason it’s easier to have LLMs use a bunch of Unix tools for us is that their text interface is tedious and hard to remember. If you’re a top 5% expert in those tools it doesn’t matter as much I guess but most people aren’t. Even a full-featured TUI like Claude Code is highly limited compared to a visual UI. Conversation branching, selectively applying…

all the examples for visual UI, are tasks which already are (or soon be) done by the agent, not human. hence not needed.

I suspect that final(*) UI is much more similar to TUI: being kind of conversational (human AI). Current GUIs provided by your bank/etc are much less effective/useful for us, comparing to conversation way: 'show/do me sth which I just need'. Not to mention (lack of) walled garden effect, and attention grabbing not in the user interest (popups, self-promo, nagging). Also if taking into account age factor. Also that we do not have to learn, yet another GUI (teach a new bank to your mom ;). So at least 4 distinct and important advantages for TUI.

My bet: TUI/conversation win (*).

*) there will be some UI where graphical information density is important (air controller?) especially in time critical environments. yet even there I suspect it's more like conversation with dynamic image/report/graph generated on the go. Not the UI per se.

Re: The Codex App

#566

Post by sbarre »

lurking_swe wrote: post #388
sbarre wrote: post #354

Earlier quoted context omitted.

How are Adobe and Slack/Salesforce doing? Are they hurting for customers?

the people that USE the software the most are not the people BUYING the software. it’s why all enterprise software has trash UX. do you think i as a software engineer like using Jira? Outlook? etc? Heck even the trendy stuff is broken. Anthropic took took 6 months to fix a flickering claude code. -_-

Yes that was my point.

Re: The Codex App

#567

Post by angiolillo »

manuelmoreale wrote: post #539
pimterry wrote: post #512

Earlier quoted context omitted.

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

> it's a tradeoff in development speed Doesn't this get thrown out the window now that everyone claims you can be 10x, 50x, 100x more productive with AI? Hell people were claiming you can ask a bunch of AI agents to build a browser from scratch, so surely the dev speed argument no longer applies.

Even if we assume a developer is actually 10x more productive with AI, if you triple their workload by having them build 3 native apps now you're only 3.33x more productive.

Re: The Codex App

#569

Post by [deleted] »

prodigycorp wrote: post #382
jtrn wrote: post #284

People's mileage may vary, but in my instance, this was so bad that I actually got angry while trying to use it. It's slow and stupid. It does not do proper research. It does not follow instructions. It randomly decides to stop being agentic, and instead just dumps the code for me to paste. It has the extremely annoying habit of just doing stuff without understanding what I meant, making a mess, then claiming everyth…

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…

[deleted]

Re: The Codex App

#570

Post by zaptheimpaler »

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…

Is there any actual problem you have with the application? If not, who cares? Is this the 10 year old Electron is slow and bad meme being trotted out again?
Post reply on HN