Is There a Demand for UI Framework?

FYI, JUCE was initially released 19 years after C++ did. Just wait for 14 years and you'll have your JUCE for Rust.

On a more serious note, GUI development is hard and Rust was neither created by Google, Apple, Microsoft nor any other gigantic tech company. Some things simply take more time, if you cannot put near infinite resources into a project.

2 Likes

Everybody would love this in Rust! Good cross-platform GUI frameworks are hard though; tons of little details and corner cases and quirks to get right. The few existing frameworks that meet your bar (Qt, Swing, ...) are from large development teams working over many years. It's almost a given you need significant commercial intent behind it. I'd love to be proven wrong but I'd be surprised to see the hobbyist/open source community deliver it.

3 Likes

see skia, and the rust bindings

2 Likes

Of course I'm aware that a cross platform GUI is hard and takes time. I guess my point is that it's not just about the language. You can have the best language in the world and it doesn't matter---for desktop applications at least---if the GUI isn't up to it.
You could argue the details. JUCE was created by one person before it was bought by ROLI. But that's probably a unique case. Rust at least has Mozilla behind it, which is more than the D language has had for example. No point in arguing this stuff though. Explaining "why" doesn't change anything.
For most apps I do, it's about language+GUI. Mozilla seems to be throwing resources into the browser with the Firefox thing. If that's the direction they choose, that's fine. I'll just have to stick with C++ for now. If I need a car with four seats, don't try to sell me a car with two seats by telling me how great the engine is.

1 Like

Also see Pathfinder.

For me only a pure Rust GUI that does not depend on external libraries is worth using.
Dynamically linking is too fragile, especially once multiple platforms are involved.

1 Like

I would personally really like a GUI framework in Rust, since it's one of the only languages as performant as C and C++. And I think many other people would also like it.

1 Like

Tauri is exactly that "Electron like thing" without all the JS and Chromium stuff. Tauri takes the output from an HTML, CSS and JS UI and builds a lightweight Rust app from it. In fact, Tauri was created because the authors were frustrated with Electron's bloat.

I'm currently working a project that will use Svelte for the UI on top of a Rust back end/business logic server. If Tauri gets to a usable WASM bundler before my project is complete there could next to no JS in my app, and freedom from the constant JS vulnerability/update mess.

A big reason for my excitement over Svelte and Tauri is the significant investment I have in HTML, CSS, JS and related tooling does not map to existing RUST front end frameworks using html! macro, etc.

Tauri is still quite young, but it is usable now and even has a "WASM Bundler" on the roadmap for Q3 2020.

5 Likes

Hi @travis,

Seed maintainer here. The main Seed apps architecture is based on the Elm architecture, however we will be integrating Hooks (React-like hooks without limitations) and Style (typed and scoped CSS) and Atoms (something like Recoil) that allow us to implement Svelte-like optimizations.

And it would be super nice to have a good UI library for Seed. Also it's easy to work with things like LitElement and WebGL in Seed if you just want to do some experiments.

If it's interesting for you, just join our chat and write the message:
@MartinKavik @rebo https://users.rust-lang.org/t/is-there-a-demand-for-ui-framework/47689/46

Cheers,
Martin

1 Like

@happybeing Yeah, that loop was what I was wondering about. Now, if the data being looped over is a literal (completely immutable), then I could see Svelte compile it into each permutation. It's when things inside of it can change dynamically that makes me unsure how Svelte handles that, if I'm even understanding what Svelte is doing as a compilation step to begin with :slight_smile:

I will need to take some more time to look at it. I've been suffering from a particularly bad episode of burnout from my day job, so I haven't even had any chance to really look into the macro stuff such as syn and quote for reading existing ASTs, and outputting new ASTs, unfortunately.

@Phlopsi

On a more serious note, GUI development is hard and Rust was neither created by Google, Apple, Microsoft nor any other gigantic tech company. Some things simply take more time, if you cannot put near infinite resources into a project.

Mozilla's a pretty decent-sized company, and its only product is Firefox which happens to be a GUI app. It looks like Mozilla's already succeeded in porting parts of Firefox's engines over to Rust, so there might be a slight change that Mozilla will want to weight in, and eventually write a UI for Rust, so that its entire app stack is in Rust.

