[highwaylights]

It could well become very popular, but using words like “magical” and “blazing fast” immediately triggers my framework fatigue.

To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim.

.NET already did that, several times over, over many years. Other frameworks still exist because not every problem needs a hammer, and the more use cases you try to solve the more you suffer from the jack-of-all-trades problem.

I’m interested in how this solves for the web and mobile. It references flutter in its marketing - is it doing its own rendering in these scenarios?

If so, it’s DOA for me for a whole host of reasons that have already sunk projects like this a lot of times over.

[jkelleyrtp]

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

[highwaylights]

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.

[nicoburns]

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

[byw]

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

[nicoburns]

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

[Svenskunganka]

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.

[peutetre]

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

[jkelleyrtp]

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.

[voat]

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

[aloisdg]

> To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim.

2nd that. For example I doubt that most people are willing to learn Rust in the short time. People are still relying on JQuery and PHP because it does the job.

[diablozzq]

With ChatGPT they may not need to learn it the same way.

Easy enough to code something in html and JavaScript and let tools translate. Obviously not that simple, but an example of why it might not be as hard in 2024.

It’s a bold claim, but they are executing and have benchmarks for validating the performance and features.

Lots of work left to do - but the speed aspect is where other frameworks who have tried similar tend to choke. If you look at the web framework benchmarks on tech empower and the web frameworks for react, dioxus is ahead of 95% today. And the ones that are ahead, don’t support deployment to desktop mobile and web.