Emerging Rust GUI libraries in a WASM world | Hacker News Reader

Emerging Rust GUI libraries in a WASM world

monadical.com

332 pointsfork-bomber217 comments

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

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.

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

In my testing, I went through a bunch of Rust frameworks that sit on top of the core OS UI frameworks. My experience with all of those was that they all capped out at about 3k rectangles on a screen at a time at 30 fps (vs the about 80k rectangles that fit at usually 30-60 fps in my demo).

I wonder if your experience is different?

As best I've been able to tell, right now you have to make a choice between (a) fast and (b) native, and you only get to choose one. And in my application domain, fast is nonnegotiable.

Mixed UIs could probably work well here. Using a canvas and specific gpu rendering just for the part requiring high throughput makes sense.

What domain are you working in?

Smoothly rendering 3k rectangles isn't a common use case for UI libraries, so I'm not surprised they perform poorly. They generally aren't optimized for that. The normal answer for weird, high performance rendering like that is to just use opengl or something and program against the GPU directly. 3d rendering contexts can render millions of rectangles on modern hardware without breaking a sweat.

This advice is the same on desktop, mobile or the web. I'm not surprised rust UI frameworks have the same limitation. Most UIs don't need thousands of rectangles. But they do need lots of custom widgets, and implementing all of those well is a higher priority job for anyone building a custom UI library.

Like I said in my top comment, it's a profiler. I need to consume logs from distributed applications (on possibly tens of thousands of nodes) and render them in as coherent a fashion as possible.

Going to 3d rendering via OpenGL / WebGL was one of the options I considered. But honestly, this is a boatload of complexity. Why do I need to pick up a full 3D rendering library just to draw rectangles on the screen? Plus, consider: the slot viewer (where the rectangles are shown) still needs to draw some UI components (e.g., on hoverover). I still need that UI integration there, even if it's not as performance-sensitive. So I end up needing something along the lines of egui anyway.

I definitely understand that not all UI libraries are going to be optimized for this. But I was surprised that it wasn't easy to e.g. get a high-performance canvas dropped into libraries that specifically advertised themselves as high-performance.

The reason to pick up a "a full 3D rendering library" is that it is actually a lower level interface to the hardware. Almost all 2D operations are now implemented on top of 3D hardware primitives.

By limiting yourself to a 2D engine you're ensuring there are more layers of abstraction between you and the hardware. While # layers of abstraction doesn't always correlate with overhead, it does place limits on performance.

Yeah. And it’s not one or the other. On the web you can make a “3d” rendering surface for the profile traces and use absolutely positioned DOM elements rendered on top for you hover-over widgets and things.

It’s still a bit of a mess though. I understand wanting to keep everything in a single UI library if you can.

I was curious so I took a look at firefox's profiler. It looks like it does a hybrid render, using a couple of canvas elements for the flame graph and the stack trace (up the top), but the rest of the UI is rendered using plain old DOM elements. It performs great, despite the whole thing being pure javascript.

Example: https://share.firefox.dev/40QUthv . (Though this trace is probably smaller than the profiling traces you're demoing.)

Should you be changing 3K rectangles of your interface at 30fps? This seems like a very narrow use case that should be restricted to using Canvas with very specific parts of the application.

Maybe you have graphs/charts that need that kind of rendering effect. Great, use Canvas for them, they're not accessible anyway. But if something like your main user controls are running into that problem, I feel like something has probably gone wrong with your user interface.

In the demo you linked, it makes a lot of sense to render to Canvas for the individual charts, flame charts, breakdowns. It does not make sense to me to render to Canvas for the sidebar. It doesn't make sense to me that the list element itself holding the charts is going through Canvas. That's something in your UI that honestly shouldn't be updating at the speed you're talking about.

I don't know if you noticed, but my test has on the order of 10 billion rectangles. Only about 80k are drawn on the screen at once because I do very aggressive culling.

To be honest, I'm not sure Canvas can handle either part of this: either drawing 80k rectangles at 60 fps or culling so that the other 10 billion don't need to waste CPU cycles. It requires a very tight integration with the UI library to make sure we do this fast.

Yes, it's a very narrow use case. That's why I went with a specialized UI library.

> I'm not sure Canvas can handle either part of this

To be clear, WebGL/WebGPU is still using Canvas. You're not using the 2D api stuff, but that's just a high-level API on top of Canvas. You're still rendering to Canvas.

> I don't know if you noticed, but my test has on the order of 10 billion rectangles

Why? I've built apps like this before. Your choice is not "abandon the DOM" or "have zero performance." You can have most of your interface in the DOM and use Canvas (again WebGL/GPU is still Canvas) for specifically the parts of your app that wouldn't be accessible anyway (mainly charts).

It does not require tight integration with the GPU to render the sliders on the left hand side of the screen in this demo. No one is saying that you need to render your charts in DOM. We're wondering why you got rid of `ul` elements.

If you build an equivalent tech demo in HTML Canvas, I'd be curious to see how it performs. I'm sure you're aware that, just because Canvas layers on top of WebGL/GPU draw calls, doesn't necessarily mean it's performant in the way I need it to be. There are many ways for performance to degrade across abstraction layers, even if in principle it shouldn't.

I didn't test Canvas specifically in my explorations, but I did test a few JavaScript based frameworks, and the ones I found that were efficient sat on top of WebGL, not Canvas. Ultimately I didn't pick those because they had a bunch of other stuff baked in that I didn't need or want, and were already equally non-native (sitting on top of WebGL). And I frankly didn't want to be writing JavaScript.

> just because Canvas layers on top of WebGL/GPU draw calls, doesn't necessarily mean it's performant in the way I need it to be

You are using Canvas right now. WebGL uses Canvas to render to the screen. If you open up your demo's DOM inspector right now, you will see a canvas element. It's:

  <canvas id="the_canvas_id" width="1914" height="580" style="width: 1914px; height: 580px;"></canvas>

