hsn915

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?

In Japan, Wantedly is more popular.

Non-native English speaker here.

I would not understand the last two sentences. Sidle? Tromp? I don't think I've seen these words enough times for them to register in my mind.

"Strode", I would probably understand after a few seconds of squeezing my brain. I mean, I sort of know "stride", but not as an action someone would take. Rather as the number of bytes a row of pixels takes in a pixel buffer. I would have to extrapolate what the original "daily English" equivalent must have been.

There are two issues:

- Hosting a website is not so easy for the average person, even the tech savvy person, specially if you try to learn it now using the way large websites are developed.

- Static site blogs lack interactivity: people can't comment on your blog. You have to post a link to Twitter or HN (here!) and interact with people over there.

- Static site blogs also don't usually let people "subscribe" by email or whatnot, so unless people bookmark your website or follow you on Twitter, they are not going to find your content.

P.S. this is a problem area I'm trying to work on, at least on the technical front.

I think it's native as in "native executable".

GPUI is not "native OS widgets".

Nice story but the places I've seen that make use of services, there's never a "1 server -> 1 team". It's more like 20 services distributed among 3 teams, and some services are "shared" by all teams

I think it was around 2015 when everything was basically AWS and Kubernetes

The turning point might have been Heroku? Prior to Heroku, I think people just assumed you deploy to a VPS. Heroku taught people to stop thinking about the production environment so much.

I think people were so inspired by it and wanted to mimic it for other languages. It got more people curios about AWS.

Ironically, while the point of Heroku was to make deployment easy and done with a single command, the modern deployment story on cloud infrastructure is so complicated most teams need to hold a one hour meeting with several developers "hands on deck" and going through a very manual process.

So it might seem counter intuitive to suggest that the trend was started by Heroku, because the result is the exact opposite of the inspiration.

Oh? I had no idea it could mean #2 until I saw this comment.