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

121–130 of 279 posts

Re: Advice for the next dozen Rust GUIs

#121

Post by gpm »

c-smile wrote: post #72

> The background for this is that most existing UI toolkits are a poor fit for Rust. Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too. Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on to…

> Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI.

This is actually one thing I think rust has going for it, the procedural macro system makes it possible to embed reasonably arbitrary DSLs in rust.

Re: Advice for the next dozen Rust GUIs

#122

Post by mwcampbell »

Const-me wrote: post #91

On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2.…

> Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future.

I'm reminded of how Windows Presentation Foundation relied on a level of GPU-based 3D acceleration that wasn't yet universally available on non-gamer PCs when Vista came out. This affected my brother when he was in seminary and tried to run the WPF-based Logos 4 Bible software on a budget laptop bought around 2007 (edit: actually 2008 IIRC). By 2011 it got bad enough that I just bought him a new laptop. And he wasn't the only one affected by this; there were others talking about it on the forum for that application [1]. This anecdote has stuck with me as a cautionary tale about us developers failing to put our users first in our technology choices (though I admit it hasn't actually stopped me from using Electron when the pressure to ship is on).

[1]: https://community.logos.com/forums/t/6200.aspx

Re: Advice for the next dozen Rust GUIs

#123

Post by Klonoar »

jreese wrote: post #66
favorited wrote: post #21

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using…

On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit. Similar to the Carbon/Cocoa split, I'm sure we'll see AppK…

The Music.app rewrite is AppKit-based, so it's not unheard of for Apple to still reach for AppKit internally.

Re: Advice for the next dozen Rust GUIs

#125

Post by verdagon »

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).

I suspect the mismatch is actually due to the borrow checker's inability to do various common abstractions such as delegates and observers.

These patterns are quite useful, especially in stateful situations such as GUI. They help decouple observer from observable, and can give an architecture more flexibility in a lot of ways. Alas, the borrow checker isn't very amenable to that sort of style.

Re: Advice for the next dozen Rust GUIs

#126

Post by nu11ptr »

xyzzy_plugh wrote: post #84
tacotacotaco wrote: post #38

Earlier quoted context omitted.

I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.

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?

Re: Advice for the next dozen Rust GUIs

#127

Post by nu11ptr »

akagusu wrote: post #86

> while Electron continues to gain momentum Electron is not gaining momentum, it already is the standard. No matter what people try to invent, it needs to do all Electron does but ways better.

> No matter what people try to invent, it needs to do all Electron does but ways better.

Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.

Re: Advice for the next dozen Rust GUIs

#128

Post by raphlinus »

OJFord wrote: post #107

This seems to implicitly mean low-level GUIs, or GUI frameworks? The only mention of Tauri is 'tao the fork of winit used by'. The article opens: > A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question. I would say if by 'UI toolkit for my application' you just want a way to make…

That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.

Re: Advice for the next dozen Rust GUIs

#129

Post by c-smile »

gpm wrote: post #121
c-smile wrote: post #72

> The background for this is that most existing UI toolkits are a poor fit for Rust. Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too. Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on to…

> Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI. This is actually one thing I think rust has going for it, the procedural macro system makes it possible to embed reasonably arbitrary DSLs in rust.

Rust can be good for implementation of UI system but as a language-behind-UI it is bad - its advantages (e.g. strictness) directly translate to disadvantages in that area.

At the end, main idea of initial Rust design is to be the language with what browser is implemented.

JavaScript (in ES2020 specification) is really good enough as UI automation language. If not JS then TS.

Just in case in Sciter I've added native JSX to JS. JSX is an ergonomic way of defining tree alike literals that used for UI DOM population and patching.

Re: Advice for the next dozen Rust GUIs

#130

Post by nyanpasu64 »

jchw wrote: post #29
pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web. And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way. To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is…

I don't like React: https://news.ycombinator.com/item?id=31981947

> In Cocoa, scroll position is part of the view's state, a mere property of the view. This is simple because the UI itself is stateful.

> In React, scroll position is typically not part of the state from which we project the view. Instead this state is attached to the projection itself (e.g. a HTML node) and we are dependent on the "Memoization Map" to preserve it. So this memoization is now required for the correct functioning of the app. The "pure function" abstraction is leaking.

Post reply on HN