Get the top HN stories in your inbox every day.
eslaught
josephg
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.
chrismorgan
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!)
rkagerer
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.
eslaught
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.
eslaught
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
danShumway
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.
flohofwoe
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).
danShumway
> 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."
zkldi
you're almost describing flash
i mean, it sucked, but it was kind of that middle layer.
undefined
kps
> 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.
keyle
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.
amelius
We could build a "DOM" inspector that runs inside the canvas too ;)
osener
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.
flohofwoe
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.
Freaky
> 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...
ocornut
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.
ReleaseCandidat
I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources.
Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.
birracerveza
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.
galangalalgol
Yeah, when a gpu is involved it is often cheaper to process everything rather than check what meeds to be processed.
ReleaseCandidat
> 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.
flohofwoe
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).
LeanderK
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.
ivoflipse
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
eslaught
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.
superdimwit
Try dear-imgui + implot. There are Python bindings
echelon
Animats
"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.)
bschwindHN
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.
echelon
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:
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.
int_19h
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.
tristanMatthias
Got this to crash by change the font size in the font book demo.
vincnetas
Trying to copy/paste in safari also crashes the demo.
undefined
potamic
It's pretty lagging for me on a beefy machine with hardware acceleration enabled. What gives?
flohofwoe
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.
arethuza
That looks awesome - are there any accessibility features (e.g. supporting screen-readers)?
emilern
Yes! egui uses https://github.com/AccessKit/accesskit for accessibility
Kiro
Are you being sarcastic?
galangalalgol
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.
rkagerer
Thanks!
I don't like how those textboxes get bigger when you click into them.
ljsb
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.
7znwjshsus
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.
davidatbu
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?
ljsb
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).
davidatbu
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...
Firfi
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!
mcluck
> 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.
KRAKRISMOTT
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.
klodolph
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).
wiz21c
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 !!!)
zelphirkalt
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.
vbezhenar
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.
KRAKRISMOTT
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.
stakhanov
> 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.
imbnwa
You forgot the part where the browser competently handles i18n and a11y, the later I especially wager none of these frameworks come close to
moonchrome
>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) .
croes
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.
jenadine
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.
Klonoar
>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
chrismorgan
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.
iudqnolq
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.
imbnwa
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
berkes
> 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.
IshKebab
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).
int_19h
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.
PoignardAzur
Speaking as someone working on a Rust GUI framework: how dare you say things about me that are completely accurate.
That said, it feels like it's starting to change. Lower-level components are getting stabilized, SlintUI and iced are picking up speed, etc.
calvinmorrison
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 .
alkonaut
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.
mcluck
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
alkonaut
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...
sophacles
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.
CJefferson
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.
chrismorgan
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.
danShumway
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.
chrismorgan
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.
mwcampbell
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.
waboremo
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.
LeanderK
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.
chrismorgan
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).
jenadine
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.
capableweb
I'm not familiar with the entire ecosystem but at least egui offers accessibility via AccessKit
CJefferson
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.
hnon
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?
eviks
There's AccessKit that's integrated in a couple of frameworks (egui is one)
(but hopefully it'd be a temporary step back)
low_tech_punk
I think Tauri bypassed the a11y challenge by delegating rendering to platform native web engines.
rwalle
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.
TobyTheDog123
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.
winstonewert
From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll probably hate golang.
We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.
So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.
8note
If you're going to use electron and all the bad that comes with it, why not just use typescript though?
baq
I love typescript, but hate the JavaScript parts of it.
winstonewert
Because even though typescript improves on Javascript and even golang, it still is much less nice than Rust.
crispinb
> I really don't understand the use-case for a Rust-based GUI.
For people already writing things (libraries, cli's etc) in Rust who want to add a GUI while staying with the language. No great mystery.
As for a business case, aside from individual developer taste/preference, it's hard to see that there is one outside of niches. System76 found a case for it with their DE. I think there might be a strong case for lightweight Rust GUI frameworks like egui for embedded device displays.
But for mainstream web / desktop / mobile apps? I can't at the moment see what the point would be.
cyber_kinetist
Things are a bit different in certain graphics app domains, where you need to create complex tools for professionals (think of image editing, 3D modeling, video processing, CAD, game engines, etc.) The users demand all kinds of functionality that requires squeezing the CPU and GPU to the fullest extent. And you have to do this while designing a complex UI with numerous complex controls, and it also needs to be butter-smooth. (Also note that the majority of the low-level APIs/drivers you need to use are in C/C++!) In that case, using languages like Go/Java/Javascript creates more problems than it solves (even if you only write the core in C++/Rust and use bindings.)
virtualritz
> 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.
0000000000100
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.
alpaca128
> 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.
pkolaczk
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.
klabb3
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)
crispinb
> 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.
FL33TW00D
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
satvikpendem
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.
crispinb
I doubt Rust is going to become used for (the GUI layer of) GUI apps far outside of Rust enthusiast circles. To build a widely attractive ecosystem it needs a dominant framework to which enough of the many widget and theming and distribution libraries and tools necessary for broad adoption attach. Rust's culture in this respect is far more Clojure (bolt together your own from a thousand options) than Elixir (just use Phoenix).
I have no doubt Rust will be used as part of many GUI apps via Tauri and others. 1Password shows how successful it can be as the real core of an app that has a separate web-tech GUI layer.
There's enough energy in the Rust ecosystem that I'm sure niche adoption will continue. But all-Rust apps beyond HN/Github-browsing/System76 circles? My guess is it's unlikely.
bsaul
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.
crispinb
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.
Liberonostrud
What's wrong with TypeScript? Last time I checked all WASM stuff was slower and much heavier than TS/JS.
devjab
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.
crispinb
Slower - not really now Rust client web frameworks have improved. Don't have refs handy, but Leptos, Dioxus etc are on a par with Solid.
Larger bundle sizes - yes that's still true.
And not all GUIs are web GUIs, so WASM isn't the whole story.
dragonelite
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.
josephg
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.
andyp-kw
My understanding that WASM has a heavier load time, however actual benchmarks after the initial load are more impressive.
SnowProblem
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.
DanielHB
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)
brabel
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).
jeroenhd
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.
pjmlp
And since everyone likes to talk about how great and magic the WASM sandbox happens to be, who cares if C is being used.
belst
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
davidatbu
> 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]
);
}_trackno5
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.
fmeyer
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.
LatticeAnimal
That is unfortunate that Druid was discontinued. I really enjoyed working with it a few months ago.
serial_dev
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.
Get the top HN stories in your inbox every day.
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.)