Is There a Demand for UI Framework?

community
1

I've seen a few people ask about the state of UI app development in Rust here and there, and from what I could gather, it sounds like there isn't a mature UI library or framework just yet (although Iced is looking REALLY interesting).

Is this something that the Rust community would like to see one day, or is Rust better-suited for more systems-level stuff such as kernel development and high-performance libraries in the long-run? Given that WASM is a first-class citizen of the Rust toolchain, we always have the browser with yew which is a really neat component-based crate for front-end web dev.

I only ask because I'm building a simple UI library based off of my front-end web dev experience that I've built up over the past 2 years. Rust's macro systems really neat, and my primary motivation to develop some sort of templating language similar to the html! macro in the yew since I've never really worked with abstract syntax trees before.

1 Like
2

I'm very sure that whatever GUI you can think of that can be done in languages like C or C++ could also be done in Rust. Given enough enthusiasm, effort, and time.

Is there any motivation to create a Rust equivalent of Qt or Gtk is another matter.

I don't want to spend any more time creating such 'machine local', 'native' GUIs any more. That need supporting on multiple platforms. The web browser is an amazingly sophisticated engine that can do all of that with cross-platform, remote, support built in.

Or are you proposing to create a Qt/Gtk like UI that compiles to WASM and can be used in a browser?

That might be interesting.

1 Like
3

I agree with you there: the web has a lot of built-in support already, and if you wanted more of a "local" app, there's always the electron framework that'll embed the browser into an application window.

But yeah, with this idea, I was thinking that the framework would be written completely in Rust as an alternative to Qt and Gtk like you were saying. Except the development experience is much more web-like as the views would be DOM elements, event handlers are attached directly to those elements, and views can be styled in a CSS-like syntax, except with stronger typing. This is where the my macro research would pay off, provided I don't go macro-crazy and end up building something that's not very Rust-like at all, which I can definitely see happening.

HTML5/CSS3 is really nice these days, but there are a LOT of ways to do any one thing due to decades of cruft and compatibility which of course naturally happens. Especially when a platform such as "the Internet" exploded in growth like it did lol. I've always thought it'd be fun to come up with my own markup and styling spec that removed all of that cruft, and focused on newer styling patterns. Especially where all styling is truly encapsulated like it is with the shadow DOM spec.

The framework would utilize reactive component methodologies like React, React Native, LitElement, yew, etc. so everything is declaratively-rendered.