It's a little bit hard for me to trust this kind of dismissive talk about the browser adding too many abstraction layers when it's not clear to me that you're fully aware of what browser features your demo is using right now. Targetting the DOM and using embedded canvases really doesn't have anything to do with whether or not you're writing Javascript, and it doesn't mean you can't use WebGL to render charts.

> You are using Canvas right now. WebGL uses Canvas to render to the screen.

Ehhh sort of. Canvas is much older than webgl. When we talked about canvas a few years ago, that always referred to the canvas DOM element and its associated 2D shape based API. (fillRect / moveTo / lineTo / etc). When Webgl appeared, the nomenclature was "using canvas" vs "using webgl", since webgl's API is completely different from the 2d canvas API.

But browser manufacturers didn't give webgl its own DOM element. Webgl also uses a canvas DOM element, then configures it differently. (getContext("webgl") instead of getContext("2d")). So if you're using webgl (which I think this app is doing), then you're "using canvas" in the sense that your HTML contains a <canvas> element. But you aren't using the canvas 2d API - which, as I said, is totally different from webgl and is also called "canvas" because it was here first. And it doesn't have another name.

In defence of the GP comment, I think its pretty clear from context that "Canvas layers on top of WebGL/GPU draw calls" refers to the canvas API, not the canvas DOM element.

Even in that context, it's not really accurate to say that Canvas "layers on top of WebGL"; WebGL targets the canvas element, it's not the other way around. And (correct me if I'm wrong) even when Canvas first came out, the 2D API was optional -- you could always take an array of pixels and render them onto a canvas directly and bypass all of the higher-level APIs. You always had the option to ignore the 2D API if you needed to.

If it's just a context misunderstanding of what specifically "Canvas" is referring to, fine, I don't mind clarifying what I mean by that. And you're right, it's not unreasonable for someone to see the word Canvas and think "2D APIs." But I just want to be very clear that targeting the DOM for UI controls doesn't mean you can't use WebGL or WebGPU and direct graphics programming for charts, or that you can't render a chart in a web worker and then use the pixel buffer with a canvas. And none of that stuff requires you to program in Javascript (except for glue code, which you'd have to write for all of those methods no matter what). In modern web terms when I talk about targeting the Canvas, I just mean rendering pixels onto a canvas element as opposed to manipulating the DOM, regardless of how or where those pixels are calculated.

There is no additional set of abstractions you need to go through to do that, and there's no graphical system for the web that gets rid of the singular abstraction of needing to eventually put the pixels onto a canvas element.

Yes, if you were calling browser 2D APIs, that would have an additional performance cost, definitely. In a context where that's not performant enough, then don't do that? But there seems to be a suggestion in this comment thread that embedding canvases would require working with a higher level more abstracted graphical API when rendering the charts, and that's just not true.

Maybe I'm misunderstanding you, but shouldn't this be the GUI toolkit's job, ie choosing what to render as native HTML vs what needs to rendered to canvas?

Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?

> shouldn't this be the GUI toolkit's job

Ideally yes. This is a failing of the egui toolkit, not necessarily a failing of the people using it. The whole point of a high-level toolkit like this is that you shouldn't have to worry about how things are being rendered.

However, it is still important to counter claims that egui is making if the people using the toolkit are parroting those claims.

> Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?

I don't think I've ever built a web GUI in Rust so I have no idea what the ecosystem looks like. To my detriment, I tend to build most of my UIs from scratch. I can promise that it is possible to have performant UIs with a lot of embedded charts (like this demo has) using the DOM, but I have no idea what Rust framework devs have been getting up to or publishing.

There's also a little bit of a catch-22 here because yes, any time you introduce the DOM, you are going to lose some performance. That doesn't mean that you're going to lose so much performance that the demo above would be stuttery or wouldn't work. But if you're just measuring "how many quads can I refresh on the screen", that's kind of missing the point that you really shouldn't be refreshing thousands and thousands of quads of information in a UI at 60fps. That's not a thing that most interfaces should be doing in the first place.

And if you are genuinely changing thousands of boxes of information on a screen at the same time, kind of by definition that isn't accessible period. There is no way to present that volume of informational change to a screen reader in a way that will be understandable. But a lot of people when building UIs tend to think they're in the rare cases where they need that level of performance and so they need to sacrifice that accessibility, when in reality what they actually have is a giant list of charts and aside from the actual chart rendering, there's nothing particularly expensive going on.

Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform.

eg. I used to be able to programmatically grab hWnd's (like Spy++ does), and manipulate the forms of an app. Apps used to show up as one (or two) simple processes with rich instrumentation metrics in tools like Resource Monitor.

Chrome abstracted all that away in an effort to 'displace' the OS.

I think canvas-only technologies could eventually do the same (the endless cycle continues) and look forward to some of the benefits (eg. more deterministic and straightforward positioning and layout). But I strongly agree they need to accommodate most of the features you mentioned and until they do it's two steps backward.

Do appreciate your thoughtful comment and the concise summary of some fundamental limitations that are presently hard barriers.

> Well, in fairness web-based applications (including Electron ones running locally) break most of the inspectability benefits that came before, at least on the Windows platform.

---

I disagree pretty hard with this sentiment. Yes, it's harder to programmatically interact with some of the browser features from outside of the browser. Programmatic interaction with basically any application that isn't yours is getting harder across every operating system as security becomes more important.

That doesn't really change that introspection of the source that makes up a displayed site was easy and approachable. I can look at the css/html/js. Further, all of those resources are contained in files intended to be opened and looked at by humans (they're human readable text).

This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

> This is my biggest issue with WASM. You're literally back at reading assembly again. And while that's possible, and there is tooling that can help - it's just not the same as being able to right-click on something, alter a couple of attributes in human readable words, hit enter and see that change.

WASM on its own isn't the problem. WASM just lets you use another language to replace javascript. When you right click on something in a browser and alter human-readable attributes, you're usually messing with CSS and HTML. Any half decent web UI framework should pass HTML and CSS to the browser in order to render the UI. Thats just as true with wasm frameworks as it is with javascript frameworks.

