Hacker News Reader

Comment by jkelleyrtp | Hacker News Reader

Our hot-reloading is "magic" for the Rust ecosystem (this post's original intended audience). Hot-reloading formatted strings and simple Rust code is basically magic in Rust land.

I use blazing-fast tongue-in-cheek but Dioxus is really really fast. We did a ton of R&D into making Rust<->DOM very fast - our sledgehammer binding layer is faster than SolidJS on the JSFrameworkbenchmark [0].

As for rendering - we have two options: webview and GPU. The GPU stuff is nascent but capable. The final vision is something like React Native Skia where the majority of the interface is drawn on the GPU but interactions are done via Native System APIs. That way you get apps that look the same across platforms but "feel" native. To render, we have to step through the platform's native containers anyway, so you can always composite in a native system widget as a component.

https://krausest.github.io/js-framework-benchmark/2023/table...

View on HN

It seems like an interesting project, but using Skia (or any canvas/GPU render) concerns me for a bunch of reasons, not unlike Flutter.

Have you given consideration to indexing, accessibility and durability when working the problem? These are often the critical features that are overlooked with these frameworks and if they’ve even thought about that it would set you ahead of several other attempts that have ignored them (and are therefore unfeasible for most use cases).

I don’t mean this to sound derisive, it’s intended to be constructive.

Perhaps I'm misunderstanding you, but Dioxus does not use the canvas when rendering in the browser. It uses the DOM with CSS just like any other JavaScript framework does.

> Have you given consideration to indexing, accessibility and durability when working the problem?

This is actually a key area where we think we have an advantage over the competition. The model for Dioxus is to render to DOM on the web and only use the GPU renderer on native platforms (where we can integrate with system accessibility APIs directly).

The tradeoff for this is that our API on all platforms ends up being much closer to web APIs, our renderer has to implement a lot more of the web platform (e.g. we're shipping a full CSS engine, and using web-compatible Flexbox/CSS Grid for layout).

> where we can integrate with system accessibility APIs directly

Is this something Flutter doesn't do?

One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?

> Is this something Flutter doesn't do?

Flutter does do this (at least to some extent) on Desktop/Mobile. It attempts to create a hidden DOM tree for accessibility on web. Which generally doesn't seem to be thought to work very well.

> One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?

Ah, we're nearly there on that one. We have a PR [0] accepted into Winit (the underlying windowing library we use) which will allow us to access those events. We're just waiting on Winit to do a new release and then we can integrate it into Dioxus.

[0]: https://github.com/rust-windowing/winit/pull/3824)

> our sledgehammer binding layer is faster than SolidJS on the JSFrameworkbenchmark

What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?

Both would help. Sledgehammer is fast because it batches and interns strings on the Rust<>JS boundary.

Rust strings are utf-8 and JS strings are utf-16 (don't ask me why...).

The Dioxus VirtualDom is ridiculously fast - it's closer to the micro-dom SolidJS has (yes there's a micro-dom) than an actual virtualdom that React has.

Sledgehammer queues up all the Dioxus mutations into one fat binary batch and then runs a hand-rolled utf-8 -> utf-16 converter since the browser's converter is so slow. All the dom mutations are done from javascript. If direct DOM access landed, then we'd be able to do that from Rust directly.

And ultimately, all this work is like 10% of the actual "time" taken that you see on benchmarks. The vast majority of time is the browser running layout and re-painting. Reconciling a dom is not that hard or expensive of a task, frankly.

Bundle size and memory usage are still worse than leading js alternatives

Reply on news.ycombinator.com