Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

131–140 of 279 posts

Re: Advice for the next dozen Rust GUIs

#131

Post by infogulch »

aaaaaaaaaaab wrote: post #105
raphlinus wrote: post #85

Earlier quoted context omitted.

From a computation perspective, UI is fundamentally an incremental computation engine. Most elements are not changing from frame to frame, so you can either recompute and re-render, or be smarter about only propagating deltas. I'd like to propagate those deltas all the way to the GPU, so you reuse lots of things from the previous frame if they haven't been invalidated. I'll be writing about this in considerably more…

Wait, are you talking about deltas as in damage rects?

If I recall correctly, damage rects are a raster-stage optimization that rerenders components only if they have changed ('dirtied') since the previous render. You could extend this concept of 'damage rect' to the next layer down, like React has pursued with the vdom/dom split. If you continue extending the analogy through every layer (raster, layout, scene graph, component hierarchy, data model, ...) all the way down to and including the application interaction model ("user has pressed the E key", "received IO result", ...) and then statically project every interaction model event back up through all the layers to derive a rerender box, then I think you could say damage rects are kinda like deltas. (I think this explanation is mostly reasonable.)

Re: Advice for the next dozen Rust GUIs

#132

Post by nyanpasu64 »

nu11ptr wrote: post #126
xyzzy_plugh wrote: post #84

Earlier quoted context omitted.

This is an extreme exaggeration. The shit you can do with MFC is still frightening, even today.

> The shit you can do with MFC is still frightening, even today. Only vaguely familiar with MFC. Elaborate?

Foxit Reader was (is?) developed using MFC.

Re: Advice for the next dozen Rust GUIs

#133

Post by jollybean »

galangalalgol wrote: post #100
jollybean wrote: post #94

Earlier quoted context omitted.

So the question is, why are we wrangling our UI approach to match the strict nature of software languages? Isn't that kind of upside down? Wouldn't the obvious lack of fit hint at perhaps some kind of fundamental impedance mismatch? While most other techs are not a perfect fit, Rust is a 'worse fit' for the kinds of things we want to do in UI. The 'design objectives' of UI for the most part just do not apply at all.…

I'm pretty sure the mismatch is just that the major ui frameworks were designed for oop languages, not that UI is inherently oo. As the gp said, react type frameworks play fine with languages that have no inheritance. It's just a matter of a few more coming along with the same paradigm(s).

So that's a good point, but I'm not quite sure OO is the issue.

Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components.

I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the place, and then honestly 'what's the point of rust'?

And doing 'observers and events' feels unnatural, as well as the rest of the threading/stateful issues related to GUI.

UI is also about a lot of small details and so the typing->compile->quick check is something that happens possibly more in UI - you have to often 'see' the results you can't just run the test.

I like Rust, but it is a bit of 'Chinese Finger Trap' for smart people, and applying it to UI I think is basically upside down. I mean - fun to reason about and experiment with - but basically just wrong.

I wonder if someone will come up with a language that is the UI version of Rust, with sufficient checking etc.. That would be cool, though I can't even fathom what that might be.

Re: Advice for the next dozen Rust GUIs

#134

Post by lewisjoe »

I like how the ecosystem around Kotlin has approached the problem.

1. The language itself has a way of introducing compiler plugins that lets you express your own tree structures in a succint syntax (comparable to macros in Rust I guess)

2. Then they figured out most UIs are trees and came up with a Flutter-like UI tree declaration API with react-like re-renders. Thus Android Compose was born! This went mainstream because most android devs fell in love with this new way of writing GUI

3. Like flutter, they are slowly exposing Skia (underlying rendering engine) APIs as kotlin wrappers - I guess the project's name is Skiko

4. Now with all these pieces they are building a full-fledged UI toolkit that renders over every platform (including web) - Jetpack Compose

Re: Advice for the next dozen Rust GUIs

#135

Post by hardwaresofton »

xvilka wrote: post #76
hardwaresofton wrote: post #32

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long. It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

