hsn915

it feels like the kind of interface a devops engineer who hates AI would design

Grok does the same thing.

We'll discuss a feature implementation with various options for design, settle on one of them, and then it will write in the doc comment all the designs we considered but dropped.

This is weird though.

Obviously the best way to use AI to furnish your CV is to build your own project using AI.

Your comment was reductionist

> Where is the reasoning in linear regression?

The comment you are replying to was meant to expose you to your own reductionism.

It's not very hard to engineer software with these two constraints at the same time:

* Must feel very responsive * Network requests can take up to 500ms end to end

How do you predict without reasoning?

If you are going to advocate against something, the alternative you propose needs to be better in some important area, other than "not that thing".

What is the thing you hate about react, and what is the thing you require in an alternative?

I hate bloat and require lightness, so I use Preact.

I also hate complexity and difficult to read stuff, so when I look at the proposal here, I don't see anything appealing, other than "look! it's not react!"

I only read up to the "Petals around the Rose" exercise. I found it pretty easy to deduce (induce?) but the author is right, there's no general algorithmic method to do it .. except for intelligence.

So, the solution is "AI", and even then it's only a "probably".

I've seen many others on Twitter say that.

Grok Build with Grok 4.5 is the best coding AI agent I have ever had the pleasure of using. Stopped using Fable after it.

I think AIs generally "like" the API surface exposed by Shirei. They seem to understand it pretty well and are able to "vibe code" any kind of UI you ask of them using this framework.

To your general point though, yes, there's a lot of uncertainty about what things it makes sense to build in the AI era. I don't have good answers for what would make sense for 10 years down the road, but at this point of time, I think a project like this actually makes perfect sense.

Now that AI can write the code for us, we need better frameworks and libraries, because a lot of what we have now is quite honestly slop.

You could say that you could get AI to maintain 3 separate codebases of the same application UI, each one targeted to a different platform, and the AI will maintain the feature parity and you won't have to worry about it.

For now, AI can take care of coding, but it does not relieve you of having to pay attention to things. If you create 2 or 3 code bases for the different platforms you target, the maintenance burden still falls on you.

But I don't know for how long the situation will remain like this.

Last year I did not think I'd be using AI for coding. I dug up a few tweets I posted last year saying that LLMs have hit a plateau and will stop improving, and that AI coding is a scam being promoted by charlatans.

> you need to have your entire dataset in memory

Are we talking about displaying tables with billions of entries? I'd like you to show me how retained mode gui scales well with that use case.

Most open source projects are abandoned because the author never finds enough time to work on it or can't muster the focus and attention needed.

It is not true that there is "lack" of human investment in the creation of this. If anything, I spent the last two weeks glued to the screen most of the time, to a degree I have never experienced before, building out all the different areas that lead to this release.

I will not mention the monetary investment because it's not the type that matters here.

Attention, which is arguably the most scarce form of investment, was invested in ample amounts.

Does "immediate mode" mean the UI refreshes at a constant 60fps rate like a video game, redrawing everything all the time?

No.

It means that you build the UI by describing what it should look like now, based on the data / state you own, without referencing any existing "widget" object or trying to manipulate it.

Scale is not about the number of buttons, but the structure of the data.

You have a list of objects, within each objects you have several fields, some of them lists, some of them maps. within some of those sub-items you have other lists and maps, nested arbitrarily.

This would be hell to manage for a retained mode UI. You have to mirror the application data into a widget tree and keep all the elements in sync, all the way down to the arbitrary depths of it.

You'd be writing thousands of lines of code that do nothing but keep your data in sync with widget states. You'd have many one off bugs where one sub field fails to sync in some scenarios. Your only options is to be more defensive: more events, more full-resync. As a result, the codebase is complicated and the application feels slow/heavy, because updating widget states is costly.

In immediate mode, none of that matters. You don't have a parallel widget tree.

That's irrelevant though? I'm not asking anyone to contribute or form a community with me as the leader.

I'm putting out something in the hopes of it being useful for others.

I have several projects in the same git repository which also forms a workspace in Go. Many of the projects in that repo are not public.

Shirei is open source, not open contribution.

You need to have some fonts installed. I think for some reason a bare wine setup either has none, or has fonts that Shirei cannot recognize.

If desktop only is so useless, why are so many people create TUI apps?

Shirei does not use GPU for rendering. It's fully software rendered.

> ebitengine

I have considered using it as a backend, but the blocker for me was how it handles resizing: the window content will stretch while it's being resized.

This is a publish-only mirror repo.

The commit history is the publish history, not the work history.

It's the only thing that can scale to complicated UI

I keep a TODO file where I just write my ideas in free text, and every once in a while I tell claude "I updated the TODO file".

This is basically like queueing up prompt.

I wish Claude Code had a thing like that builtin. Like a "user ideas scratchpad".

The TUI version of ClaudeCode is not even that good compared even to the VSCode plugin.

You have to stop thinking about it as a computer and think about it as a human.

If, in the context of cooperating together, you say "should I go ahead?" and they just say "no" with nothing else, most people would not interpret that as "don't go ahead". They would interpret that as an unusual break in the rhythm of work.

If you wanted them to not do it, you would say something more like "no no, wait, don't do it yet, I want to do this other thing first".

A plain "no" is not one of the expected answers, so when you encounter it, you're more likely to try to read between the lines rather than take it at face value. It might read more like sarcasm.

Now, if you encountered an LLM that did not understand sarcasm, would you see that as a bug or a feature?

My criticism is of the basic architecture, not usability or fitness for a particular purpose.

If a distributed file system is useful, then a properly architectured one is 100x more useful and more performant.

This is upside down.

We need a kernel native distributed file system so that we can build distributed storage/databases on top of it.

This is like building an operating system on top of a browser.

I had a similar feeling expressed in the title regarding ChatGPT 5.2

I haven't tried it for coding. I'm just talking about regular chatting.

It's doing something different from prior models. It seems like it can maintain structural coherence even for very long chats.

Where as prior models felt like System 1 thinking, ChatGPT5.2 appears like it exhibits System 2 thinking.

For some, having an instagram profile with many followers is the accomplishment.

Wouldn't distributed systems benefit from using UDP instead of TCP?