The problem in this example is that the wasm code is bundling its own UI library that is trying (badly) to replace the browser's layout engine. All the browser can see is a bunch of drawing calls to an html canvas. Thats not the fault of wasm. Its just this UI library, which isn't really designed for the web.

Most web apps don't use human readable text. It's all heavily minified and the textual nature is just pure downside: slower and harder to parse than binary, more bloated, harder to implement.

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

This is what I don't get: if you have an accessibility layer that is fully usable, that means you have the capability to describe your user interface using only speech/text.

So what are you doing that couldn't be performant in the DOM? Because any kind of fast updates that you're doing with a lot of triangle that are too fast to render into an XML tree are also going to be happening too fast to describe with a screen reader.

The DOM is asking you to be able to describe your interface -- performantly -- in entirely pure text. If you can't do that, then there's no way you can be fully accessible, because the screen reader needs to be able to describe your interface -- performantly -- in entirely pure text.

People always get upset about this kind of thing, but it's very obviously true.

If you are updating thousands of rectangles in your UI at 30/60fps, it is impossible for you to fully convey the same amount of information that is changing visually to a screen reader.

Either your interface can be described using pure text, or it can't. Either I could use your interface by closing my eyes and having someone describe it to me, or I can't.

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.

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

you're almost describing flash

i mean, it sucked, but it was kind of that middle layer.

> Accessibility could be fixed easily if there would be a web accessibility API

It does have one. The DOM is the web accessibility API. A really big point of the DOM is that you don't get to make multiple interfaces, you have to make one interface that works for everyone, which forces you to provide some degree of feature parity between those interfaces.

The web accessibility API is "you have to describe your interface to us in pure text, because that format is more likely to be accessible."

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

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

Obligatory jaw-dropping egui demo:

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

Egui slaps and is clearly going places.

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

Trying to copy/paste in safari also crashes the demo.

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

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

