Comments URL: https://news.ycombinator.com/item?id=49743333

Points: 2

# Comments: 0

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.

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

> Where is the reasoning in linear regression?

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

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

Comments URL: https://news.ycombinator.com/item?id=49347834

Points: 1

# Comments: 0

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!"

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

Comments URL: https://news.ycombinator.com/item?id=49003247

Points: 1

# Comments: 0

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.

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.

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.

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.

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