Hacker News Reader

Comment by virtualritz | Hacker News Reader

The central argument, reiterated countless times through the post is "It does not scale".

To which my reply is: "Who cares, the vast majority of apps do not have complex UIs".

And if they do you can come up with a workaround like e.g. rerun did for egui (outlined in the article).

Case in point: my biggest spare time "prompted" project is a now 500k LOC hybrid 3D modeling app. It uses egui.

I'd say modeling functionality-wise it's somewhere between Grasshopper/Houdini, close to 200 nodes out of the box + any number of custom ones

That gives you an idea about UI: node graph, parameter editing, widget overlays, gizmos. A lot of nodes have custom widgets, ramp or curve editors etc.

It's not a simple UI at all.

But I didn't spent a second on worrying about the performance of egui's approach. And while UI shows up on my per-frame statistics it's negligible.

View on HN

The "who cares if it doesn't scale" attitude sucks if your users suddenly pass the threshold for whatever reason.

A well-engineered product shouldn't have possible states that don't perform well.

There’s a low ceiling on how much complexity users can process in a UI. We hit those limits sometime back in the late 1990s. There’s no benefit to having a UI that can handle 4,000 buttons on screen at a time.

Technically true, but while they might not be onscreen, sometimes you have a thousands of rows that the user can scroll through, and each row might have multiple input widgets. A UI framework should have a good way to handle large scrolling lists.

There are also photo apps where you can scroll through decades of photos.

Also, text editors should be able to handle large files, and filesystem widgets should handle large directories.

AppKit had ways of handling this 30+ years ago. NSTableView can easily handle millions of rows.

With "your users" you mean developers?

When you pick a UI framework you know how your app looks and what 'complexity' means for your UI. And you make an informed choice of which framework you choose based on that.

Or one would hope you do. As that's part of the job of being a software engineer.

If you give that decision to your clanker and it chooses egui a for spreadsheet app: that's still on you. At least for now.

But it's not on egui, either way.

> And you make an informed choice of which framework you choose based on that.

Experience shows that choices made in the beginning of a project are very often reconsidered later when requirements change. In those cases it is nice if you choose for the worst possible outcome, so in this case you choose for a high performance GUI framework which can scale.

Obviously, today you can just write "please rewrite this badly scaling app with that scaling GUI framework" but I think that's outside the scope of the discussion.

How is that outside the scope when the discussion is about a an AI-prompted blog post that is a thinly veiled advertorial for a most likely AI-prompted new GUI crate?

The fact that you can just prompt a UI kit swap should be at the core of the discussion then; wouldn't you concur?

At that point you might as well ask the AI for advice, no discussion necessary.

Reply on news.ycombinator.com