Are other WebGL demos also slow (e.g. check https://webglsamples.org/)? How uptodate are your graphics drivers? In some rare cases WebGL is blacklisting old drivers if they have known vulnerabilities, and instead falls back to software rendering.

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.

For this there's Leptos and a half dozen other "DOM in Rust" frontend frameworks:

https://github.com/leptos-rs/leptos

These are already orders of magnitude faster than React, and as the WASM<->DOM bridge improves, they will only get faster.

Sycamore:

https://github.com/sycamore-rs/sycamore

https://sycamore-rs.netlify.app/examples/todomvc/#

Dioxus:

https://dioxuslabs.com/

In about 3-5 years these frameworks will start to consolidate and reach maturity.

It's already possible to build reactive isomorphic apps in Rust.

If you haven't checked out Actix/Axum, it feels a lot like Python/Flask. The ecosystem is coming along quickly.

Yep, my current favorites are Axum and Dioxus for web things (and some desktop apps too).

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

Yes! egui uses https://github.com/AccessKit/accesskit for accessibility

Are you being sarcastic?

I certainly was extremely impressed the first time I saw it. Other than the font book I haven't found anything there that is slow. What makes you think the op might have been sarcastic? Egui was in a thread yesterday and it seems like canvas rendering is a dividing issue between people who value portability and performance most vs people who value consistency of ergonomics and style/look most.

Its certainly controversial. Using canvas based rendering like this is essentially reverse-electron.

Electron builds native software by embedding a web browser and using the browser's layout engine and DOM. Canvas based rendering like this is the inverse. Here the application discards the browser's layout engine and DOM, and instead embeds its own layout engine. - Despite the browser being right there and available.

Hilariously, in a demo like this there's 3 layers of UI controls nested inside each other. First, there's the OS's native UI toolkit. Then there's the browser. The browser discards most of those UI elements, and reimplements its own controls. And then Egui discards all of that and embeds its own, third layout engine all written in wasm. No inertial scrolling. No web inspector. No native controls (especially a problem on iOS or android). No CSS - so I hope Egui's layout engine supports the layout you're after.

Downside: Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron!

The idea is that instead of shipping electron, you ship a native binary that use egui without using wasm or the canvas.

Egui only use wasm in situations where you must use the user browser because you have no choice. Eg: showing a demo of the app on the web without having to install anything.

> Its a 5mb wasm bundle. But on the plus side, 5mb is positively tiny compared to shipping electron

This comparison makes no sense. Situation where electron could be used are exactly the kind of situations where a wasm bundle would not be shipped (a native binary would be shipped instead)

> This comparison makes no sense. Situation where electron could be used are exactly the kind of situations where a wasm bundle would not be shipped (a native binary would be shipped instead)

Sure; but given the insane size of shipping chrome, it’s fun seeing a full app complete with widget library, layout engine and text input elements in 5mb. It’s terrible to make websites that big. But if chrome could do all that stuff in only a 5mb binary then I’d be much happier with electron.

If you didn’t catch it, the wasm bundle is running in a 32mb memory slab. Positively slim by the standards of modern gui apps!

I'm curious to see if they took every effort to strip that demo down or not. I think eframe doesn't get a ton smaller than 2mb no matter what you do, so maybe they did.

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.

Thanks!

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

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.

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.

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

An egui ScrollArea can request only visible rows from a callback using show_rows:

https://docs.rs/egui/latest/egui/containers/scroll_area/stru...

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.

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.

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.

Yeah, when a gpu is involved it is often cheaper to process everything rather than check what meeds to be processed.

I don't know how egui or the OP's app works, but we aren't talking about costly intersections of arbitrary surfaces but the sending of vertex data (for the vertex shader) in an integer interval (of nodes). This isn't about half or 1/10, but about 1/1000th of the data.

> If drawing all 8000 nodes consumes less resources than rendering your average homepage, is it really wasteful?

That may not have been clear, but I am talking about drawing less nodes in any case, also when using egui.

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

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.

Try dear-imgui + implot. There are Python bindings

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

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.

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

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.

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!

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?

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

Thanks for the ideas! Separating out presentation crate into it's own crate sounds like a great idea. Re "temporarily stopping rust-analyzer", I came across this trick[0] to make RA use a different build path (trading off disk-space for speed, but I mean, disk space is cheap).

Re: cranelift, I gotta check that out! Thanks for the reminder!

[0] https://github.com/rust-lang/rust-analyzer/issues/6007#issue...

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

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.

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.

The browser is successful not because it has a solid foundation but because a ridiculous amount of engineering effort has been put into it. Most of the "beautiful foundation" you see are all post 2012. You young'uns don't remember the days before HTML5 and CSS3. Before npm and PWAs and the "cloud native" nonsense.

Adobe Flash anyone? Silverlight? Before WebAssembly/WebGL/WebGPU unity (yes that game engine) even required a browser plugin. Web browsers were often severely incompatible with each other and web standards were a suggestion at best. Now, it's bad form to slander dead people so I will just say that the nice kind folks at apple under the orders of their dear leader did their best to destroy as much of the pre-2012 web as possible by gatekeeping the iPhone browser and using their market power to strong arm web technology.

I can’t figure out if you are for post-2012 web tech or against it

The answer is clearly ‘Yes’.

The problem is we’re in 2011 again, except chrome is the new flash and safari is the ie6.

I remember the buggy adobe svg plugin c.2000! That is an extension you had to install as an .exe to view some subset of svg!

People dont't simply use CSS and JS to build UI for web apps, they use web frameworks that comes with their share of supported components. And there are also a bunch of these framework to choose from, they come and go.

> Browser does not have a fuck ton of well supported widgets [...] And it works.

I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are.

With Microsoft-level resources, you can take on a mammoth engineering task like implementing Office or Visual Studio in the browser. But if you are resource-constrained in the way that most developers are, you cut corners and drop functionality, and that's where we are today with browser GUIs ...not that any of that matters if all you're doing is CRUD, like most people are. But one shouldn't judge technology by its easiest, most boring, and degenerate use cases.

I beg your pardon, but why do you consider CRUD 'degenerate'?

A "degenerate special case" of a general concept, in mathematics [1], is a special case that no longer has the complexities that motivated the need for that concept in the first place.

Consider, for example, the evolution of a CRUD app that was first written in, say, the late 80s for OS/400, using an interaction style where it's all full screen forms rendered as text that you fill out with your keyboard, then submit. Say, you rewrote that app in the 00s in Windows Forms but using the same interaction design, and then again in the 20s as a browser-based app. If you look at the evolution of what happened to UI technology through the lens of that app, you won't feel like anything is amiss in 2023, but you're also kind of missing the point of having a GUI in the first place, as opposed to, say, a text terminal.

Whenever I hear "all I need is a textedit and a button" from a web developer, I kind of assume that this is what informs their viewpoint.

If you instead look at the evolution of UI technology through the lens of an app like Photoshop, it will immediately be obvious to you what it is that GUIs uniquely have to offer that, for example, text terminals can't, and why rewriting such a UI in a browser is anything but trivial.

[1] https://en.wikipedia.org/wiki/Degeneracy_(mathematics)

The browser is more equivalent to the .Net framework and the JVM.

The GUI part was started by bootstrap and similar tools and shifted to React, Vue etc.

You forgot the part where the browser competently handles i18n and a11y, the later I especially wager none of these frameworks come close to

>Browser does not have a fuck ton of well supported widgets

What are you talking about ? HTML and CSS is full of widget libraries, it's the best cross platform widget library out there.

Ease of deployment + reach is the driving force behind improving the platform, but at the present nothing in Rust can even compare to something like Material UI. And let's not even go into stuff like date range picker components and shit where companies probably spent millions in engineering effort to get them right (eg. AirBnB) .

Is a date range picker that hard to implement?

You wouldn't think so, but I've seen a lot of bad ones.

>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

It’s not entirely wrong. Rust GUI has been held up by a significant dose of trying to do things properly, since the language definitely pushes you in that direction. It’s taken so long because Rust insists on correctness and on an ownership model that the popular solutions for GUIs simply didn’t fit into, so it’s taken time to come up with things that do work in those constraints.

Why do you guys think it's taking a lot of time because people are "trying to do it properly"?? See the comments about people trying the egui demo... that thing is as easy to crash as any junior dev React application.

By doing it properly chrismorgan means a native Rust solution that works with borrow checker.

Egui is mostly bindings. And those can suffer from impedance mismatch (e.g. using OOP UI in Rust)

Can you give an example of a real, shipped app where the majority of the GUI is written in Rust?

I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust.

This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite disappointed.

The most complex I know about: https://github.com/gyroflow/gyroflow

This appears to use Qt for the UI (I assume via Rust bindings).

The author of egui created https://www.rerun.io/ using... egui but the commercial version is still WIP.

A number of apps in the GNOME ecosystem use the Rust GTK bindings (e.g, Fractal).

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

Funny you mention R. I started a several months work on data analysis/science/you-name-it in python (a good language) and slowly, without noticing it, I migrated all my stuff to R (made by Satan). And exactly for the reason you give: R gets the sh*t done faster (in terms of time spent writing code) than Python... (and you can consider I am a lisper (worse: a schemer)/rust-er at heart !!!)

There is also some correlation between how solid the base is and how long a library/package/project is used, before it is cast aside for a new hip and trendy one.

Maybe. My sense is that there’s a finite amount of developer energy you have to allocate between different concerns. If you think of R, the language, as a base, then it’s definitely NOT a solid base (in my estimation). If you see it as a continuation of S, then it’s nearly 50 years of use for something you wouldn’t want to build on.

I’ll say the same thing about R+statistics as I will for Python+machine learning, for C++&game development / OpenCV, or Fortran and scientific computing. Having domain experts actually use your language to solve problems is such a massive advantage that you can almost ignore the benefits and drawbacks of the language itself. Almost.

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.

I don't think that's quite the point. It's not that you want dozens of different widgets in every app. It's that when picking an ecosystem for apps, a business will want to know that whatever they need (whatever small sample from that multitude), it's available. A large pool of resources is particularly important when you don't know exactly what you'll need up front, which is most of the time.

You might only want 8 colours, but if you don't know exactly which 8, you'd better have a large palette available.

I used to think like that, but it doesn't match my experience from my years of building (traditional) GUIs. I believe it is almost always better to stick to the couple of standard widgets that are available everywhere and known by everyone.

In the very rare cases it's not it is better to build a custom widget that matches your customers requirements exactly. Nothing is worse than a half-baked GUI element idea, badly implemented and sloppily maintained that matches like 85% of your customers requirements - and that's what most non-standard widgets are.

Quality and consistency trump quantity in my opinion.

It matches my experience precisely. Every time I've seen a GUI framework/library chosen that didn't have a huge head of steam behind it and very broad availability of off the shelf components and tooling, the project has either failed, or had to be rewritten after a swerve. This is for relatively mainstream software (consumer apps). Niches are another matter.

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

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.

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

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.

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 .

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

If we look at, say, Qt 3 (2002), or even Qt 2 (1999), I'd say that the comparison is still not in favor of modern Rust UI-from-scratch toolkits.

Actually I got the dates a bit wrong - according to Wikipedia they started writing Qt in 1991. Also that was a full time commercial project. As far as I know all of the Rust GUIs except Slint are hobby projects.

Finally, modern GUIs are way more complex than they were back then - especially when it comes to graphics APIs and text handling.

So I still think it's too early to say Rust has failed when it comes to GUIs.

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.

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

OSes that come with a native UI obviously have that as the default. But there will never be a default across OSes I think. Web UIs might be that, but I sure won't want to use html or js anywhere in my UI's if I can help it, even if cross platform.

Java might perhaps be the best example of trying to make a default-for-a-language cross platform UI (Swing and whatever it was called that came before it). But I think it's also an example of why it might not be a great idea to even try.

I think a key realization is that an app like Blender or AutoCad need a different UI paradigm than Spotify or a game overlay does, even on the same platform there are differences there. Apps that can use web based UIs tend to be more like Spotify than Blender...

Swing is pretty nice UX these days actually. Try the very latest IntelliJ in "new ui" mode, it looks modern and has an incredibly productive UI with tons of keyboard shortcuts, specialized widgets, etc.

The API is a bit old now, but you could easily put a reactive layer on top.

Qt and Swing are pretty good at "not quite native but close enough" in practice, IMO. I would take either one over a web or Electron app that completely disregards native UX and rolls it own, which is typical of them.

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.

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.

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

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.

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.

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

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

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.

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.

I believe you’ve misunderstood my intent. When I speak of the pure canvas approach, I mean throwing away almost all that the browser gives you, and rendering everything in a single canvas, with fake scrolling, fake links, &c.

For individual widgets like data visualisation, go ahead, use canvas if you want; I won’t complain—though make sure if you have any links in it that you have actual <a> links on top of the canvas for the user to interact with. And also consider if you can SVG. Anyway, individual canvases are fine; but don’t put everything in a single canvas.

Things like Google Docs and Figma are often cited as examples of how canvas-based rendering can be not bad, but neither are pure canvas: the user interface of both is full DOM, and it’s only the document area that’s canvas. (Also, I find Google Docs somewhat unpleasant: its rendering latency and throughput while you type is terrible, and keyboard caret navigation doesn’t match my platform’s behaviour in many places.)

See also https://news.ycombinator.com/item?id=33863185 (similar content to this comment).

ah ok, now I get what you mean. Yeah, doing everything in canvas is in general a bad approach for all the reasons you listed.

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.

Good intentions, but this leads people to create even more apps that they then proudly proclaim are just as accessible as alternatives because of AccessKit. It's a bit of a catch-22.

I think that's less bad than someone losing their job, or failing to get a particular job, because they can't access a canvas-based app. Edit: The former isn't entirely a hypothetical; I know of a blind person who lost his job in 2006 because use of an inaccessible app (a Java applet running on the Microsoft JVM, IIUC) became a requirement. I try to keep that bigger picture in mind with everything I do in AccessKit.

I just wish that the people that make canvas-based web stuff would realise how awful it is and tell people. I’ve interacted with a Flutter web thing once, for something that was only targeting the web. It was very painful. Flutter was completely the wrong tool for the job. But when they advertise their stuff, do they say “look, it kinda supports the web, but if you’re actually trying to target the web, please don’t use this because it’s just not good, and can’t be good unless we rip out the canvas stuff and render to real DOM elements”? Almost never.

When I do work on a web backend for AccessKit, I will be completely forthcoming about the limitations in the documentation.

It's far better that AccessKit exist than that it not.

That being said, yeah, there are people in this very comment section saying that of course egui is accessible, it supports AccessKit. So it's not really theoretical, any attempt to close the gap with AccessKit is going to be used by people as an excuse to build inaccessible applications. That's already happening in this comment section right now.

But that doesn't mean that AccessKit shouldn't exist it's just... one of the downsides to reducing the number of entirely inaccessible apps. It's a partial fix for a bad situation, and it's good for devs to use it if they have to, but it's far better for devs not to need to use it.

I think many people, especially SV devs whose job is finding solutions to problems, forget that there are no solutions to some problems. That only solution to these problems is to not pursue what causes the problem altogether.

Yes, it would be better if web applications that use canvas for their whole UI didn't exist. But they do, and I'm sure there will be more of them. I won't be able to persuade developers to stop developing apps this way. So I have to do what I can to help make them accessible, however imperfectly.

Right; to be clear, my issue is not with AccessKit or really any of the work you're doing here. I'm really happy that AccessKit exists, I'm glad that you're working on it.

AccessKit is trying to help fix a problem as best it can. My issue is with the people and frameworks that are causing the problem.

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.

The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve misunderstood how various platforms work.)