If I got far enough, I'd probably write the renderer in OpenGL for starters. Modern OpenGL though, and then once I have enough of it working natively, I'd consider writing a replacement for the renderer in gfx-rs (which I would have to learn, so it's a farcry there). The project would benefit from being able to take advantage of Vulkan/Metal/DX12 where available which would further reduce CPU overhead of rendering stuff. gfx-rs also yields WebGL support which at that point, you have an entire app written completely in Rust that could be built to WASM and completely rendered within a WebGL canvas. This would remove A LOT of browser compatibility problems/bugs as the entire app would render within a WebGL canvas. Capturing keyboard events from the browser/native window would have to be handled with care after a while. I'm honestly not sure about that yet... I'd be more concerned with porting my text OpenGL renderer over from C++ to Rust, and getting the word wrap algorithm to be performant when there are many lines of text to render.

Then, once I have that completed, I'd port the entire ecosystem of the software packages that I've been building and open sourcing initially for LitElement over to this new Rust app stack. That way the Rust app framework basically starts off with a state/validation framework for building forms (this is actually one of my own inventions that I came up with on my own, and it's killer), a router for rendering based off of location, a set of skinnable components for things like textfields, textareas, checkboxes, calendars, etc. Modal popup/slide-out overlay stack manager (works within the DOM-only, but native OS windows could be supported for native desktop builds).

Going further down the web app rabbit hole: it'd be neat to eventually break the rendering architecture up into a client/server architecture which at that point, you kind of have server-side rendering without any additional effort for WebGL deployments. A flag could be added to the built-in link element which would actually render these links as anchor tags into the DOM with the href set up to help with SEO.

Most importantly: an automation framework comparable to WDIO. Now THAT would be really fun to write. I'm honestly more excited to build that and the rest of the dev tools like the Inspect Element dock with the framework than building the framework itself haha. Those devtools windows could be bundled into the app's crate for dev builds, then stripped out in prod. At that point, your DOM tree is now hidden from the end-user if you'd like that layer of security in the browser.

That's a LOT of work for a single person though, but it's some cool pie in the sky to think about. I'm mainly interested in learning about macros, how to use them effectively, and learn more about ASTs.

1 Like
4

That sounds very interesting for sure! Before you reinvent the wheel I just want to make sure you are aware of Flutter (written with Dart) and similar frameworks. Flutter is very similar to what you are describing, it is already somewhat full-featured, and has a large user base. However, I don't think it has SSR in any way shape or form, and I'm not sure what it offers for automation. If you want to make your own framework then go for it :slight_smile:

1 Like
5

Yeah, I saw that the other day. Dart looks interesting as a domain-specific language, and it looks like there's interop support for Rust now as well, so maybe that's the way to go. Especially if it's backed by Google, and they continue to maintain it. Looks like they've got a large userbase, so they're probably going to keep this going strong.

6

Big Flutter fan here, I can at the very least say It's probably the most intuitive tool for making cross platform apps. It has the best consistency between ios and android, and is working towards web, and desktop too. Also there's a Contact manager app called 'Flokk' in the snap store made using Flutter, to demonstrate it's viability on desktop.

1 Like
7

A ton of people would love one. It's just a really big project, so nothing sufficiently-complete exists yet.

https://areweguiyet.com/

3 Likes
8

Anything that is both:

  • lighter than Qt, Gecko or Chromium
  • lighter and safer than Electron
  • more modern than Webkit
  • easier than GTK
  • lighter and cleaner than HTML/CSS
  • more accessible and safer than Java Swing

will be very, very nice to have.

3 Likes
9

Personally, I'd like to see something like QT or wxWindows with these properties:

  • focused on the UI only (no need to support networking, databases, etc)
  • reasonably multiplatform (Windows, Mac, X/Wayland)
  • uses OS's underlying window manager and widgets (I don't mind if my app looks different on different platforms)
  • doesn't have heavy dependencies (like a HTML/browser)
  • permissive licence

Something very close to what I have in mind is vgtk - Rust -- if I could use something like that, I can't imagine why I'd ever need to go back to Electron and (v)DOM based UI engines.

In other words, I'd like to live in a world where each tiny TODO app doesn't require 8-core 4GHz CPU with 8GB of memory. :slight_smile:

6 Likes
10

What's the problem with vgtk ?

11

No problem with it, it just doesn't suit my needs -- it's GTK so it's LGPL and even though it should be fine to use in commercial offerings, company lawyers don't want to be the ones who argue the case in court. Not sure there is a commercial licence.

That said, it'd be fine for my hobby projects. Assuming the Windows support got better (it wasn't a very smooth sailing some time ago when I used it last time.)

12

[OT] I always find this "lawyers lazyness" strange. Do they know that glibc is also LGPL ?

1 Like
13

Any svelte fans here? Just had a quick read about vgtk and it's talk of DOM diffing had me shaking my head as any svelte fans will confirm :wink:

I'm wondering if a svelte style (compile to Rust) approach makes any sense, but it's a bit beyond me.

But having always found building UIs a world of pain, from Windows 1.0 onwards, through early web (when I created a multi standard HTML editor to reduce that pain), to my recent adventures with Svelte, I haven't experienced anything so well suited to the job (or at least my style).

So I would love to see something that worked as well as Svelte but was made for native applications, and of course that makes Rust an interesting adventure.

I can't help wondering if wasm is the bridge here too, but I don't have the depth or vision to say much more at this point.

2 Likes
14

@Coder-256 Flutter looks amazing. At first, I was turned off by needing to learn yet another language just for UI while all of the behavioral stuff would be offloaded to another language (Rust in this case). The thing is, maybe it's not as bad as I'm making it, and honestly, I'd probably need to make heavy use of macros in Rust to the point where I've basically developed my own language (which is probably on the verge of bad macro hygiene). The macro language wouldn't be difficult to adapt to, but then why not learn Dart at that point?

@scottmcm Oh yeah, I think I checked that out in 2018. Looks like a lot of new projects have been added to it since.

