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.
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.
What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?
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.
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.
> 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?
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.
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.
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).
I do track and use their main competitor - Leptos.
Break down your project in crates in a cargo workspace. My reload time went from 10/15s to ~4.
I followed the instructions here: https://benw.is/posts/how-i-improved-my-rust-compile-times-b... . Specifically the 2nd part of the post
And I do think I have a pretty granular crate system (would be _very_ happy to hear otherwise, because that would mean there's low hanging compile time fruit!): https://github.com/dnaaun/heimisch
My current _incremental_ compilation time swings anywhere between 15 seconds and 3 minutes (no, I'm not kidding). And I work on an M3 max macbook pro.
---
Things that I suspect are making my compile times worse:
1. The fact that I am doing SSR, which means my frontend code is included in the backend code as well.
2. I _think_ Rust is unnecessarily recompiling dependencies on incremental builds? (I don't understand how incremental compilation times can be so bad otherwise). But I'm clueless about how to go about debugging that.And at the same time: I am absolutely delighted that Dioxus has managed to raise some money so Jon can work full time and bring others into the work full time. This really, really is a "rising tide lifts all boats" type of situation... I would 100% rather capital go toward things like building out a viable Rust ecosystem and improving build tooling than the alternatives ("it's TikTok, but with an LLM!" etc.) Our two projects have collaborated successfully and will continue to collaborate and inspire each other in the future, I'm quite sure.
This isn't meant as a rebuke to your very kind comment about the work I've/we've managed to do for free, I just wanted to chime in to say that in my opinion, both of these are good!
The contrast is interesting because leptos was the brainchild of an individual (Anglican priest, too, IIUC) whereas Dioxus is venture-backed.
DIY components is rough for basic dev.
My feeling is that if you are going to use a webview, you might as well use Typescript and a battle tested framework.
Dioxus is a full UI kit for Rust. They stick as close as possible to React and even have CSS and Html syntax. But, it's not a web environment.
Dioxus appears to currently use Tauri for the desktop renderer (https://dioxuslabs.com/learn/0.6/guides/desktop/) so it seems like it's a cross-platform framework that uses tauri on the desktop.
However it seems like they to switch to their own html renderer for desktop at some point.
https://github.com/Boscop/web-view
We are great friends with Tauri but I think people misunderstand our architecture and philosophy just because we use one of their maintained libraries.
We’ve been working on a native HTML/CSS library for a while called blitz which is reaching stability soon.
> Dioxus desktop is built off Tauri. Right now there are limited Dioxus abstractions over the menubar, event handling, etc. In some places you may need to leverage Tauri directly – through Wry and Tao.
Maybe that paragraph is out of date though?
From your comment it seems like wry is not (currently?) based on Tauri so it doesn't seem like it would make sense to "leverage Tauri directly – through Wry"; was wry previously based on Tauri and is that part left over from before that change? Or did the person who wrote the documentation misunderstand how it works?
A similar comparison would be Electron and React / React Native.
Tauri is a way to package a web app (e.g. could be react or svelte written in typescript) in a window and interface with rust code.
Dioxus is a way to write web apps (and other applications) in pure rust.
Some of us want to invest many years of time and money into stuff and have to make the decision carefully.
Dioxus is a private company though. It is fine if people want to contribute, or if Dioxus wants investors. But isn't it a little weird trying to influence me/someone to donate to a private company to improve their _product_?
They are YC: they should raise more funds and get serious IMO. Hire more people, fix the broken stuff in the DX and more people will use the product. It's that simple.
Also if you want people to contribute money I would work on getting the product to a more usable state. People don't want to buy products that don't work, software or not. If the first experience is repeatedly one of not working software, people will not want to use it.
I'm also building a screenplay editor prototype[1] in the Rust equivalent, Iced, and while not as ergonomic as Lustre and Gleam, it is TEA. Iced is still in flux but I have trust, considering System76 uses it to build Cosmic.
[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
Gleam looks great. Reading the FAQ, especially why the don't implement type classes, I am a bit worried though that it leans to much into trying to be simple.
Minimalism can work in dynamic languages because they impose basically no restrictions on your types and you can have crazy complex ones for free but in a purely static languages a lack of more advanced type system features can make writing library code very annoying and make the language feel very boilerplaty. The advanced type system features that languages like Haskell or OCaml provide are not purely for academic wankery, some of them are extremely useful. Even Golang had to add generics.
I hope they don't fall in the same trap as Elm did where it got so obsessed with simplicity that super knee-caped the language. I mean the Gleam devs seem already be way more pragmatic. At least it seems to have a decent FFI which provides an important escape hatch.
In Elm-likes you usually need to explicitly need to connect all child components in the model _and_ view _and_ update in a way that ultimately connects all leaf components to the root component. I know that there many Elm proponents that see that as a positive (as that makes execution more transparent). However in practice that usually ends up with either overly shared Message types where logic isn't contained to the widget it belongs to, or a boatload of boilerplate just to do .map operations between a child-Message-type and it's wrapping parent-Message-type.
I think this boilerplate can be solved by some degree with good framework support (and some try), but most Elm-likes don't and it makes scaling projects in them a pain.
That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.
I did a cargo install. I then used the dx command line app to create a new project. After initialization I ran dx serve in the directory as instructed, but it gave me a compiler error with seemingly no feedback on what specifically went wrong. And again, this is for a hello world app that they generated for me. I'm unsure how to obtain more information on why it failed.
I feel like I'd have more insight and ability to debug this if I were trying to compile using a standard rust workflow rather than their CLI tool.
You can press v to enable verbose logging, but this doesn't add information which provides clarity to me. Here's the compiler output with verbose logging, though heavily edited to be readable in this HN comment box
14:17:49 [dev] Building server...
14:17:49 [dev] Building app...
14:17:49 [dev] Executing cargo...
14:17:49 [dev] cargo args: ["--profile", "server-dev", "-- verbose", "--features", "dioxus/server", "--bin", "hack"]
14:17:49 [dev] cargo args: ["--verbose", "--features", "desktop", "--bin", "hack"]
14:17:49 [dev] cargo args: ["--profile", "server-dev", "--verbose", "--features", "dioxus/server", "--bin", "hack"]
14:17:50 [dev] Setting builder to failed state
14:17:50 [dev] Build failed: Other(Cargo build failed, signaled by the compiler)
Status: Failed
You can also press `t` for `tracing` logs which will emit the relevant logs. I'm sure it's something pretty simple / easy to figure out like a wrong version.
Why does a Linux webview app built with Dioxus require it? I'm asking, because software inserting simulated HID inputs to arbitrary windows is not exactly my cup of tea. ;) And xdotool doesn't work on Wayland anyway, by design. Apparently there are similar programs for Wayland, but AFAIK they require the user to belong to the input group, which in turn gives any app run by such user access to /dev/uinput - a security risk.
In general, though, Dioxus looks interesting and I wish you all the best in your endeavour!
WRT the other comment - `rsx!{}` is carefully designed to not leak details about the web. RSX is entirely abstract over the element+listener set so you can build whatever you want with it.
I'm looking for a native widget library that can compile to web technologies when running in the browser, but otherwise uses native widgets.
DX tries to be "rust only" but basically gives you a macro to write HTML-like components, which are obviously just a shim between layers and the abstraction is leaky. You don't get much from that.
You probably want egui.rs
On desktop/mobile, does Dioxus run as a native app? Is it an immediate mode renderer like egui? How do you style it? Or is it JavaScript + webview/electron?
On the web does it run as a WASM binary against a canvas renderer, or is it write to DOM? How does it talk to the DOM? WASM, JavaScript transpilation, etc.?
Can you do multithreading on web with web workers? Is the async story good? HTTP/gRPC clients?
Do you have to build your entire app in Dioxus, or can you incorporate other web (eg. React) apps? Can it talk to JavaScript?
How solid is the API now? Is it going to change a lot in the near future?
Do you think it'd be trivial to stuff a Bevy game inside of a Dioxus shell? We've thought it might be easier to prototype the UX outside the engine, especially since web is a deployment target.
How big is the community?
Looking into this for a project soon, so if any of the Dioxus devs can answer some of this, I'd super appreciate it. (Sorry for all the questions which may already be answered in the FAQ/docs.)
It’s retained mode and stays close to the architecture of a React/Svelte app.
On the web, it talks DOM directly. We have SSR, hydration, streaming HTML, and a fullstack nextjs-esque framework to go with it. All done via webassembly.
The async story is great. Our state management is multithreaded and many users are using web workers and PWAs.
We have focused less on building a good multi-tenant story but you can definitely integrate React into Dioxus and Dioxus into React. We’re close to runtime compatible but React core is a shifting foundation to build on.
The API feels closer to solid now but the scope of the project is big and APIs are bound to change. This update, we changed a few things but upgrading is quick. It will be a while before we want to rework interfaces again, and we’ll likely provide codemods at that point.
I think the community is quite large (gaining critical mass for library support) picking up steam, but JS land certainly is going to be much bigger.
Given the similarity, would it be feasible to add a compatibility layer to bring in React Native Turbo Modules? (Fabric support would be unlikely I'd imagine)
The sticky parts were where I needed more complex UI functionality. In the web world you can leverage mature, albeit heavy libraries for graphs and tables. In pure egui, you often need to roll your own and extend the basic features. Depending on how far you go down this road, it may make more sense to work within Bevy's UI entirely.
Dioxus looks like an interesting alternative here, but it also seems to be even heavier than egui, which isn't exactly a lite dependency.
If the culture of the Rust ecosystem was to publish a 1.0, we would do it. And frankly, I'd really like to have an extra "version" to play with - 0.x.y is quite limiting.
There's a few core things I want to clean up and split out in 2025. If all goes well, we might see a 1.0 next year.
At the end of the day we just use the Rust Struct parser!
It's very similar to JSON or RON if you're familiar.
I have seen a lot of templating languages like the one in Dioxus but I don't think you will "win" the hearts of people with a templating like this:
``` rsx! { footer { class: "footer", span { class: "todo-count", strong { "{active_todo_count} " } span { match active_todo_count() { 1 => "item", _ => "items", } " left" } } ```
Even if I can read it, it's much more of a hassle since I have to translate this into actual html in my brain. Why would I pick this over regular jsx with React? Sure crossplatform is cool, but I already do crossplatform since I only do web dev like most people nowadays.
Maybe I'm not the target customer here, but I have a hard time finding a reason why I should pick something that is much more complex. Speed sure but the gains are not good enough to warrant learning this and if I was a betting man I would bet against it in it's current form due to the learning curve. Also I worry about the financing sine I've read that you guys are taking in VC. Obviously there is some kind of plan in order to make money in the future and I wonder what rug-pull will happen.
The thing is, I have been looking on Rust due to the performance and the potential in wasm (I do very client heavy apps that would benefit from it). But I really don't like the language or the community so I'm basically waiting for other languages to keep up.
When I go in on a technology, I want to master it. So it will require a lot of learning and time investment for me which is my most precious resource and not something I will throw away lightly.
Do they require copyright assignment or a CLA? I could not find anything on their GitHub.
How many of their contributors are payed?
Question: where does Qt stands these days, and how does this toolkit compare to it regarding accessibility and handling HiDPI screens? Are there any quality bindings for languages that aren't C++ and Python? It feels like they solved a lot of problems long ago, and the toolkit could be way more popular with better bindings and tooling.
There are many bindings to other languages[1].
Is the web framework necessary? How does this compare, to say Tauri w. React & Vite?
The way you write components is really great and the overall developer experience is very good.
The static HTML templating thing is pretty damn good, though. I actually use it to render parts of my blog.
Trying to figure out which parts of the page to auto reload is hacky to me.
And it's the best proof of: Preoptimization is the root of all evil squares.