Almost every GUI toolkit does this, it’s nothing React specific. And with the browser you have to know all sorts of complexities to know what it’s actually doing (is this change going to cause a full layout, full paint, etc.)
Personally I think most of the abstractions we’ve tried around GUIs don’t work, and old school frameworks like AppKit are better. They just need some DX love since programming has evolved so much.
> not having such a governing body leads to either divergence or stagnation
Or you do the BDFL model like Python, D, Zig, Odin, etc.
I think it works better. A language that reflects the vision of an individual deeply thinking about the interactions of language features, and being able to say "no" to anyone/everyone has many benefits.
Committees make me think of the Web, C++, Swift, etc., and they have a lot of "odd" decisions that have had a heavy cost. Swift has https://www.swift.org/swift-evolution/, but a lot of ideas with minority support were pushed through by Apple (for SwiftUI mainly), against overwhelming community feedback.
And the Web has had a lot of "duds" when you think of WebGPU, WASM (not saying it's bad, but people clearly want to stop writing TS/JS and they haven't made that a reality yet, at least in a way I'd call "successful"), etc.. Oh and DRM in the browser sucks. I forget the details but I was goofing around with FreeBSD Desktop and couldn't get various things to work due to some browser DRM bullshit. https://en.wikipedia.org/wiki/Widevine if curious.
BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.
Linus stopped scaling sometime in the late 90s - 00s. That's when lieutenants took over more authority, and a more or less informal line of succession formed. BDFLs can promote their own replacements from trusted collaborators who share the vision.
> BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.
Well I mean you're just wrong, you can look at any of those languages (or https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere. But everyone pokes fun at the C++ committee and the wacky shit they cook up.
Design by committee just sucks. Coordinating and working with people is expensive, and a drag. If you have to, you have to, but for many projects you don't and shouldn't. An individual's design is always going to be more cohesive, and we can see it clearly looking at PL history IMO.
> Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere.
Guido stepped down from that role 8 years ago. It now has a 5-member steering council along with the core developers as the primary maintainers and decision makers.
When people talk about "toy" languages they usually mean something that it meant to be played with or learned from. D, Zig, Odin etc. may not be as mainstream or used in industry to the extent Python and C++ are, but they are nonetheless serious programming language projects.
Is using Codex through Pi allowed? I've been a Claude user, but a lot of the things mentioned bother me as well. I see it constantly make mistakes due to (simple) shell aliases, etc..
Not sure I'll actually switch but I'm curious. I've thought about trying to build my own harness and use Codex usage to work through it without spending a fortune on credits.
Yes, you can use your Codex subscription with Pi without any limitations. It supports Codex out of the box. You may need to install extensions for things like tracking usage and limit resets though. Pi only provides basic Codex integration.
Anthropic's subscription is the one that has historically been tough to use with other harnesses, where they have (had?) technical safeguards to ensure your subscription usage was limited to Claude Code CLI, with third party harnesses often implementing workarounds or faking it to use your Claude.ai subscription. Nowadays Jetbrains Air does officially allow using your Claude.ai subscription.
But OpenAI's subscription has seemingly always been available to use in other harnesses without trouble.
There is no stick unlike Anthropic (along with insisting on signing commits and "don't abuse the robot" the reason I started to use OpenAI instead of Anthropic --- not that I am under the illusion they are any less evil overall) but I think now there is starting to be a carrot towards Codex usage since there sessions are "cached forever". I assume if you use Pi you get 12 hours of cache instead.
Using your subscription in 3rd party tools is explicitly allowed for Codex, and disallowed but not really enforced for Claude. There are extensions for Pi that allow you to log in with your Claude credentials, Codex is iirc even built-in.
Yea and no, I mean it was an even worse setup than typical, probably because the person setting it up didn’t have php experience or used an LLM that misinterpreted “route requests from nginx to php” or something too literally and set up a hacky solution.
But my impression isn’t that they set it up in some cheeky way to avoid exploits, it looks like they just asked for nginx to be in front.
And is “hacked in two hours” fair if they had to make it easy for people because their noob setup ended up not being exploitable?
The problem with doing apps on the web is the DOM. It’s wild how much complication browsers will add instead of just adding a new UI rendering method/substrate that doesn’t inherit 30+ years of legacy (remember web apps didn’t even exist for like 15 of those).
The DOM is a slow annoying pile when you want to make actual applications.
> Which GUI toolkits over internet do you refer to?
My point is there is no GUI toolkit for the browser and there should be. They should stop trying to morph the document object model into a platform for delivering applications, let it do documents, and give us something else/new. It'd also be the proper path to the new thing having accessibility support. Instead people raw-dog the GPU for UI and you get no screenreader support.
What they're doing here is a half-assed attempt: letting people draw but using the DOM for accessibility. The worst of both worlds I guess?
Our only hope is for AI to supplant screen readers, and then we can just ship WebGPU apps.
Remember when looking up a restaurant online loaded a full screen flash movie with an outdated menu and loud music you could not stop? The reason why we abolished everything else apart from the DOM was that as soon as we had anything else it just marginalized the open web by not being flexible and adaptable. Active X controls, Silverlight, Flash and Java applets all did more or less what you are requesting while not being fit for mobile.
I don't see how Canvas or WebGPU is any different. People want a way to write high-performance UIs without all the complexity/legacy of the DOM. It makes everything more difficult, and because it makes things easier for browser developers isn't a valid justification to make the user experience worse. The users should drive the technology. I'm sorry this architecture you built almost 30 years ago isn't adaptive enough to meet the needs of your users. Instead they should create a new one for this use case (GUIs/applications) and keep it focused on documents.
> isn't adaptive enough to meet the needs of your users
I imagine if this conversation continues this will be quoted and argued against. My point is that it's not working well. People find workarounds to do amazing things with the browser, but they shouldn't have to. Give developers what they've wanted for 15 years. The various committees and working groups keep missing the mark, by a lot. See WASM, WebGPU shader language, etc., etc.. I'm sure it's more complicated than I realize, but if all you do is fail and disappoint, maybe your governance model and the people involved need some adjustment. Is anyone happy with WebGPU? Is anyone happy with Web Components?
On tvOS if a frame takes too long it just starts skipping frames and runs at 20 FPS. It won't recover after it happens. ThermalState is .nominal, so it's not that. There's also no way to just say "render as fast as possible" so you can measure performance, instead every device does throttling/pacing and it's completely opaque.
Anyway, I've had a developer account for 10+ years, and run into stuff like this constantly where you just can't get things to work properly. The framework isn't used much, so it's probably just broken.
I ported the game to SDL3/Zig and wouldn't you know it I can run continuously at 60 fps.. It's disappointing because I'm on board with targeting a single platform if I can utilize the hardware more effectively and make something special with it. But instead it's constantly an uphill battle of dealing with the opaqueness/brokenness of the platform. If I open a feedback request I'll probably just get told it's a bug, and maybe they fix it next WWDC.
You can most certainly render “as fast possible”. You are probably using a CAMetal layer render target with a delegate that is vsync’d to device refresh. You have to roll your own delegate or render target instead. Apple has a sample project in the Metal framework on how to do this.
Also, the threat to privacy. If I turn on iCloud Private Relay I get bombarded with CloudFlare captchas. It’s so annoying I sometimes turn it off just for that reason.
Having some all knowing entity running the internet has a lot of downsides.
This is something the owners of the website can configure. Private relay actually uses Cloudflare exit nodes, but if the website owner decides to configure their site with maximum protection, captchas is what you’ll get.
And that's the other thing - how can you be sure which parties you have to trust to use a service? We, tech people can sometimes figure it out. The normal consumer doesn't really have a chance.
Personally I think most of the abstractions we’ve tried around GUIs don’t work, and old school frameworks like AppKit are better. They just need some DX love since programming has evolved so much.
reply