@tuxmain A lot of your nice-to-haves align well to the goals for this project:

  • Lighter than Qt, Gecko, Chromium: I've worked with Qt, and it requires a lot of gigs of bandwidth and capacity to download and install. My framework shouldn't require gigs of downloads, although since it's an OpenGL project that needs a window to render its contents into for desktop and mobile builds, it'll require ~190 dependencies as anything using winit or glfw seem to require those which seems to be around 2GB of deps in the /target directory for a bare-minimum OpenGL/Window app. That's per project too, but I don't think the built binary will be bad at all.
  • Lighter and safer than Electron: Nothing interpreted here, and the framework's all in Rust, so it'll leverage Rust's type safety. If I ever get this far, I'd love feedback.
  • More modern than webkit: I'd like to improve things such as the drag-n-drop API a little bit when it comes to serializing metadata and handling events on the touch screen, but I'm not too certain on how to do that yet.
  • Easier than GTK: I think it will be. It should be simple and intuitive to quickly stylize components, or if you'd rather focus more on the app and not its look, others could create crates containing their own components.
  • Lighter/Cleaner than HTML/CSS: This is my favorite part. I've got a rough draft of the styling properties, and it leans everything down to under 40 styling props broken up into 6 or 7 sub-domains for easier organization. It doesn't include transitions or animations yet, but it's lean. You can either absolute-position elements, or not as there's no in-between positioning. If you want relative positioning, there's the transform property. No more display, as every element implements a CSS-grid-like layout for their child elements. This actually eliminates the need to allow elements to define their own dimensions as the layout does this for you. Building 2D games with elements as sprites shouldn't be too difficult as you'd have a layout containing absolute-positioned elements that can be transformed via transform, but it's not designed for that. Styles and ID selectors will be encapsulated, which can make automation a little more tricky, but I've got some design patterns that I think will help a lot with this. All of the semantic HTML elements have been replaced by a single, generic <View> element. You define your own component elements that can contain arrangements of them.
  • More accessible and safer than Java Swing: I haven't worked with Java Swing, but I think the simplicity enforced by Rust's philosophy and framework naturally yield safety as it will encourage things to be simple.

@qaopm Thanks for sharing vgtk. If things go well, then my theorized UI framework has the potential to be blazing fast, but probably not for the initial release, should I get that far. I'd focus on trying to get the design elegance down, and take any passive perf benefits I can get from that. I looked into the VDOM, and it's uncharted territory for me. Hopefully the TODO app example for this framework only takes a 6-core CPU @ 3.2GHz w/ 7.99GB memory and a GTX 970 for minimum specs :slight_smile:

Also, MIT license. Lawyers like MIT licenses, yeah?

@happybeing I haven't checked out svelte yet. One goal of this UI project is to have it work in the web via WASM builds. I don't have a lot of experience outside of the Rust WASM tutorial myself :slight_smile:

2 Likes
15

A new GUI toolkit project pops up every couple of months or so. It's fun! I've got a blog post in the works explaining the Druid vision more fully, and one framing I've thought of is "advice to someone starting a GUI toolkit." One reason to do that is that it would guarantee a large audience.

For this thread, my advice is: if you're serious about this, then spend a lot of time learning as much as you can about existing GUI projects. Why did they make the decisions they made? If something sucks, is it just because in their priorities they haven't got to it yet, or is it because of a deeper architectural issue? There are a lot of hard subproblems in UI; you've touched on a few.

Obviously I have a horse in the race, but it isn't random advice either. If you look at the intro blog for Bevy, you'll see that the author did take this approach, studying and building on existing solutions rather than just going off. I don't think it's a coincidence that Bevy is attracting a lot of attention and excitement.

4 Likes
16

I was skeptical of svelte for a long time.
I think it smacked of "too good to be true" for me, but am halfway through the video on their blog thing here: Svelte 3: Rethinking reactivity

I never realised svelte made use of a compiler to do its "magic". Very interesting. I think a lot of is here can appreciate a good compiler :smiley:

1 Like
17

I think generally people are skeptical because they see it as yet another framework, understandably. In fact it is quite different in various ways, really and fun to learn, great community, and technically well worth having in your toolkit. Anyway, I don't want to go further off topic! I'd love to see something with the synergies of Rust and svelte.

18

FWIW, I looked at svelte pretty closely when I was doing the research for my talk on reactive GUI, and see its advantages clearly. That said, I think it might be very difficult to directly adapt the ideas from svelte into Rust, in large part because of the major role of the compiler in transforming ordinary variable/field accesses into "observable" method calls. The Druid architecture achieves reactivity a different way, where updates to state are ordinary mutations, but "lenses" do a lot of the work of dispatching updates to other components. A valid analysis of SwiftUI is that they also use lenses under the hood, but they're generated using "syntax sugar" from binding keypath notation.

2 Likes
19

What is it with GUIs?

The best software talent in the world has been working on the GUI problem for four decades or more. Major corporations have spent billions on this problem. And still it is a fractured mess of dozens of incompatible solutions. With more coming every year. And they are all sucky in one way or another.

There is still no GUI equivalent of the classic "Hello World!" program from the C white book, that will work in any GUI anywhere, forever.

Even in the browser, probably the most universal, cross-platform, GUI engine we have we find a bewildering array of GUI "frameworks" from jquery to the the new kid on the bock, Svelt.

And it seems that to make use of whatever GUI is in vogue at the time you have to buy into the whole programming language that supports it.

Is this even a solvable problem?

20

Probably not.

2 Likes