Emerging Rust GUI libraries in a WASM world

https://monadical.com/posts/shades-of-rust-gui-library-list.html

by fork-bomber • 3 years ago

332 217 3 years ago

eslaught7• 3 years ago

I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the other GUI stuff I needed.

WASM demo here if you want to see it (with dummy, and not particularly realistic, profiling data): https://elliottslaughter.github.io/legion-prof-viewer/

For comparison, the UI I'm replacing falls down with about 16 nodes worth of data. (The demo has 8192 "nodes" worth of fake data.)

josephg11• 3 years ago

Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.)

I sincerely hope the web as a whole doesn't move in this direction. The inspectibility of the DOM is one of the web's greatest strengths. Lets not throw that away.

chrismorgan6• 3 years ago

And scrolling is unavoidably all wrong: dragging two fingers from one end of my touchpad to the other should scroll by about four screenfuls, but only manages two thirds of one screenful; a quick swipe should send it dozens of screenfuls, with inertia, but manages even less than that two thirds of a screenful; and these limitations are fundamental due to the web not possessing the right primitives. (Then there are more fixable bugs like that, after focusing the page, you have to move the mouse before scrolling will work.)

And input element behaviour is non-native, which will never be properly fixable since different UAs have different behaviours, some of which cannot be emulated even if you sniff which platform you’re on (e.g. scroll bar grab and drag behaviour when you move far outside the window). (Then there are also simple bugs: holding Left or Right while the range element is focused only bumps the value once, not according to key repeat. And Up and Down don’t work.)

I have written about these things a number of times, fundamental limitations of the pure-canvas approach that make it unavoidably and permanently unsuitable. https://news.ycombinator.com/item?id=33861831 is probably the best thread.

(And just for a bit of fun: the demo can have slightly negative utilisation, drawing outside the box!)

eslaught7• 3 years ago

I have no beef with deferred mode GUIs except that I have yet to see one with the performance characteristics I need.

For what it's worth, egui does have an accessibility layer. I haven't gone to any particular effort to wire it up yet (besides what you get by default): https://github.com/emilk/egui/issues/167

keyle• 3 years ago

That's nothing new with immediate rendering... You can't have great performance and great usability. Not saying I prefer that way, just pointing out the obvious.

flohofwoe4• 3 years ago

If the web API zoo wouldn't be so random it would all be easier. Pretty much all problems on the web (including the Javascript framework churn) are caused by the DOM being too high level, too inflexible and generally too 'black-boxy' to do anything interesting.

Accessibility could be fixed easily if there would be a web accessibility API. There's basically an entire 'middle layer' of web APIs missing, current APIs are either too low level (like WebGL/WebGPU) or too high level (like the DOM).

amelius• 3 years ago

We could build a "DOM" inspector that runs inside the canvas too ;)

kps• 3 years ago

I sincerely hope the web as a whole doesn't move in this direction.

I'm not happy about it, but I think it will.

The inspectibility of the DOM is one of the web's greatest strengths.

Not if you're pushing ads.

echelon2• 3 years ago

Obligatory jaw-dropping egui demo:

https://www.egui.rs/#demo

Egui slaps and is clearly going places.

tristanMatthias• 3 years ago

Got this to crash by change the font size in the font book demo.

Animats• 3 years ago

"Loading..."

I've run it before. I know what it looks like.

I use egui. It's OK. But you have to code up all your dialog boxes in Rust. This is misery if you have fifty dialog boxes and widgets you need. The widget library is weak and the themes are poor. I don't care, because I'm doing a metaverse client, and all the visuals are in the 3D image. The 2D GUI on top is minimal, as is normal for games. So minimal that it disappears completely, like YouTube controls, when you're not using it, to give you a clean 3D world.

(Egui hint: don't use bottom-up layout. Always work top-down, left to right. Egui layout is one pass, and while it tries to look ahead, it's not good at it.)

potamic• 3 years ago

It's pretty lagging for me on a beefy machine with hardware acceleration enabled. What gives?

bschwindHN2• 3 years ago

