[HN Gopher] Emerging Rust GUI libraries in a WASM world
___________________________________________________________________
Emerging Rust GUI libraries in a WASM world
Author : fork-bomber
Score : 300 points
Date : 2023-04-27 02:41 UTC (20 hours ago)
(HTM) web link (monadical.com)
(TXT) w3m dump (monadical.com)
| ljsb wrote:
| 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
| Firfi wrote:
| 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!
| 7znwjshsus wrote:
| 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.
| Liberonostrud wrote:
| 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.
| TobyTheDog123 wrote:
| 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?
| brabel wrote:
| 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.
| tluyben2 wrote:
| 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.
| aatd86 wrote:
| 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.
| Conscat wrote:
| Have you tried Vale or Lobster though? Research in memory
| management semantics is a lot more sophisticated than you
| might think.
| iopq wrote:
| 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)) ...
| eslaught wrote:
| 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.)
| echelon wrote:
| Obligatory jaw-dropping egui demo:
|
| https://www.egui.rs/#demo
|
| Egui slaps and is clearly going places.
| arethuza wrote:
| That looks awesome - are there any accessibility features
| (e.g. supporting screen-readers)?
| emilern wrote:
| Yes! egui uses https://github.com/AccessKit/accesskit for
| accessibility
| int_19h wrote:
| 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 wrote:
| Got this to crash by change the font size in the font book
| demo.
| vincnetas wrote:
| Trying to copy/paste in safari also crashes the demo.
| bschwindHN wrote:
| 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 wrote:
| 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.
| bschwindHN wrote:
| Yep, my current favorites are Axum and Dioxus for web
| things (and some desktop apps too).
| [deleted]
| Animats wrote:
| "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.)
| Kiro wrote:
| Are you being sarcastic?
| galangalalgol wrote:
| 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.
| josephg wrote:
| 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!
| jenadine wrote:
| 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)
| josephg wrote:
| > 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!
| galangalalgol wrote:
| 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.
| potamic wrote:
| It's pretty lagging for me on a beefy machine with hardware
| acceleration enabled. What gives?
| flohofwoe wrote:
| 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.
| rkagerer wrote:
| Thanks!
|
| I don't like how those textboxes get bigger when you click into
| them.
| osener wrote:
| 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 wrote:
| 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 wrote:
| > 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/str
| u...
| ReleaseCandidat wrote:
| 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.
| flohofwoe wrote:
| 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).
| birracerveza wrote:
| 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 wrote:
| Yeah, when a gpu is involved it is often cheaper to process
| everything rather than check what meeds to be processed.
| ReleaseCandidat wrote:
| 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.
| ReleaseCandidat wrote:
| > 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.
| LeanderK wrote:
| 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.
| eslaught wrote:
| 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 wrote:
| Try dear-imgui + implot. There are Python bindings
| ivoflipse wrote:
| 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
| josephg wrote:
| 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.
| keyle wrote:
| 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.
| eslaught wrote:
| 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 wrote:
| 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.
| danShumway wrote:
| 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.
| chrismorgan wrote:
| 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!)
| eslaught wrote:
| 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.
| danShumway wrote:
| 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.
| eslaught wrote:
| 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.
| danShumway wrote:
| > 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.
| eslaught wrote:
| 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.
| mtsr wrote:
| Mixed UIs could probably work well here. Using a canvas
| and specific gpu rendering just for the part requiring
| high throughput makes sense.
| josephg wrote:
| 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.
| eslaught wrote:
| 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.
| IX-103 wrote:
| 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.
| josephg wrote:
| 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.
| rkagerer wrote:
| 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.
| horsawlarway wrote:
| > 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.
|
| ---
|
| 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.
| josephg wrote:
| > 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.
| revelio wrote:
| 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.
| amelius wrote:
| We could build a "DOM" inspector that runs inside the canvas
| too ;)
| flohofwoe wrote:
| 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 wrote:
| > 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 wrote:
| you're almost describing flash
|
| i mean, it sucked, but it was kind of that middle layer.
| [deleted]
| kps wrote:
| > 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.
| Aerbil313 wrote:
| 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.
| low_tech_punk wrote:
| I have my popcorn ready for the battle of WebGPU toolkit
| implementation. That can be a true differentiator between Rust
| and other languages.
| Liberonostrud wrote:
| What's wrong with TypeScript? Last time I checked all WASM stuff
| was slower and much heavier than TS/JS.
| crispinb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My understanding that WASM has a heavier load time, however
| actual benchmarks after the initial load are more impressive.
| belst wrote:
| 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
| SnowProblem wrote:
| 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.
| jeroenhd wrote:
| 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 wrote:
| And since everyone likes to talk about how great and magic
| the WASM sandbox happens to be, who cares if C is being
| used.
| brabel wrote:
| 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).
| josephg wrote:
| 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.
| mwcampbell wrote:
| 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
| josephg wrote:
| 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
| SnowProblem wrote:
| 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.
| DanielHB wrote:
| 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)
| _trackno5 wrote:
| Where did you check that?
|
| If you're talking about Wasm with Emscripten, yes there's a
| cost of loading the runtime because Emscripten comes bundled
| with a lot of stuff.
|
| I'm skeptical that just wasm itself was slower or heavier.
| devjab wrote:
| 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.
| eviks wrote:
| 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
| crispinb wrote:
| 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 wrote:
| 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 wrote:
| 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.
| LatticeAnimal wrote:
| That is unfortunate that Druid was discontinued. I really enjoyed
| working with it a few months ago.
| serial_dev wrote:
| 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.
| plaguepilled wrote:
| 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!
| fmeyer wrote:
| 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.
| preommr wrote:
| 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.
| doodlesdev wrote:
| https://archive.ph/MLUeZ
| mcluck wrote:
| > 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.
| alkonaut wrote:
| 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 wrote:
| 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 wrote:
| 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...
| revelio wrote:
| 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.
| int_19h wrote:
| 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.
| sophacles wrote:
| 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.
| KRAKRISMOTT wrote:
| 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.
| berkes wrote:
| > Almost everything else is secondary.
|
| For any app more complex than a demo "todolist", handling
| "business logic" is - by far - the most important. Hundreds
| of widgets that don't do anything, or do it wrong and buggy,
| are worthless.
|
| "handling business logic" is difficult and, ironically,
| perpendicular to many frameworks (as in: frameworks make
| dev/testing/evolving/refactoring of business-logic harder,
| not easier). A perfect example was (is? IDK) Visual Basic:
| tons of widgets, a neat builder, but terrible in managing
| even simple state and handling business-logic. Or React,
| which is a perfect framework (and paradigm/architecture) for
| small, or flat apps, but terrible for complex or convoluted
| apps.
|
| What I see in Rust, is a focus on the stuff beyond mere
| "providing lots of stuff that can be drawn to screen": how to
| manage state, react to changes, manage events etc. Which is,
| the way I see it, why there also are so many frameworks
| emerging: what architecture and paradigms work best, very
| much depends on your use-case.
| PoignardAzur wrote:
| 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 wrote:
| 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 .
| IshKebab wrote:
| 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 wrote:
| 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.
| wiz21c wrote:
| 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.
| imbnwa wrote:
| 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
| vbezhenar wrote:
| 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.
| jenadine wrote:
| 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.
| stakhanov wrote:
| > 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.
| vincnetas wrote:
| I beg your pardon, but why do you consider CRUD
| 'degenerate'?
| [deleted]
| stakhanov wrote:
| 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)
| moonchrome wrote:
| >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) .
| coderedart wrote:
| Is a date range picker that hard to implement?
| CuriouslyC wrote:
| You wouldn't think so, but I've seen a lot of bad ones.
| croes wrote:
| 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.
| imbnwa wrote:
| You forgot the part where the browser competently handles
| i18n and a11y, the later I especially wager none of these
| frameworks come close to
| KRAKRISMOTT wrote:
| 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.
| setr wrote:
| I can't figure out if you are for post-2012 web tech or
| against it
| baq wrote:
| The answer is clearly 'Yes'.
|
| The problem is we're in 2011 again, except chrome is the
| new flash and safari is the ie6.
| quickthrower2 wrote:
| 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!
| klodolph wrote:
| 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 wrote:
| 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 wrote:
| 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.
| klodolph wrote:
| 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.
| Klonoar wrote:
| >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
| iudqnolq wrote:
| 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.
| ogoffart wrote:
| The most complex I know about:
| https://github.com/gyroflow/gyroflow
| foldr wrote:
| This appears to use Qt for the UI (I assume via Rust
| bindings).
| sbt567 wrote:
| The author of egui created https://www.rerun.io/ using...
| egui but the commercial version is still WIP.
| Klonoar wrote:
| A number of apps in the GNOME ecosystem use the Rust GTK
| bindings (e.g, Fractal).
| chrismorgan wrote:
| 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.
| brabel wrote:
| 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.
| Ygg2 wrote:
| 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)
| weinzierl wrote:
| 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.
| crispinb wrote:
| 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.
| TobyTheDog123 wrote:
| 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 wrote:
| 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 wrote:
| If you're going to use electron and all the bad that comes
| with it, why not just use typescript though?
| winstonewert wrote:
| Because even though typescript improves on Javascript and
| even golang, it still is much less nice than Rust.
| baq wrote:
| I love typescript, but hate the JavaScript parts of it.
| jeroenhd wrote:
| 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.
| TobyTheDog123 wrote:
| 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).
| bmikaili wrote:
| 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.
| 0000000000100 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| crispinb wrote:
| > 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.
| zkldi wrote:
| can i ask what kind of things you specifically found
| confusing about the syntax?
| crispinb wrote:
| 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.
| alpaca128 wrote:
| 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.
| crispinb wrote:
| 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.
| virtualritz wrote:
| > 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.
| crispinb wrote:
| > 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 wrote:
| 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.)
| satvikpendem wrote:
| I've been using Flutter with flutter_rust_bridge pretty
| successfully, seems like a few other people I've talked to are as
| well, would want to see it covered in this article as well.
| FL33TW00D wrote:
| 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
| CJefferson wrote:
| 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.
| low_tech_punk wrote:
| I think Tauri bypassed the a11y challenge by delegating
| rendering to platform native web engines.
| rwalle wrote:
| 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.
| eviks wrote:
| There's AccessKit that's integrated in a couple of frameworks
| (egui is one)
|
| (but hopefully it'd be a temporary step back)
| capableweb wrote:
| I'm not familiar with the entire ecosystem but at least egui
| offers accessibility via AccessKit
| CJefferson wrote:
| 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.
| chrismorgan wrote:
| 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.
| LeanderK wrote:
| 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 wrote:
| 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).
| danShumway wrote:
| 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 wrote:
| 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 wrote:
| 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.
| danShumway wrote:
| 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).
| mwcampbell wrote:
| 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 wrote:
| 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.
| mwcampbell wrote:
| 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.
| chrismorgan wrote:
| 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.
| mwcampbell wrote:
| When I do work on a web backend for AccessKit, I will be
| completely forthcoming about the limitations in the
| documentation.
| danShumway wrote:
| 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.
| Aerbil313 wrote:
| 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.
| mwcampbell wrote:
| 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.
| danShumway wrote:
| 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.
| jenadine wrote:
| 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.
| vbezhenar wrote:
| 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.
| fulafel wrote:
| 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.
| Cloudef wrote:
| 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).
| vrglvrglvrgl wrote:
| [dead]
| klabb3 wrote:
| 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 wrote:
| > 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.
___________________________________________________________________
(page generated 2023-04-27 23:02 UTC)