YHK - yet another hacker news clone

Hundreds of visible controls sounds like more complexity than you want.

Don't know about the other links you've posted, but for photocraft the vast majority of those issues are from the engine that process the image itself, not about the GUI. In fact, as far as I can tell, none of the artcraft apps are that complex in terms of GUI to be slow down by any choice of GUI framework really. There could be performance differences between them, yes, but not so much.

With vectorcraft loading shape libraries can be slow, but this is a background thread.

egui was a great choice given the results; also egui's wasm support is very good, which means artcraft supports wasm; i.e. they can run on a browser.

I see. Not my experience using those apps though. There are bugs but they get fixed.

You can use the UI to figure out your ideal design process manually and then hand it off to a gent next time. The cool thing about those apps is that everything in the UI works headless as well.

It's November and most of these issues were fixed two weeks ago.

This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.

It's ~100MiB each, installs in seconds; I can point my agent at the github repo and it will be able to run it and control the apps; e.g. look at how excel spreadsheets actually render and adjust the layout.

I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).

They are already usable and get better quickly. Are you working for a competitor?

egui has been integrated with AccessKit since a few years now

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.

Doesn't that need a whole new framework with other downsides but the first option lets you use it with how it is designed?

I work on a GUI toolkit professionally. Immediate-mode libraries are cool, but they absolutely in no way shape or form scale better. Having to evaluate and layout the entire UI for every state change is fundamentally not scalable. Doubly so if you need to do this multiple times to reach a steady-state layout like you do in some cases with egui.

They are slow and inefficient especially in a VM where there is no GPU. It doesn't make sense to redraw all screen if only one button has changed.

Apart from the main 3D viewport Blender's UI need don't look that complex. Most of its UI are panels with simple layouts and buttons/sliders/checkboxes. And I bet they don't use their UI library for the main 3D viewport.

I'm beating a dead horse here, but benchmarks aren't a useful way to compare UI frameworks, because:

1. The benchmarks aren't always going to be fair - e.g., in this article they talk about rendering 3,000 rows, but that's an unrealistic benchmark (you'd want to use list virtualization in any framework at that point) that is obviously more favorable to some frameworks over others.

2. Most frameworks are fast enough for most tasks. The performance of a framework is rarely the main issue, but benchmark scores are quantitative and sound objective, so people cling to it.

- "Tree-based data structures are just the bread and butter of Rust." - they are not - they are the opposite of 'bread and butter'. They create nearly impossible problems for borrow checkers. Literally where the borrow checker caps out and can't fulfill it's obligations.

- "shouldn't be declaring your UI with cycles at all." - they are inherently cyclical. Parent/child and handler/emitter relations are very common. You can work around it, but unnaturally.

"Ugly state is exactly what Rust was made for. " - No. Rust forces you into constraints, which have certain paramters.

--> this is the biggest conceit of Rust - that somehow, the 'borrow checker is correct'. It is not. It is a constraint. Having to meet that constraint is in some cases beneficial, but it's mostly just limiting.

The limitation of that constraint and implications is so strong, that it keeps Rust from being mainstream.

- "Event driven and heavily async are neither a Rust strength nor a weakness"

Async in Rust is objectively hard, it's another dimensional of complexity that does not have the same impact in other languages. Asyc does create issues everywhere but not as much as in Rust. Again, another big layer of trickery for not advantage.

- " but JSON is not only "solved" in Rust but the best ser/de libraries I've ever used are in Rust." - then maybe you have never programmed in any other language?

Because the 'best' language for JSON is obviously Javascript/Typescript - and it suites most OO languages extremely well.

The question underlying all of these statements, is why anyone would ever choose Rust in the first place?

Rust brings much greater complexity for no advantage in most cases.

By any objective measure, Rust is just a 'bad choice' for all but a narrow set of things.

I think you have to add both 'developer interest', 'integration with specific libraries' and maybe 'other strategic considerations' in order for Rust to be a rational choice in a lot of cases.

> Ugly state is exactly what Rust was made for. It forces you to tame the ugly state instead of hacking at it and hoping it works.

I'm not an expert on GUIs, but my understanding of them is that the ugly state is sort of inherent to GUI applications and you can't tame it. Ie, everything interconnects with everything else and there's not much you can do about that. This sort of inherently pushes you to a big runtime that manages a lot of stuff for you, which is in line with GUIs being rather expensive generally (ultimately you have to render everything to the screen).