egui is nice for internal tools, and for quickly creating UIs for games and such, but I don't think I'd ever release a consumer-facing app with it. It has too many quirks compared to a more "native" UI that it can be quite awkward to use interfaces made with it. I'm talking about things like inertial scrolling, text selection, window resizing, etc.

It's certainly nice to work with from a developer's perspective, what could be easier than

    if ui.button("Say hello").clicked() {
        println!("Hello!");
    ]

But it's quite a pain to style if you're particular about typography and pixel-perfect layouts. Between styling an egui app and styling something with CSS (or some flexbox/grid system), I'll take CSS every time.

Still looking forward to how Xilem turns out, and what people build on top of that.

arethuza• 3 years ago

That looks awesome - are there any accessibility features (e.g. supporting screen-readers)?

Kiro• 3 years ago

Are you being sarcastic?

int_19h3• 3 years ago

The first thing I noticed here is that the textbox doesn't have the usual context menu with commands like "Select all" and various IME features. It's not clear whether RTL and bidirectional capabilities are there, and if so, how to use them.

Next I clicked on the combo box, it opens the dropdown, and I try to use arrow keys to navigate it. That doesn't work. Is that because I opened it using the mouse? Nope, still doesn't work if you tab through the widgets and use Enter to open. Looking up items by typing the first few characters doesn't work, either.

This is all really basic stuff that native widgets offer to any app for free on any platform.

rkagerer2• 3 years ago

Thanks!

I don't like how those textboxes get bigger when you click into them.

osener• 3 years ago

What makes egui so fast? I thought immediate mode GUIs have a convenient API at the expense of unnecessary redraws and lower performance.

Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.

flohofwoe4• 3 years ago

This demo produces only a handful of draw calls to the GPU, and even though those draw calls can have hundreds of thousands of triangles, that's still as efficient as it gets.

I guess that egui works similar to Dear ImGui: only (font) texture changes and clip regions (e.g. scroll areas) require a new draw call, and that's typically just a handful to a few dozen draw calls even for complex UIs.

For long lists, Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.

ocornut• 3 years ago

Also try mouse-wheeling in Tracy web version (using Dear ImGui) and opening different panels: https://tracy.nereid.pl/ I think you'll find it to be more reactive and snappier than most traditional toolkits.

ReleaseCandidat3• 3 years ago

I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources.

Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.

birracerveza• 3 years ago

If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful? I understand it can be optimized, but that optimization often comes at a cost which may end up being even more wasteful.

flohofwoe4• 3 years ago

In Spector.js it looks like the demo is using a very small number of draw calls, and those can sometimes have hundreds of thousands of triangles. For old low-end mobile GPUs this might start to become a problem, but it's nothing for the last 20 years of desktop GPUs.

