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

451–460 of 671 posts

Re: The Codex App

#451

Post by gloosx »

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

Re: The Codex App

#452

Post by stitched2gethr »

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…

Perhaps if he was able to get Claude Code to do what he wanted in less time, and with a better experience, then maybe that's not a skill he (or the rest of us) want to develop.

Re: The Codex App

#453

Post by novok »

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…

Devex tooling is so much better in web, you can ship much faster, and speed to market matters more than making a native app. Apple dev tooling and build speed sucks a ton in comparison, and don't get started with windows

Re: The Codex App

#455

Post by eviks »

frumplestlatz wrote: post #390
sbarre wrote: post #354

Earlier quoted context omitted.

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

McDonald’s isn’t hurting for customers either. Doesn’t mean their food is anything a chef ought to aspire to.

McDonald's is renown for speed of service, a bit ironic to compare that to slow apps

Re: The Codex App

#456

Post by eviks »

aurareturn wrote: post #448
frumplestlatz wrote: post #430

Earlier quoted context omitted.

Your mistaking supply-side path dependent outcomes that produce a lack of consumer choice with consumer preference. No consumer prefers slow, bloated, non-native software, but they're stuck with what they can get.

There is competition for Figma. Sketch. There's plenty of competition for VSCode too. Don't forget that these Electron apps outcompeted native apps. Figma and VSCode were underdogs to native apps at one point. This is why your supply side argument doesn't make any sense.

> There's plenty of competition for VSCode too.

But there isn't, not if you include all the extensions and remember the price

Re: The Codex App

#457

Post by mstipetic »

OlympicMarmoto wrote: post #324
embedding-shape wrote: post #306

Earlier quoted context omitted.

> You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/ That's only for Windows though, it seems? Maybe the whole "just write all the rendering yourself using metal/gl/dx" is slightly harder than you think.

The proof that rendering is not _that_ hard because the flutter team did it when they switched off skia (although technically they still use skia for text rendering, I'll admit that text rendering and layout is hard)

How is a fact that someone did something proof that it isn’t hard?

Re: The Codex App

#458

Post by eviks »

blackoil wrote: post #415
jarek-foksa wrote: post #282

Earlier quoted context omitted.

Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years. You will be outcompeted if you waste your time reinventing the wheel and optimizing for stuff that doesn't matter. There is some market for highly optimized apps like e.g. Sublime Text, but you can clearly see that the companies behind them are struggling.

Even with SublimeText, most popular IDE is VSCode, most popular interface design tool Figma, all popular chat platforms and so on are all electron based. If people were desperate for faster platforms they'll be migrating to them.

> Even with SublimeText, most popular IDE is VSCode

What a weird comparison, one is free, another one is a premium app, of course a lot of people prefer some suffering over paying money

Re: The Codex App

#459

Post by nazgul17 »

tokioyoyo wrote: post #437
FridgeSeal wrote: post #355

Earlier quoted context omitted.

Users care about performance and jank, it’s just that they’ve been successfully forced to shut-up-and-deal-with-it. They’re not involved in purchasing or feedback, and the people that are don’t use it enough to care, or just don’t care. Users who complain about it may as well shout into the void for how much companies take note, but hey, at least we got an ai button now! Atlassian products are a great example of this…

“They just aren’t empowered to feedback about it, or are trained to just sigh and put up with it” is a roundabout way of saying users don’t care about it enough.

Software decisions are often not made by who will use said software.

Re: The Codex App

#460

Post by eviks »

jarek-foksa wrote: post #282
OlympicMarmoto wrote: post #265

Earlier quoted context omitted.

This is another common excuse. You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/ You can just write all the rendering yourself using metal/gl/dx. if you didn't want to write the rendering yourself there are plenty of libraries like skia, flutter's renderer, nanovg, etc

Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years. You will be outcompeted if you waste your time reinventing the wheel and optimizing for stuff that doesn't matter. There is some market for highly optimized apps like e.g. Sublime Text, but you can clearly see that the companies behind them are struggling.

That just means your feedback system is trash if it fails to surface such an obvious and common pain point in user experience. Tough that's an extremely common state of feedback systems. But also, the general computer knowledge isn't that high for every end user to connect some sluggishness in another app to your app wasting ram and causing disk swaps, that eliminates a lot of end user complaints

> reinventing the wheel

what exactly are you inventing by using a framework "invented" decades ago and used by countless apps in all those years?

Post reply on HN