Browsers seem to have resisted adding fundamental alternatives of construct-on-query accessibility trees, or some kind of “I need AT stuff” switch so you can skip setting ARIA attributes or materialising other DOM if it’s not going to be used.

The end result is that the web doesn’t properly support accessible virtualised scrolling (where you have a hundred thousand emails in a mailbox, but only render the ones on screen, still providing a meaningful scrollbar) or infinite scrolling. There’s role=feed which improves matters in most screen reader configurations, but it’s still making some compromises. But then, virtualised scrolling is imperfect even for non-AT use—things like browser find-in-page won’t work properly. Still more of the “if you want it to work properly, it has to exist in the DOM all the time” stuff.

You're completely right about platform-native accessibility APIs.

To be honest, AccessKit itself doesn't support lazy accessibility trees for virtualized scrolling, at least not yet. It can avoid constructing the accessibility tree completely if the platform accessibility API isn't queried at all, but there isn't yet a way to only partially construct an accessibility tree while indicating that there's more available on demand. So to some extent, I guess AccessKit brings this web performance problem to native.

Okay, that is a fair point on virtualized scrolling, and while I can somewhat point to reasons why that's the case they're not strictly related to accessibility. They're more an API/extension concern than an accessibility concern, I guess.

That being said... I have also kind of soured on virtualized scrolling over time as I've spent more time working on UX projects, and I realize that sort of sounds like an excuse (we don't support this well, but you shouldn't be doing it anyway), but... I do kind of feel like infinite scrolling and giant lists of elements to the point where the list needs to be virtualized is bad UX for most apps.