In any case, it looks like a good base for further optimisation to ignore offscreen UI elements early (e.g. not sure if egui has something like Dear ImGui's ListClipper).

LeanderK3• 3 years ago

wow, i am genuinely impressed! super snappy. I wonder whether it could be used to tackle a real pain point of mine. I work a lot with data, visualisations with jupiter notebooks. There are essentially two approaches: matplotlib, which outputs pngs/svgs. The notebooks stay fast but they are not interactive. The other is approaches like plotly, js-based, interactive, very useful but it gets slow really fast. I can not handle a lot of data. It can not handle a lot of plots. A simple, interactive plotting library with a focus on speed would be immensely useful! With python bindings. Could be a fun weekend project. I don't know any rust though, anybody up to collaborate? :P

I bet the canvas approach would not slow-down the notebook.

superdimwit• 3 years ago

Try dear-imgui + implot. There are Python bindings

ivoflipse• 3 years ago

Checkout fastplotlib, which should be quite capable of what you're after and it works great in a Notebook https://github.com/kushalkolar/fastplotlib

Alternatively, try pygfx for ThreeJS graphics in Python leveraging wgpu. It works great in Notebooks through notebook-rfb. https://github.com/pygfx/pygfx

If you're adventurous, figure out how to make pygfx work with webgpu via wasm

eslaught7• 3 years ago

It sounds like you want BokehJS. It was one of the alternatives I was recommended while I was exploring, but for various reasons my particular use case is not so easy to integrate (plus my backend was already in Rust).

https://github.com/bokeh/bokeh

I did do a basic test, and the raw rects-on-screen performance is roughly comparable to my final solution.

LatticeAnimal• 3 years ago

That is unfortunate that Druid was discontinued. I really enjoyed working with it a few months ago.

serial_dev• 3 years ago

Im a Flutter developer, and, though I love Dart, it's still only my second favorite language, so I can't wait for a viable "flutter alternative to emerge in the Rust ecosystem.

mcluck2• 3 years ago

GUI in Rust progresses with unprecedented speed – 3 months in Rust GUI-land is like 3 years in the mortal world.

areweguiyet.rs was started almost exactly 5 years ago. That means it's been about 60 mortal years and we still don't have a definitive solution to GUIs.

KRAKRISMOTT2• 3 years ago

That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity". For GUI programming, there is only one feature that matters: having a fuck ton of well supported widgets for every situation across every platform. Almost everything else is secondary. This is why HTML/CSS, Flutter (and to a lesser extent Qt) are so successful. No end user cares about data mutational elegance when at the end of the day, somebody has to do the unsexy work to maintain and support each individual button, scrollbar, and toggle.

vbezhenar2• 3 years ago

I'd argue that the most successful UI platform is a browser.

And guess what? Browser does not have a fuck ton of well supported widgets. All it does it some button with outdated UI, few inputs nobody really uses and dropdown select suitable only for the most basic uses.

Anything other built on divs with CSS and JS.

And it works.

So my opinion is that it's definitely solid foundations what matters. Rest will come with time from third party libraries.

Klonoar2• 3 years ago

That's because Rust GUI people are like Lispers and functional programmers — too obsessed with doing things correctly "from first principles" and "purity".

That's... entirely wrong and not necessary to paint swathes of developers like.

Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms.

Just because there's not one blessed solution doesn't mean it's not possible to write UIs in Rust today. ;P

klodolph2• 3 years ago

I think that you’re right, and broadly speaking, there’s an inverse correlation between how invested someone is in programming and how invested someone is in the problem domain. Could be Berkson’s paradox at play here, but I think that it’s really a question of opportunity cost—the time you spend becoming a better programmer is time you could have spent learning some problem domain that you could solve with programming.

So you end up with stuff like the image crate (a straight up disaster of a crate—lots of fancy Rust bells and whistles, doesn’t support a bunch of stuff you want to do with images, reading the GitHub bug reports make me feel no hope that the issues will be addressed, ever) and R (a straight up disaster of a language, just a nightmare to write, but full of useful statistics packages, always has the package you need, but the language was made by Satan).

weinzierl2• 3 years ago

Maybe you are right but it sounds a bit like: "For GUI design there is only one feature that matters: having a fuck ton of well supported colors for every situation across every platform." Replace colors with fonts or animated GIFs and you and up in late 90s web design.

imbnwa2• 3 years ago

This must be why the two Rust GUIs I used daily, Neovide (Neovim) and Psst (Spotify) have stagnated as far as addressing visual bugs: they depended on Druid which, according to TFA, is abandonware

wiz21c2• 3 years ago

There are domains where "end users care about data mutational elegance" because, you know what, they care about reliability in a very strong way (not like: hey the web site is down, let's call the devs; more like: there was a bug, let's call the morgue).

Just to say.

But I agree with you: if your work balance is more oriented towards productivity then rust will not help much. For example, I design lots of stuff in python/jupyter/ecosystem first and then port that to rust for the speed and correctness.

berkes• 3 years ago

Almost everything else is secondary.

For any app more complex than a demo "todolist", handling "business logic" is - by far - the most important. Hundreds of widgets that don't do anything, or do it wrong and buggy, are worthless.

"handling business logic" is difficult and, ironically, perpendicular to many frameworks (as in: frameworks make dev/testing/evolving/refactoring of business-logic harder, not easier). A perfect example was (is? IDK) Visual Basic: tons of widgets, a neat builder, but terrible in managing even simple state and handling business-logic. Or React, which is a perfect framework (and paradigm/architecture) for small, or flat apps, but terrible for complex or convoluted apps.

What I see in Rust, is a focus on the stuff beyond mere "providing lots of stuff that can be drawn to screen": how to manage state, react to changes, manage events etc. Which is, the way I see it, why there also are so many frameworks emerging: what architecture and paradigms work best, very much depends on your use-case.

PoignardAzur• 3 years ago

Speaking as someone working on a Rust GUI framework: how dare you say things about me that are completely accurate.

That said, it feels like it's starting to change. Lower-level components are getting stabilized, SlintUI and iced are picking up speed, etc.

calvinmorrison• 3 years ago

That's a great point. If you've had the pleasure of writing anything in GTK/Glib with C, you quickly realize it ain't your mothers C. But like C with a bunch of object oriented casting on top of it .

IshKebab2• 3 years ago

There definitely are people like that (e.g. the Xylem stuff is an attempt to make something "perfect") but a) I don't think there's anything wrong with some people doing that, and b) that clearly isn't why we don't have a 1st class Rust GUI yet.