Hopefully, not. From my personal experience, Electron and alike applications are slower, larger, and in general have less advanced UI than many Qt or GTK-based (or Windows UI) applications. Nothing can beat good old native GUI frameworks.

Note that I did not make performance claims relative to native!

The “use Qt/GTK/etc” is quite a common refrain on hn, and while I agree all these projects just have not achieved the DevEx that anyone is looking for.

Electron/Tauri and even flutter are easier, and that’s why I think they will win.

AFAIK the real problem is accessibility features which are lacking. The wasteful resource use will be essentially fixed as computers get faster/hold more data, and more devs put even minimal effort into resource usage.

Re: Advice for the next dozen Rust GUIs

#136

Post by boberoni »

hsbauauvhabzb wrote: post #124

What’s actually wrong with electron, or makes electron slow? I feel like every ‘UI frameworks suck’ posts glosses over this, but no real indication of why.

Most complaints about Electron that I see are about memory usage. If you’re running on an old laptop with little RAM, running 3+ Electron apps can start to slow your entire system down.

There’s also a breed of users who are extremely sensitive to the “native feel” of a desktop app. For them, it’s a jarring experience to downgrade to something that is less snappy, but they expect a certain standard of snappiness.

Re: Advice for the next dozen Rust GUIs

#137

Post by josephcsible »

hsbauauvhabzb wrote: post #124

What’s actually wrong with electron, or makes electron slow? I feel like every ‘UI frameworks suck’ posts glosses over this, but no real indication of why.

Because every Electron app is basically its own Web browser with all of the app's code being JavaScript, rather than the app just being native code. Try running Chrome, Edge, and Safari all at the same time and look what that does to your computer's resource usage. Electron apps basically do the exact same thing.

Re: Advice for the next dozen Rust GUIs

#138

Post by liquidnitrogen1 »

Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.

Re: Advice for the next dozen Rust GUIs

#139

Post by magicalhippo »

raphlinus wrote: post #114
magicalhippo wrote: post #113

> What subset of expected text control functionality is provided? Missing from this otherwise great list, is basic system-standard text navigation and editing. I get so annoyed when basic stuff like ctrl+end or ctrl+v doesn't work like they should.

Thanks! I might add that explicitly, but meant it to be included under "keyboard shortcuts according to platform human interface guidelines".

I think explicit might be better, because it goes beyond that. For example, pressing ctrl+v while having text highlighted should replace the text on Windows, but doesn't always with non-native editors.

edit: btw, great article. I've worked on a cross-platform application (Windows, Linux, OSX) which went from using wxWidgets to Qt. Quite painful either way, and while Qt was a fair bit better on OSX at the time we still had to use tons of ifdefs and per-platform configuration.

And while I've been a win32 GUI programmer for decades, I totally get why people reach for Electron or embedded web servers. It's a really hard problem space with lots of trade-offs to be made.

Re: Advice for the next dozen Rust GUIs

#140

Post by moonchild »

pcwalton wrote: post #73
moonchild wrote: post #63

Earlier quoted context omitted.

Even in 2-d, it is nice to have smooth zoom in/out. The only way to do this that I know of that doesn't compromise on quality is to re-render every frame, and the only way I know to do that fast is to use the gpu. I believe pathfinder can do it (correct me if I'm wrong). I know I'm working on something that can do it too. Moving a bit farther from the strictly 'text' realm there are authoring tools for vector graphic…

Honestly, there are so few different glyphs on a typical page, and CPUs are so fast, that it usually isn't that hard to just rerender every glyph on CPU and aggressively reuse glyph images in order to hit 60 FPS during pinch zoom, at least for Latin text. CJK may be a different story, but I kind of doubt it. In 2022, smooth font rendering during pinch zoom is yet another case in which we in the software field dropped…

I wouldn't say it 'doesn't matter'. We get by, sure; but that doesn't mean the situation is ideal. On my laptop, if I try pinch-zooming, safari seems to do bilinear scaling, and firefox CPU usage will dramatically spike. The former is noticeably ugly; the latter is bad for battery life, and may stutter if work is being done in the background (laptops and phones don't yet have hundreds of cores).
Post reply on HN