That said, they might find it beneficial to stick with Qt (I believe they're using Qt anyway) as their multi-platform app GUI framework of choice. Qt's notorious for its licensing, but maybe LGPL2 has made it easier on them.

@jkboyce I agree with GUI frameworks being difficult. Personally, I've always thought that text rendering is difficult. I think the text rendering might actually be the hardest part about this framework; even over efficient renders of the layout.

@s3bk I think I was looking at Pathfinder for rendering SVGs and fonts at one point if my theoretical framework ever got to that point. I'm not totally sure how it goes about rendering in OpenGL because it has a built-in state machine, and it's difficult to write your own rendering code with other libs co-existing if it acts as a black box API as your own code interacting with OpenGL can't reliably know what state the context's FSM is in without making a bunch of expensive queries.

@MartinKavik I haven't had the chance to touch Elm, although I worked at a company that used it. I've been meaning to check it out, and see how it compares to reactive component libraries such as React, LitElement, yew, etc. It looks like Seed is essentially the "seed" to your web app's architecture that's written in Rust, and emits JS, inspired by Elm's concepts. I would like to check Seed out more, but at this time, I've got a lot on my plate for this major deadline for our company's product launch, currently working through the biggest burnout episode I've ever survived (I'm getting old), and somehow haven't managed to write a lick of macro code in Rust thanks to work and burnout. I have read a little here and there about macros though, but I haven't lived it yet, lol.

I must say, this thread is a major success: it answers my question, and does look like there's a demand for Rust-based GUIs out there. It looks like I was wrong about the lack of GUI in the Rust space as there are quite a few exciting projects that are much more mature than I thought. In fact, my project "idea" is late to the game if anything. Sadly, the more I learn about macros, the more it looks like I'm just trying to build a statically/strongly-typed version of LitElement which might not be the answer in Rust.

The current approach is that other components render to a texture and that is used. Or you can turn it around and have pathfinder render into a texture.

This is one of Svelte's strengths. If values used inside the HTML change, it re-enders the things which depend on them. I don't know what goes on under the hood, but it's very nice building stuff in this way. Add Svelte's support for transitions and animation on top, and it becomes easy for anyone to build stuff that is currently reserved for UI framework masters. I even started to build my own components with transitions, something I've never attempted before, and they worked as intended, limited only by the underlying HTML. I created both JS style and Svelte style versions to provide a comparison. Both worked, but the Svelte was simpler and easier to create.

You sometimes have to build your 'variables' in stages so that when X, changes svelte re-calculates y, and since y is in your HTML, the relevant part is rendered. But this is concise and easy to do with the small extension to JS which Svelte provides (look out for $:). It's easy to have functions called reactively too.

Take care with the burnout.

PS re Mozilla, I think they let the Servo (Rust browser engine) team go, and have become more product focused (eg launching a branded VPN). They've downsized a lot because their funding has dried up, having been 90% from Google. I'm hopeful this is a positive change in the long run because I was always unhappy they were a vehicle for Google's poisonous business model, but in the short run it's painful for a lot of good engineers and staff.

1 Like

I'm no sure what you mean by "compile it into each permutation" exactly but it does not sound like what Svelte does.

I'm pretty sure that Svelte:

  1. Compiles your Jasvascript, HTML, and CSS into the minimum required Javascript to make the DOM API calls to get the page looking like what you ordered based on the state data (properties?) it has been given.

  2. Does two way binding from changes in state data to the DOM API calls need to reflect the change in the page and from user interaction events to state data changes.

  3. That binding is said to be compiled into the minimum Javascript required to do the updates to the DOM with "surgical precision". There is no diffing of DOM trees and such to work out what changed, as there is in React, because what can change is known and compiled in at compile time.

As a result Svelte ends up being small and fast compared to the likes of React.

Which in my little Svelte experiments so far seems to be true.

2 Likes

You should check out Tauri, which is Svelte & Rust compatible. We threw together a small project using it not too long ago.

Yes indeed, I'm looking forward to trying it out on a demo project soon...

Do you have something I can look at? I built something recently to learn Rust with a TUI so am thinking of creating a Tauri version.

I've used ftlk-rs and have liked it so far.
https://crates.io/crates/fltk

2 Likes

so happy and amazed that fltk still has legs, as i work for the company where it was written in the mid 90s. And it was primarily the work of one developer who just needed a gui toolkit with better support for opengl... of course it eventually got replaced by qt.

and speaking of qt, i have had a lot of success with rust-qt. i have managed to work around the lack of inheritance for almost all my needs. it is pretty brilliant being able to bring my qt widgets muscle memory to rust!

there is definitely a place for native non-web based gui toolkits for things like cad, media & entertainment apps, etc. whether this gets addressed by one of tge rust native efforts or good bindings is anyone’s guess...

2 Likes

I've enjoyed using gtk-rs. Much of the GUI is described in markup, then you attach handlers in your code. In other languages I've used, this get surprisingly complicated fast, but the type and borrow checkers in rust make it much more manageable. Especially when your program does a lot of its own custom drawing.

The only downside is that it's not cross platform. At least the Mac and Windows versions aren't well supported or a part of the main project.

@s3bk Ah, rendering to a texture could be a good approach. The only caveat I could think of there is text highlighting. Sure, I could overlay the highlight box, but I'd need to inverse/manipulate the color of the highlighted glyphs to something different for them to stand out. I'll take another look at it.

@happybeing I checked out Richard Harris's presentation on Svelte, and it was enlightening. The idea that React isn't really a "reactive" framework (cited by others on the React team), and Svelte's take on converting the declarative developer experience into an imperative one was pretty interesting. I still don't really understand what it's doing under-the-hood, but the results: rendering is several times faster than React to the point where UIs run on embedded devices, and SEO to boot. Pretty neat stuff. I'm not completely sure why Svelte doesn't appear to like observable properties though like every other framework, but I'm sure there's a good reason for it. Yeah, I noticed that with the destiny operator. I had no clue that existed in JavaScript.

That's sad to hear that the Servo team is gone. Google's poisonous business model?

Thanks, I'm taking it one day at a time. I'm on week 6, and still feeling the burnout. Re-learning how to live and function without work being my life 24/7 has felt like an existential crisis.

@ZiCog Ok, so it's just JS -> DOM. No middleman, and the compiler magic is just simplifying the JS down dramatically, right?

1 Like

It doen't exist in Javascript.

In Javascript you can use labels on statements. Terminated with ":". The can be used as labels on loops so that you can "break someLabel" out of the depths of a nested loop to some outer level. There is not "goto" in JS so they are not jump targets.

Svelte has co-opted that syntax to make reactive bindings. Also using the fact that "$" is a valid identifier.

let count = 0;
$: doubled = count * 2;

Svelete is a compiler so it generates the appropriate code to do the binding between "doubled" and "count" from that syntax.

That is my understanding.

1 Like

Of course the magic part about:

$: doubled = count * 2;

Is that it is valid Javascript syntax BUT that "$:" label has no possible use in Javascript. There is no "goto" that could use it.

That means it can be used between the < script > tags in a Svelte module without any possibility of getting confused with any other JS one may write in there.

Pretty cunning.

2 Likes