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.
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...
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.
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).
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?
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.
What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?
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.
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.
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.
And once you "get" The Elm Architecture it feels like you're in a whole different world that is equal parts beautiful and logical.
I think mobile is a different beast best served by native toolkits. But for a lot of people, what they really want is a website packaged into binaries for every platform, so their tradeoffs are different.
For everyone reading this who's considering iced, I'm on Discord daily trying to help newcomers get their bearings. I'm also on Discourse and GitHub but those just happen to be less active.
Then in 99% of cases you find out that those 3 have very few things on common. UI usually has to be completely re-designed for each platform, each has unique features that are not and will not be available on another platform etc.
You'll need to have a shit load if "if os=='desktop'" or even more granular like 'android' etc.
And if your app it not tiny - its just simpler to redo UI in a proper specialised framework.
Nowadays it is literally a very simple issue as existing frameworks are very mature.
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
And to a lesser extent this:
(It won’t target games consoles or non-headless edge devices, that I know of).
Rust is great for command line apps, tooling and well systems programming but UI stuff? Sure can be done but it doesn't really play to Rust's strengths.
Tauri at least allows people to use their JS knowledge so it is a much easier sell.
Of course if you just enjoy writing Rust that is fair, just saying it doesn't make business sense for most people.
> web
Aside from the fact this is for obvious reasons not happening, why would anyone want to replace something that's standardized, mature and effective with a VC-backed UI library with basic features? Because Rust? Sure, if you really, really like Rust for some reason, I can see the hypothetical appeal, but what I can't understand is the desire to throw away the web, which imo is like the 8th wonder of the world. But the DOM, accessibility, rendering, JIT and sandboxing? Starting from scratch on that is akin to building a new OS. And for what? Dislike for JS? Then WASM is the right solution.
Dioxus-web is basically React/SolidJS/Svelte. It writes to the dom and handles dom events just like any other web framework.
Where Dioxus differs is on native platforms, where we basically try to provide a Web-like API to native widgets. Think electron but you're not shipping a browser, just the rendering engine (that fits into 3.5mb!).
Our users on native platforms like being able to access system APIs with no intermediary. You can spawn threads, talk unix sockets, call FFI, etc. Stuff like electron is heavy, slow, and puts an IPC boundary between your UI and the system. We're trying to dissolve that.
Long term we want to expose JS and Python bindings for our native engine - Rust is not necessarily the "killer feature" there.
Yup, fair point. Let me respond with a bit more context.
> It writes to the dom and handles dom events just like any other web framework.
So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?
> Think electron but you're not shipping a browser
The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
> Our users on native platforms like being able to access system APIs with no intermediary. You can [...] call FFI, etc.
This is so difficult, and I applaud you for taking on the challenge. Rust is a decent choice for FFI, but still, FFI is a mess with largest common denominator being C. In the Tauri community, most users are intimidated by Rust alone. The number of devs who could fix segfaults related to Objective C bindings, wrangle Win32 syscalls and knew enough GTK could be counted on one hand (maybe one finger). So in short, can is doing a lot of heavy lifting here. That also means users have to come up with the cross-platform API surfaces themselves, right?
Yes - we have a project called Blitz which is trying to emulate just the DOM without the browser. It's built on Servo/Firefox tech.
https://github.com/dioxusLabs/blitz
> The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
The default dioxus desktop/mobile renderer uses the system's webview for exactly this reason. The blitz stuff is still young but is planned to eventually replace the webview renderer. Fortunately, webviews are on many platforms already.
> .. That also means users have to come up with the cross-platform API surfaces themselves, right?
Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc. In 2025 this will be a huge focus for us, and in all likelihood we'll just find a way to bind to existing widgets in the respective ecosystems. Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice). Projects like our SDK do this, but the surface area is quite small when compared to what we eventually want to support.
> Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc.
I don't know about those, but I can say with confidence (from experience in Tauri) that the native integrations are absolutely crucial. Getting the API surfaces right, the plugin <-> core boundary right (with versioning, etc). It's hard as hell - do lots of research and try to learn from their mistakes.
> Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice).
One thing I learned from the Tauri FFI story is that Rust mattered very little in the sense of hermetic and safe development. The boundaries get ugly and safety can be violated simply by misunderstanding the model of the other language (for instance, I've had an Objective C autorelease bug that caused a segfault on `drop`).
Investing in good infra, testing, debuggability around the FFI boundaries would have been the right thing to do. You often run into the same kind of problems in different "plugins" and features.
Mobile, desktop, web, rust
They have an eye on performance up front which is where most previous attempts fail.
And rust gives them the security and performance foundation up front.
.5 was a huge leap, this looks like the polish that should make it viable.