[diablozzq]

I’ve been watching this for a while. It’s the most promising tech framework I’ve seen. If they succeed, it could obsolete all other frameworks.

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.

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

[risyachka]

All in one (Mobile, desktop, web) always sounds nice until you actually do a multi platform app.

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.

[klabb3]

> If they succeed, it could obsolete all other frameworks

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

[jkelleyrtp]

Not sure if you grok 100% what we're building.

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.

[klabb3]

> Not sure if you grok 100% what we're building.

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?

[jkelleyrtp]

> So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?

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.

http://github.com/dioxusLabs/sdk

[klabb3]

Ok, sounds more reasonable now. Being DOM-like or DOM-compatible sounds much preferable, even though I don't see the reason to abandon webviews - you get 30 years of battle-tested tech for free + massive ecosystem.

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

[airstrike]

For cross-platform desktop (and WASM), I'm still betting on iced, which I use daily. It's just so. blazing. fast.

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.

[cardanome]

I don't see any use case where you couldn't write your app in a garbage collected language.

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.

[bryanhogan]

Is there really more potential compared to Capacitor or Tauri?

[J_Shelby_J]

Imagine hitting deploy and your app builds for every platform that exists.

[highwaylights]

There’s this

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

And to a lesser extent this:

https://expo.dev/

(It won’t target games consoles or non-headless edge devices, that I know of).

[jcelerier]

idk I do this in plain ol' C++ with Qt & CMake, every commit builds for mac, windows with msvc and mingw, 15-ish linux distros / configurations, web, bsd... https://github.com/ossia/score?tab=readme-ov-file#build-stat...

[bitbasher]

^ Like a website?

https://xkcd.com/1367/