So it's not a GUI. In my book a GUI only redraws when something changes, to save the user's power.
Then you won't have to waste cycles deciding which random internet comment from a stranger to believe
Don't know about web. Seems overkill if all you have are GUI widgets. Egui is most useful on top of something more graphical.
Scrolling text is a problem. EGUI isn't good at big text boxes with much offscreen text. That can be worked around.
Afaik nobody is forcing to rerender the ui layer if nothing changes, though. Just render it to a texture and compose … no need to put everything to the same render target?
"egui is not a framework. egui is a library you call into, not an environment you program for."
So I suspect it gives you control on when to redraw and you might eg call it only when user input happens in your app or there's a some other state change that changes what is shown.
It's one pass. As a result, layouts which are ordered left to right and top to bottom work well, but ones which displace or resize items above or to the left don't work well. Egui tries to fix things up on the next frame, thereby getting the effect of a multipass layout system, but sometimes that results in mis-positioning and jitter on alternate frames. As long as you respect that limitation, good results can be obtained.
It needs some kind of dialog builder tool so that you don't have to write code for each dialog box. Someone was working on that about two years ago. Should find that project again. Meanwhile, lots of repetitive code to write.
Note that winit, wgpu, egui, and their friends all have to advance in version lockstep. All those projects routinely make breaking API changes, and when this happens, it takes a month or two before all the others catch up. Again, as long as you know this, it's not too bad. It would be nice to see some of those packages reach version 1.0.