1. There are unprincipled Rust GUIs, e.g. Egui. It works great.

2. Making a GUI framework is just bloody hard and a ton of work. I think only a small handful of languages have native GUI toolkits. Most just wrap C or HTML.

GTK is 25 years old and Qt is 27 years old. I don't think 5 years is long enough to develop a mature GUI toolkit (unless you have an enormous company backing you maybe).

alkonaut2• 3 years ago

Would there ever be a "definitive" solution to GUIs? Like some canonical "this is how you GUI in Rust"? I mean there are about zero other languages where that has happened, how would Rust be any different? Just for N simple binary choices like immediate/retained, single/cross platform, markup/non-markup, native/non-native controls and so on, you'd quickly end up with 2^N solutions that almost have to coexist because some of those choices are deal breakers for some.

mcluck2• 3 years ago

Of course you'll always have different ways of building UIs depending on circumstances but eventually some consensus will be reached for a default approach.

WinForms used to be the default for Windows, Tk was the default for Linux (or at least that was my impression, I was all in on Windows back then), etc.

For many people, using web tech has become the default if you want to build cross platform UIs. You have the option of building with imgui, Qt, Gtk, etc. but I don't think it's controversial to say that your average dev who wants to make a cross-platform GUI will probably use Electron or an Electron-like.

I really want to have a default for the Rust space. I've even done some work here myself which is why it's surprising to me that we aren't there yet

sophacles• 3 years ago

C was started 50 years ago, and we don't have a definitive solution to GUIs there either. I'm not sure what your point is.

CJefferson2• 3 years ago

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page).

Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.

capableweb• 3 years ago

I'm not familiar with the entire ecosystem but at least egui offers accessibility via AccessKit

CJefferson2• 3 years ago

Thanks. Last time I looked in depth (about 6 months ago), nothing supported accessibility, but you are right, it looks like egui at least has made excellent progress.

I still keep my comment about the article -- I feel discussions of GUIs should talk about this type of thing, as so many people require accessibility support.

jenadine3• 3 years ago

Desktop solutions don't use wasm/canvas for their primary use. Although you can wasm to compile it for web demo, they are primarily meant to be used as native apps outside of a browser.

I know Slint and egui have accessibility support.

eviks2• 3 years ago

There's AccessKit that's integrated in a couple of frameworks (egui is one)

(but hopefully it'd be a temporary step back)

chrismorgan6• 3 years ago

Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice):

The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.

LeanderK3• 3 years ago

this take is a little bit too simplistic. There are use-cases where you are bound to a web-based framework but JS solutions are just not fast enough, e.g. data visualisations via jupyter notebooks. So you're stuck with some horribly slow solutions or non-interactive ones giving you pngs. Since you're plotting data, the text is minimal and the needed dialogs etc. are also minimal (clicking on a point and getting a label) or having a few options to rotate/turn on some features/zoom. And pngs with rendered text is as inaccessible as it gets, although data-visualisation may be fundamentally incompatible with accessibility tools since it is all about seeing stuff.