----

And to be clear, I'm not necessarily saying that the DOM is perfect as an accessibility tree, just that it's good enough compared to the kinds of accessibility APIs that most native devs want when they complain about the DOM. In practice, a full-featured accessibility API with the same feature-set as the DOM and the same level of capabilities would likely have performance costs no matter how it was implemented in the browser.

Sure it could be better. But also all of those improvements could just be added to the DOM instead of making a new native web API. The biggest difference between adding those improvements to the DOM vs reconstructing something very similar to the DOM as a separate browser API is that devs could ignore the performance costs of that API and only benchmark their apps with the accessibility API turned off.

And I think it's good for devs not to have that option (or at least, for browsers themselves not to directly provide that option; again I'm not saying that I don't think AccessKit should exist).

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

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.

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?

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.

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.

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

I love typescript, but hate the JavaScript parts of it.

With a good linter config set super strictly, you can make Typescript feel like you're barely writing Javascript at all.

Any Javascript devs will probably hate working like that because now they're forced to write types for absolutely every single thing, but to me it felt like Javascript was finally fixed.

Just banning things like "any" and enforcing proper nullability makes up for a lot of Javascript problems.

This is the worst part of JS. To make it workable u have to:

- setup linting (which is awful and annoying) - formatting - use typescript

and then maybe u have a usable work environment. Rust just does that out of the box.

I disagree - Javascript's issues are not just its lack of type safety.

Even with Typescript you're dealing with the disastrous state of NPM/configuration/linters/formatters/libraries -- all of which are firmly Javascript-esque plagues (though not exclusively Javascript plagues).

Because even though typescript improves on Javascript and even golang, it still is much less nice than Rust.

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.

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

This is a matter of familiarity. For example, Golang is claimed to have simple syntax, but I find Golang's syntax much harder to read than Rust. The fact they avoided keywords and symbols like a plague caused that now e.g. function signatures are mostly names, spaces and parentheses, and the meaning of them depends on their relative positions, which is something I'm not used to.

I guess if I wrote / read Golang sources more frequently, that would become a second nature and would not slow me down.

> This is a matter of familiarity

No it is not. Or at least not for everyone.

I have learned several languages more unfamiliar to me than Rust (pure functional, logic, stack-oriented,etc), but none has given me the difficulties Rust has. Also (only my sample of course, but there are no reliable stats) no-one I personally know who has gone through the Rust book has continued with Rust. The Rust Foundation hasn't made 'flattening the learning curve' one of its 2024 goals because people don't find Rust harder than other languages. Many just do.

A false universal doesn't become true through brute repetition.

can i ask what kind of things you specifically found confusing about the syntax?

I don't have a problem with Rust syntax. Actually I can't imagine any developer with more than a year or two's experience has much trouble with any language syntax (unless it's something truly weird like APL). After a few days use you barely notice surface details anyway - it's just one possible representation of an AST.

My problem with using Rust is the way its complexity creeps into everything. There are large numbers of stdlib utility traits whose idiomatic use you have to remember to read almost any real world code. There's hardly a Rust library in common use that isn't a huge sprawling mass of over abstracted generics and macros. Even command line parsing is made to be a vastly complex endeavour. There are admittedly sugary niceties (eg derive attributes) that can make use of many of these libraries tractable for easy cases. But overall any substantial Rust program makes cognitive and memory demands on the programmer far in excess of what most languages require for the equivalent in my experience.

I can agree with that, I don't like overly abstract stuff either. That said in my projects I'm in control of the code and so I tend to avoid traits where they're not really necessary, I find Rust very pleasant to use that way and the compiler messages are simply outstanding. Often lifetime annotations can be replaced with heap allocations, which isn't always that efficient but it's a damn fast language and often you're not even going to measure a difference.

> Even command line parsing is made to be a vastly complex endeavour.

Yes, I even wrote a library for that once but then realized it only complicates everything and adds limitations. Nowadays I just do that by hand. For one it's guaranteed to be shorter than any parsing library, but also it's a good opportunity to think about what kind of arguments I need and in which form. And copy-pasting the parser from the previous project and adapting it is quick & easy.

Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is just stubbornness (because I find it hard), but some practical (performance, WASMability etc). I do like the way the type system makes it seem like things snick precisely into place when you get things right.

