Claude Code is much nicer than Pi, especially for long running autonomous work. Pi might be OSS but it's just not nearly as featureful or agentic as Claude Code.
Pi can do all the same that CC can. OSS is nice but the reason to use it is to control what is happening between me and the LLM. See: OP and many others for many reasons, bloated system prompts, the harness changing day to day, Anthropic shipping terrible and untested [features](https://news.ycombinator.com/item?id=48947776) that don't appear in the changelog, Codex ultra subagents nuking usage, etc. You can tell which harnesses are vibe coded.
I agree, but when it comes to the Pi defaults. I’ve spent a good deal of time (admittedly via vibe coding) writing extensions that completely alter the look/feel as well as functionality of Pi.
I view Pi as similar to NeoVim, both programs have kinda crappy defaults that nobody should really use but are incredibly extensible and customizable for power users willing to invest their time into them.
Interesting comparision with NeoVim, given that it was basically created to provide a better default (config) experience than classic vim. We might be close to PostNeoVim (or is helix [0] already that?).
No, tables are the right solution: nonoverlapping elements arranged in a sane way that is easy to reason about. The arguments about semantics so everything can be a div are hilarious -- it really doesn't matter.
Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned.
You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign.
The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do.
If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc.
We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
Regarding security: I think this is already managed in the iOS/Android ecosystem. It shouldn't be too difficult to restrict permissions from sites, and has the advantage of possibly allowing accesses for sites you trust.
Regardling difficulty: HTML/CSS is essentially already cross platform UI toolkit. Yes its hard, but Im saying if one were to make it, I dont see why the same UI framework shouldnt work for a desktop application.
True those platforms have security controls, better than what we've ever seen on desktop. Desktop also needs controls like that: to use the system tray, filesystem, hardware, etc. There's at least a work multiplier of 3 for Windows, Mac, Linux. It's just one of many things needed.
Building the web toolkit took enormous effort and it sucks in many ways (see article). Theoretically a new one could be created and could also work for desktop, but there are lots of reasons why that won't happen.
Hard disagree. Lots exist but none are great. Usually layout isn't sane. Another blunder is components are too complex with too many layers. Customization and creating your own components becomes difficult. Often the event system is terrible.
Eg Swing has all those problems, in addition to ugly themes. The uncanny valley resulting from trying to mimic native UI was bad. At least nowadays users don't necessarily expect native looking UI, even browsers don't do it.
It's not a question of can you make a nice UI with it. You can drive a nail with a rock. The high pain needed to be productive with bad tools leads to Stockholm syndrome. People would rather stick with what they know than go through such pain again to learn something new, and rightly so when the new one is likely just as bad in new ways.
Swing layout was bad then (gridbaglayout!) and is bad now. The framework's approach is bad. Components provide min, pref, max sizes that are very often just ignored. Components need a layout mystery object in order to participate. The mechanisms to measure and constrain components sizes and positions is bad. None of the layouts are sane and it's difficult to add your own. 95% of layouts are nonoverlapping components arranged in row and columns, but provided layouts do other things.
Swing was themeable but good luck if you ever try to do it. Customizing an existing theme is too hard. All components have opaque theme objects that are part of the complexity problem I mentioned and often hide functionality and parts you want to customize.
It's easy to shit on everything, but I really think UI could be done much better and that most or all toolkits make big mistakes that hurt productivity and cause a lot of suffering.
But we have more than one OS in the world, how would you think your one framework approach is going to fit in all platform?
We have seen all these framework claimed to be cross platforms and none of them are not able to make it to the top framework being used.
Web is the only "platforms" with some kind of success by abstract everything away so most of the browser display roughly the same things to all users on all OS.
Implement the UI framework at an OS level. The default OS-specific design should live on top of that. If you were to build an OS of the future, there shouldn't be this need for this distinction between web and desktop.
Close! It was 1 dev and 1 artist for a long time. Eventually the runtime and support load became too high and it's slowly grown to 9 people. Running lean was satisfying but exhausting.
Anyone can distribute the Spine Runtimes without a Spine license, but they have to attach the Spine Runtimes license, which means the need for a Spine license is pushed down the line to their users. In this way someone without a Spine license can use the Spine Runtimes in game toolkits/etc without having a license themselves. https://esotericsoftware.com/spine-runtimes-license
That what I imagined as I was reading, the act of breathing and pushing blood around the body just becomes easier when you are fit. (requires less energy)
Your nervous system also becomes more efficient at zapping the right muscles at the right time. The effect of this can be pretty dramatic too. Even a slightly out of sync orchestra just sounds wrong.
This is GREAT! The usability is through the roof, and supporting HN in the same way is super cool. It's similar to Sync but simpler and even better in some ways.
To bring your own subreddit subscriptions into this, use a multireddit:
4) Bookmark the page. Or you can click the tag icon in the upper right to save it. Find it again by clicking the Ledit icon in the upper left, where you can also set it as default.