So I usually produce pngs via matplotlib and only selectively use interactive, js based, visualisations but they are get so unbelievable slow quickly when that your whole tab freezes.

mwcampbell6• 3 years ago

Lead developer of AccessKit here. I know it won't be a panacea, particularly for the non-screen-reader-related problems you point out. And about the performance problem, there's probably no getting away from the despised "enable accessibility" button. But if these types of applications are going to exist despite our wishes to the contrary, then I have to do what I can to make them accessible. It could be the difference between someone being able to do a job, complete a course, or whatever, and not. I have to do what I can to improve the accessibility of the world as it is, not the world as we wish it was.

danShumway12• 3 years ago

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem."

The web does have an accessibility API. It's called the DOM.

What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users and a much laggier less-featured app for users using the accessibility API, because it forces you to always have the accessibility API turned on. It forces you to treat the accessibility API as your default rendering target (and allows you to occasionally make something inaccessible by embedding a canvas element inside of that UI for one or two parts of your app.

And if you can't develop a fast app using the accessibility API, then having a toggle to turn that layer off is not really a solution for that problem. I'm very glad AccessKit exists, it's better than nothing, but that doesn't mean the apps that are using it should be proud of themselves.

low_tech_punk2• 3 years ago

I think Tauri bypassed the a11y challenge by delegating rendering to platform native web engines.

rwalle• 3 years ago

Eh, that's not how it works. Web engines do a great job at providing accessibility for basic stuff, but to make an application and its content fully accessible, you would need to have accessibility as a requirement from the very beginning, make sure every little UI element is accessible (sometimes meaning provide additional fallback content), and constantly test your UI, which is never something that can be automatically added on top of an existing non-accessible UI.

hnon• 3 years ago

I think it's interesting that we take it for granted that accessibility is primarily the responsibility of GUI toolkit developers. I would think that maybe some amount of blame would fall on OS vendors, who have billions of dollars flowing through their organizations, rather than some random open source projects.

If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way.

[0]: I am aware of AccessKit. Where's the OS backing?

vbezhenar2• 3 years ago

I wonder if WebGPU could help with app GUI. I tried to understand how does it work but it seems it's all about triangles, so it's not really clear if it has any benefit over plain Canvas for standard UI approaches.

Cloudef• 3 years ago

Please don't use canvas or webgpu for GUI unless it's a game or other interactive experiment. Webgpu will drop compatibility with hardware and no accessibility, you would have to build everything up from ground again that web browsers already offer with DOM like flutter does by having "overlay DOM" on top of canvas to provide accessibility, and it's kinda janky. Now that's out of the way, sure you can do GUI with webgpu, see for example IMGUI or NanoGUI (NanoVG based).

fulafel• 3 years ago

It would be interesting to get complete apps running there. Wasm-on-GPU seems a reasonable match since there's no OS APIs in Wasm.

eviks2• 3 years ago

Is there a good detailed table with features filter for various frameworks?

For example, maybe you feel that VDOM is pure overhead and want to hide all frameworks that use it.

It's a bit disorienting to read many rather shallow lists with all the various frameworks without a proper convenient way to compare them

preommr• 3 years ago

The biggest problem is that there is no dominant solution. Right now having a rust-based app is a luxury when there are easier albeit 'dirtier' solutions. I don't have to build something in rust and I am dreadfully afraid that I'll spend hundreds of hours building something only for an altenrative to be the emergent solution forcing an expensive rewrite.

TobyTheDog1233• 3 years ago

This may not be the message of the article but as a side-rant:

I really don't understand the use-case for a Rust-based GUI.

Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.

I understand that not every UI needs to be a cross-platform blah blah blah written in TypeJavaReactScriptJS, or a pixel-painted canvas written in Flutter. I also understand there's a use-case for one-off UIs that may not target a browser.

Let's compare it to something like Golang. Fast compile times, similar libraries, garbage collection -- it seems like something more suited for UIs where there are usually a lot more iterations. Worse performance for sure, but Rust also seems more-than-overkill in that regard for the UI use-case.

winstonewert2• 3 years ago

From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll probably hate golang.

We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.

So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.

8note• 3 years ago

If you're going to use electron and all the bad that comes with it, why not just use typescript though?

0000000000100• 3 years ago

Yeah it seems to be a pretty niche use case. The learning curve for Rust is simply too high (my GOD the syntax). You can just get much more done, in less time with a web framework.

I looked into Rust for writing games (including the UI frameworks), but found that the power it provides isn't really worth all the mental overhead. Most games don't really need that much power, particularly if you are using non-realistic graphics. In the event that you do actually need extra optimization, most engines let you hook down into C++ for raw performance.

alpaca1283• 3 years ago

The learning curve for Rust is simply too high (my GOD the syntax)

The syntax isn't even close to being a difficult part of the language, and it's something you get used to very quickly. The Rust syntax just isn't readable for people who don't yet know Rust, just like I find C++ difficult to read.

You can just get much more done, in less time with a web framework.

Sure, you can also get it running even quicker in Python. But when it comes to maintenance I prefer something where the type system wasn't just slapped on top. That said the web does feel like the only fully-featured and truly cross-platform GUI at the moment.

crispinb12• 3 years ago

I really don't understand the use-case for a Rust-based GUI.

For people already writing things (libraries, cli's etc) in Rust who want to add a GUI while staying with the language. No great mystery.

As for a business case, aside from individual developer taste/preference, it's hard to see that there is one outside of niches. System76 found a case for it with their DE. I think there might be a strong case for lightweight Rust GUI frameworks like egui for embedded device displays.

But for mainstream web / desktop / mobile apps? I can't at the moment see what the point would be.

cyber_kinetist• 3 years ago

Things are a bit different in certain graphics app domains, where you need to create complex tools for professionals (think of image editing, 3D modeling, video processing, CAD, game engines, etc.) The users demand all kinds of functionality that requires squeezing the CPU and GPU to the fullest extent. And you have to do this while designing a complex UI with numerous complex controls, and it also needs to be butter-smooth. (Also note that the majority of the low-level APIs/drivers you need to use are in C/C++!) In that case, using languages like Go/Java/Javascript creates more problems than it solves (even if you only write the core in C++/Rust and use bindings.)

virtualritz• 3 years ago

Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.

What about a vector or image editor, a 3D DCC etc?

These are prime example for desktop apps where existing solutions are 100% written in C++.

That's stuff where Rust would be a better alternative if you started work on an app like this today.

In VFX there is a whole initiative by the ASWF to wrap the stack in Rust for starters and possibly have new additions written in that language instead of C++ in the future.

And compiling to WASM and being able to run in a browser (even if only as a single canvas element with all applying limitations) is a great plus.

crispinb12• 3 years ago

I doubt Rust is going to become used for (the GUI layer of) GUI apps far outside of Rust enthusiast circles. To build a widely attractive ecosystem it needs a dominant framework to which enough of the many widget and theming and distribution libraries and tools necessary for broad adoption attach. Rust's culture in this respect is far more Clojure (bolt together your own from a thousand options) than Elixir (just use Phoenix).

I have no doubt Rust will be used as part of many GUI apps via Tauri and others. 1Password shows how successful it can be as the real core of an app that has a separate web-tech GUI layer.

There's enough energy in the Rust ecosystem that I'm sure niche adoption will continue. But all-Rust apps beyond HN/Github-browsing/System76 circles? My guess is it's unlikely.

bsaul• 3 years ago

My guess is Rust is going to experience its first test in the next two years, where the general people will see what it's really good for, and what's it not, because it won't be the "new hot thing" anymore.

Only then we will know if it has chance of really becoming widely used as a general purpose PL.

crispinb12• 3 years ago

If by 'general purpose PL' you mean one used to write mainstream GUI apps, I nearly agree though I'd bet against Rust on that score.

If however you mean one used across a wide variety of industries, software types, and hardware, I think its future is already assured there. My own guess is that Rust will become quite ubiquitous for the performant and stable core of many software systems, with the interactive levels handled by other languages.

Liberonostrud2• 3 years ago

I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.

TobyTheDog1233• 3 years ago

I remember looking into V last year, it seems most of the discussion surrounding it was that it was vaporware.

Is that not the case? It certainly looks nice, but is it ready for use?

brabel4• 3 years ago

The main issue was that V promised automatic memory management like Rust, but without the "trouble" caused by the borrow checker, which is something anyone who knows about the problem more deeply would laugh at.... last I checked, they were still at the same stage as a few years ago with that: "it will be working soon". It will almost certainly always stay there.

iopq• 3 years ago

It's sorely lacking Haskell features, I have sometimes written functions to simplify my code to find out the function signature is several lines of code and MUST use references

    fn apply<A, B, C, G>(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C
    // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
    where
         G: FnMut(A) -> C,
         B: Copy, // for dereferencing
         A: Clone,
    {
         move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }

all this did so I could write in my code

    ...
         .filter(apply(second, i))
    ...

Tozen3• 3 years ago

People should be allowed to have a difference of opinion and like other programming languages, without a swarm or mob of evangelists going on a downvoting party. If others like Rust or Go, that's their preference, but it's not necessary to bully other programmers.

Lots of people like Vlang, so better to accept that. Not everybody is going to prefer or think the same in regards to programming languages.

Liberonostrud2• 3 years ago

What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.

crispinb12• 3 years ago

Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid.

Larger bundle sizes - yes that's still true.

And not all GUIs are web GUIs, so WASM isn't the whole story.

dragonelite• 3 years ago

Yeah played with some Leptos wasm and i believe something simple like their book tutorial was like 335kb or so. Not that shocking and for me personally totally acceptable. I do wish browsers would ship with their std lib for wasm. So wasm is can become more competitive on bundle sizes with Javascript which has its std lib shipped with browsers.

andyp-kw• 3 years ago

My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.

SnowProblem2• 3 years ago

It’s not WASMs fault. Rust produces large binaries for whatever reason and people like to write their WASM in Rust. I’ve ported Rust to equivalent C and it was 25% of the size and similarly for loading times.

belst• 3 years ago

When you ship javascript, the Browser already has a lot of the bigger libraries built in. When you ship rust/wasm, you need to ship all of the basic types like Strings, Vecs, + a lot of the std

_trackno5• 3 years ago

Where did you check that?

If you're talking about Wasm with Emscripten, yes there's a cost of loading the runtime because Emscripten comes bundled with a lot of stuff.

I'm skeptical that just wasm itself was slower or heavier.

devjab• 3 years ago

Did anyone say that something was wrong with typescript? It’s my preferred language these days, in non-tech enterprise you’ll basically have to use it and since it’s good enough for everything, it’s easy to have small teams that can all work together in one language. This means the frontend developer gets to go on vacation (or call in sick) without bringing a laptop. It also means you can easily share in-house libraries and ask each other for ideas/troubleshooting more easily. And so on, there are obviously downsides as well but over all it’s a joy to work with.

That doesn’t mean I don’t want Rust “people” to work on frontend stuff for Rust. Typescript is good, I like using it, but I’d like to have options. If not for anything else, then for Typescript to take the best parts of Rust and use them.

I don’t personally think we’re going to see a massive shift away from a JavaScript world until someone like Microsoft starts driving the change. The amount of resources they pour into Typescript means it’s not likely to leave my world any time soon. But if it did, and something better came along then I’d be happy, not sad.

davidatbu3• 3 years ago

What's wrong with TypeScript.

I love typescript, but, from my PoV, what I miss in typescript is:

- An actually sound type system: This is a big one. Can you figure out why this[0] is unsound?

- I regularly have to do `as ` assertions, and I know it's not because I'm bad at typescript because it's often the recommended solution from cream-of-the-crop tS libraries for certain issues.

- Traits

- new-types

- Algebraic data types: Option and Result. 'nuff said.

- Pattern matching: :cheff's kiss:

[0]

    export function useSetter<T, K extends keyof T>(
      state: T,
      setState: (n: T) => void,
      key: K
    ) {
      return useCallback(
        (val: T[K]) => setState({ ...state, [key]: val }),
        [key, setState, state]
      );
    }

klabb3• 3 years ago

I am glad that there are people looking at GUI from the perspective of Rust. Many Rust idioms and patterns, like ownership and immutability, are very promising for GUI development.

However, this article also confirms an issue I have observed with the Rust ecosystem, which is fragmentation. It would have made me much more excited to see convergence behind one project than 15 different ones. I think Rust enthusiasts, bless their hearts, are often so excited about the puzzle of the language representations, that the output often ends up being more of a POC than a well-maintained library for users. It seems more-than-usual amount of projects are abandoned when the intellectually stimulating honeymoon phase is over. As a prospective user, this is probably fine for small leaf-dependencies, but it’s a major show-stopper for something like GUI.

I’ve never expressed it like this before, but I think there’s a moderately serious issue when a language seduces you away from the domain problem and towards the language itself, even if that is subjectively enjoyable. (In other languages like perhaps Java or C++, the language quirks are at least so dreadful that only masochists are spending more time than necessary on it)

crispinb12• 3 years ago

an issue I have observed with the Rust ecosystem, which is fragmentation.

Absolutely. The fragmentation doesn't matter with all library types, because they don't all need the vast array of associated libraries, tools, common practices etc which mainstream GUI apps lean on.

Wide GUI framework/library adoption needs a head of steam (far more than it needs architectural elegance). Right now I don't foresee this happening with Rust. Not everything is foreseeable, of course.

low_tech_punk2• 3 years ago

I have my popcorn ready for the battle of WebGPU toolkit implementation. That can be a true differentiator between Rust and other languages.

satvikpendem• 3 years ago

I've been using Flutter with flutter_rust_bridge pretty successfully, seems like a few other people I've talked to are as well, would want to see it covered in this article as well.

FL33TW00D• 3 years ago

The creator of egui has founded a pretty cool company, and their flagship application is built entirely using egui: https://github.com/rerun-io/rerun

plaguepilled• 3 years ago

All very exciting to see, but when is crablang going to support this? That's the real meat and potatoes in the memory safe space!

ljsb2• 3 years ago

I hope it's OK to add a shameless plug for my Rust WASM framework, Silkenweb [0]. It's similar to Leptos and Sycamore in that it's signals based, but I've put a lot of effort into making it ergonomic without resorting to a macro DSL. It supports all the usual things like SSR and hydration, along with a few nice extras like scoped CSS.

[0] https://github.com/silkenweb/silkenweb

7znwjshsus• 3 years ago

I love how simple your cargo toml is. A big turnoff of leptos for me was the incredibly messy cargo toml of the examples. I could barely touch it without bricking the project.

Firfi• 3 years ago

Author here! I've added it to my TODO list and will update the article at some point coming week or two. Love how the library looks like - thank you for the link!

davidatbu3• 3 years ago

While I'm usually a no-macros kinda guy, but (I believe) leptos and dioxus provide tooling to hot-reload markup-only changes without (incremental) recompilation. Do you think that would be possible withour macros?

ljsb2• 3 years ago

I can't think of any practical way to do that without macros, unfortunately. I've found incremental compilation to be pretty speedy for small markup changes so far though. I do tend to put the presentation code in it's own crate for larger projects, which might make a difference. Maybe as my projects get bigger I'll start to run into problems.

Some other ideas:

- Temporarily stopping the rust-analyser server to avoid lock contention on the build dir.

- Using cranelift codegen backend (not sure of it's current status).

fmeyer• 3 years ago

Who remembers GWT?

I understand the requirements of having a dedicated canvas and a decent UI running on it for things like games, CAD, 3D modeling and image manipulation apps. At the same time I don’t want my web bank using it. And unfortunately that’s usually what comes out from this.

Aerbil3132• 3 years ago

Give it enough time, and anything will happen. JS to Rust compiler with DOM bindings. Pure canvas Rust UI frameworks with even better accessibility than Web DOM. Whatever. People are so eager to claim X won’t be able to do that, etc.

doodlesdev• 3 years ago

https://archive.ph/MLUeZ

Emerging Rust GUI libraries in a WASM world

Related Stories