My beef (such as it is) is that I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. It takes me probably 4x as long to do anything compared to any other language I've used (and although I'm not a talented programmer, I am a polyglot).

Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.

> I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming.

I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other languages. I don't mind the compilation speed as much as some people seem to do, but the learning curve definitely is a problem.

Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there, the borrow checker almost never stands in the way. And realizing I can move owned stuff around cheaply instead of copying/referencing was also another huge enabler.

However I can imagine when Rust borrowing rules can be a huge pain. This happens when you expect to continue using the same style of programming that relies on big piles of (often cyclic) object graphs built with references/pointers, shared mutability, heavy (runtime) indirection and inheritance. A style that is so prevalent in OOP projects written in Java, JS, Python. I don't like this style at all, and always tried to avoid it even when coding in those languages, because I believe it causes more harm than good. Rust will simply force you to unlearn it. And some people won't need to unlearn much, and some will have to unlearn a lot. Changing habits is always pain.

I think it should be simply considered a different paradigm.

> I think it should be simply considered a different paradigm.

I addressed this above and believe it to be an unconvincing explanation of Rust's difficulty. Many polyglot programmers comfortable with, and experienced in, switching (and learning new) paradigms, still find Rust more difficult than other languages they have learned. In my experience most just give up. I haven't, but neither have I become remotely productive in the language.

Of course my experience is just one person's sample. There isn't much else to go one. But the Rust Foundation clearly agrees with me, given its 2024 roadmap. In our view, Rust is hard to learn and use, more than most languages, and problematically so for many.

How come Rust appears at the top of most loved languages in the SO survey so many years in a row? And doesn't even make into the "most dreaded" list at all (when many simpler languages do make into that list)?

Also, there aren't any other mainstream languages with borrow checker at the moment. The problem with Rust is that it introduces many novel ideas, not just some old ideas wrapped in a different syntax (e.g. like Kotlin or Swift). They need time to get into developers heads. Similarly it took many years to accept some ideas from FP into mainstream languages, and people were even debating if Java needed lambdas.

And BTW: I didn't find Rust harder to learn than, e.g. Python or Scala... Scala was kinda fun, but FP required similar amount of mind-bending as lifetimes in Rust, and Python was just purely frustrating.

> How come Rust appears at the top of most loved languages in the SO survey so many years in a row? And doesn't even make into the "most dreaded" list at all

Because these two lists are mutually exclusive.

On the survey they ask:

* Do you use X today?

* Do you want to continue to use X in the future?

"Most loved" means "the ratio of yes/yes answers is high", and "most dreaded" means "the ratio of yes/no answers is high."

Rust wins "most loved" because many users say yes/yes, and few say yes/no.

If so few people say yes/no then this means to me that either the difficulty is not really as bad as some people try to paint it here (under assumption people don't want to continue using a language that is frustrating), or that indeed the difficulty level might be high but developers get a lot in return, so it is still worth to pay that price and continue using Rust, which means - maybe it is difficult, but it is still productive.

It is very hard if even possible to objectively assess the difficulty of the language, because difficulty is inherently subjective and depends heavily on prior experience. The fact that there are many people who claim to be more productive in Rust than e.g Python or Java, but at the same time many others that don't share that opinion, IMHO supports my claim this is mostly a matter of a paradigm shift.

Also I noticed many developers somehow don't count the difficulty to fix bugs towards the difficulty of the language. And maybe that's also an explanation why we end up with so vastly different opinions.

However often you inform someone that they are wrong about what they found difficult, it will not thusly become true. Your brutish & obdurate insistence is only boring.

The difference between what you and I are claiming isn't in the substantive content, it's that you, Shiny Happy Rust Person-style (exemplifying what many of us find so ugly and bullying about the much-vaunted "Rust community") insist on universalising your personal experience.

I've already told you that novelty is nothing whatsoever to do with why I find Rust difficult. It has few novel concepts, and they are simple enough. Note that I never mentioned the fucking borrow checker. Now fuck off. I've blocked you anyway.

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

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

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

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)

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

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

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.

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.

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.

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.

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

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.

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.

Yeah also note that 335kb of wasm isn't as bad as 335kb of javascript.

Its true that large javascript bundles are bad because big files take longer to download. But the arguably larger problem is that parsing javascript is really slow. This isn't as big an issue with wasm - the browser can parse wasm many times faster than it parses javascript. If I recall correctly, wasm parsing speed is about on par with the speed of parsing pngs.

So having 335kb of wasm is similar to having a 335kb image on your landing page. Its not ideal, but its not a showstopper.

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

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.

