Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

31–40 of 148 posts

Re: I Switched from Flutter and Rust to Rust and Egui

#31
post #13

Earlier quoted context omitted.

Doesn't egui always re-render? I like my idle apps to be doing nothing, I don't want them running their render loop in the background

Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.

I really wish this were built into imgui as a first-class use case instead of requiring a hodgepodge mix of unofficial hacks.

I recall the author posting an imgui update saying this will be an officially supported mode, but AFAIK it's still not the case. Otherwise I would be building all my applications with imgui going forward.

Re-rendering the screen, even if it's fast, incurs a lot of memory bandwidth to draw everything and swap framebuffers etc. Not something you'd like to happen on mobile, in particular. Just because the waste is "small", doesn't mean it's acceptable.

Re: I Switched from Flutter and Rust to Rust and Egui

#33
I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.

Re: I Switched from Flutter and Rust to Rust and Egui

#34

Earlier quoted context omitted.

In the end the WYSIWYG would produce an XML file that you can put under version control. All depends on the UI of the thing your are building, if what you are building only needs to be functional and nobody cares about the UI (that is always the case of internal use software, that needs to have a good UX but who cares if it has the Windows 95 style controls, like machine HMIs, ERP software, etc.) WYSIWYG (like Visual…

But those files are often hard to read and merge. If WYSIWYG really worked well, why aren't more big projects or popular frameworks using it? Why do you think it's become less popular over time?

Because editors stopped trying to do WYSIWYG. It's not that the demand isn't there. They stopped trying about the time monitors went from a couple of quite similar fixed widths of 600/768 to more. Then smart phones came along and really killed the WYSWIG editor. I worked with Silverlight for a year in the late 2000s, and even by then WYSWYG editors were struggling. You sorta still had some for flash and stuff. They were trying to bring back a WYSWIG editor for it (and for WPF in general after silverlight flopped). But it was pretty clunky still. There's a lot of hard problems about how you anchor elements, how things scale, that are much easier to express in code than in a properties panel.

You can see the demand in the sheer number of WYSWYG editors for the web.

But for development, basically all the big players stopped trying or died for other reasons. I just think no-one's got the will to try it.

I think it could be a huge opportunity for someone. Right now, with AI coming to the fore in development, seems to be when it would become absolutely killer for less code orientated people making their own apps by adding/dragging controls around and telling an AI what each control should do. All without a programmer involved. The AI could even "solve" the hard problem of a good responsive WYSWYG editor by making assumptions of how the user probably wants the controls anchored.

So I think that's the market we'll see a WYSWIG editor emerge again for.

Re: I Switched from Flutter and Rust to Rust and Egui

#35
post #33

I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.

Isn't that basically what VDOM is?

Re: I Switched from Flutter and Rust to Rust and Egui

#36
post #33

I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.

I really like Mithril.js (https://mithril.js.org/), which is, IMO, as close as it gets to web IMGUI. It looks a lot like React, but rendering happens manually, either on each event or with a manual m.redraw() call.

Re: I Switched from Flutter and Rust to Rust and Egui

#40
There’s a big advantage to having your whole application in one language. I’m not sure the experience of egui on mobile though but egui is great to use as a developer

Pros

- Solid widget set

- Easy to get started

- Less state management

- Easy to make custom widgets

- Active community and crates (e.g docking view, tables, etc.)

- Fast to build new Ui

Cons

- Harder to do layouts (has multipass and some flexbox crates but still hard and compile loop makes it slow to iterate)

- Bring your own architecture (no restrictions on how you build your app so easy to make spaghetti if you’re not careful)

Egui is currently my favorite Rust UI crate although Slint and iced are also interesting.

Post reply on HN