Exactly, WASM was designed to be very very lightweight... you can put a lot of logic into a very small amount of WASM, but you need a good compiler to do that, or write WASM by hand to really feel the benefit. If you just compile Go to WASM, with its GC, runtime and stdlib included in the binary, yeah it's going to be pretty heavy... Rust doesn't have a runtime but as you said, for some reason, produces relatively large binaries (not the case only in WASM by the way). Probably, the best ways to create small WASM binaries is to compile from C or from a WASM-native language like AssemblySCript (https://www.assemblyscript.org).

Rust doesn't have to output more code than a C compiler. But it tends to because most rust programs are stuffed full of bounds checks. And bounds checks aren't small. As well as the conditional itself, every bounds check also includes:

- A custom panic message (so you know which line of code crashed)

- Some monomorphized formatting code to output that message

- The infrastructure to generate a stack trace after a panic

- Logic to free all the allocated objects all the way up the stack

If you compile this 1 line function:

    pub fn read_arr(arr: &[usize], i: usize) -> usize {
        arr[i] // (equivalent to 'return arr[i];')
    }

... You produce 20 hairy lines of assembler: https://rust.godbolt.org/z/dhz34KEvj

In contrast, the equivalent C function is this rust code:

    pub fn read_arr_unchecked(arr: &[usize], i: usize) -> usize {
        unsafe { *arr.get_unchecked(i) }
    }

And predictably, the result is this gem - identical to what the C compiler outputs:

    example::read_arr_unchecked:
        mov     rax, qword ptr [rdi + 8*rdx]
        ret

But nobody writes rust code like that (for good reason). You can get a lot of the way there by leaning heavily using rust's iterator types and such. But its really difficult to learn what patterns will make the rust compiler lose its mind. There's no feedback on this at compile time, at all.

I'd appreciate any more tips or resources you might have about reducing Rust code bloat. I want my library [1] to be acceptable to the most strident anti-bloat curmudgeons, so they'll make their UIs accessible.

[1]: https://github.com/AccessKit/accesskit

Great project - this is important! Love your clear motivation statement at the top. I do wish there were some code/data examples within the README, but clearly that's not holding people back from using it.

I don’t know many good resources to learn this stuff unfortunately.

The things I reach for in practice are godbolt and cargo asm[1] - which can show me the actual generated assembler for functions in my codebase. And twiggy[2], which can tell you which functions are the biggest in your compiled binary and point out where monomorphization is expensive.

When I’m developing, I regularly run a script which compiles my code to wasm and tells me how the wasm file size has changed since the last time I compiled it.

Some tips:

Try to avoid array lookups with an index when you can. When looping, use slice iterators and when making custom iterators, wrap the slice iterator rather than storing a usize index yourself.

Be careful of monomorphization. If you’re optimising for size, it can be better to take a dyn Trait rather than making a function generic.

And play around with your wasm API surface area. It takes a lot more code to pass complex objects & strings back and forth to javascript than other types.

But otherwise, good luck! Love the project.

[1] https://github.com/gnzlbg/cargo-asm

[2] https://github.com/rustwasm/twiggy

Rust can be the same size if you put the same code into the binary, sometimes even smaller.

The problem is that it's real easy to just add a bunch of crates to an application, similar to the nodejs/Python approach.

Most people slso don't seem to turn off many parts of the standard library they don't, even for platforms like WASM. Maybe it's useful to have a stack unrolling panic handler during debug but in release you can just abort and save up to megabytes of space.

There's also a lot to be gained by tweaking the compiler optimisers. By default the optimizer is multithreaded, which makes compiles quite a lot faster, but reduce that to a single thread and suddenly a lot of optimizations can happen that wouldn't happen by default.

I wouldn't write code like described here in C, but I imagine Go and C# are better choices here. Maybe even that Java library the name of which I can never remember, or that Kotlin project that compiles Kotlin to Javascript with super easy interaction between frontend and backend.

I love Rust but if you're going to pick a systems programming language for your frontend, just make desktop supplications. Web is a nice fallback but if it's your primary target, there are so many better options out there.

it is rather simple, JS tooling cares A LOT about the size of their dependency tree. Statically compiled languages do not (except if they focus on embedded programming). Having a binary be 2mb vs 30mb is not a big deal for a desktop application

Just for reference I was testing this the other day and compiled some simple C++ to WASM and adding:

std::cout << "some text";

to the code increased the binary size by like 5mb. Turns out std:cout pulls ALL currency-formating, date-formating and i18n code in the c++ standard library into your binary

ansi C printf does not meaningfully increase your WASM binary size

If you want your code to be able to be loaded on-the-fly and fast you need bundling tools, just like JS does. Bundling is a really hard problem, game devs struggle a lot with it as well (although their problem is usually bundling assets, not code itself)

And since everyone likes to talk about how great and magic the WASM sandbox happens to be, who cares if C is being used.

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

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.

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.

> 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]
      );
    }

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.

That is unfortunate that Druid was discontinued. I really enjoyed working with it a few months 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.

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.

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.

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

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.

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

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.

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

https://archive.ph/MLUeZ

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.

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?

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.

Reminds me that I need to check https://vale.dev/

This is another one that tries to attack the same surface area as rust but aims at being easier.

The problem is that although the creator is gifted, he seems to not have much theoretical PL design knowledge. That is an issue for something as complex as this; this automatic memory management without a GC is cutting edge research and we don't know if we can make it work without making sacrifices like Rust did. You have to sacrifice something and that means while you won't have to worry about memory management, the work for the programmer becomes harder. Or just use a GC.

Vlang is worked on by a large group of different developers, not just the creator. It seems this gets lost in a lot of narratives, as if it's a one man show. If you check V's GitHub, it's clear to see they have many contributors and developers who are professional programmers or have extensive backgrounds.

Have you tried Vale or Lobster though? Research in memory management semantics is a lot more sophisticated than you might think.

Everybody is trying to make a more user-friendly Rust. The problem is that it is not clear yet whether that's possible, and if it is, how it may look. I know Vale and have tried it, though it's extremely early to judge anything so far. It does have a much stronger theoretical background than V, but even the theory is not completely clear at this point.

There is also Carp by the way: https://github.com/carp-lang/Carp

Autofree already works (to a significant extent) and has been demonstrated[1], for years now. Vlang's Vinix OS[2] uses autofree.

The situation (as I understand it) is unlike using a GC, autofree requires the user to have knowledge of memory management and how to use it properly. One of the objectives of Vlang is to be easy (easier) to use. Using a GC as the default, proved to perform very well with the language, and presented less complications for users.

It appears the strategy of the Vlang developers (as stated on their website and documentation) is to go with flexible memory management. That is the GC can be turned off whenever the user wants (-gc none), and other memory management options can be used such as autofree (-autofree) or their arena allocator (-prealloc).

This flexible memory management strategy would be somewhat similar to what Nim did, and interestingly, I don't see people crying as much about it. Furthermore, there is more to Vlang as a programming language than just autofree, as if its the only thing that counts. People use it for many other reasons.

1. https://www.youtube.com/watch?v=gmB8ea8uLsM (Autofree demo) 2. https://www.youtube.com/watch?v=mJG4Zg6Ekfw (Vinix OS)

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

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.

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!

Reply on news.ycombinator.com