Dioxus 0.8 Roadmap #5024
Replies: 3 comments 2 replies
-
|
Great! Promising! Why not the component lib catch up? |
Beta Was this translation helpful? Give feedback.
-
Progress Update | Jan 4, 2026Native APIsWe're making tremendous progress on this front:
This PR is bringing full manifest customization as well as a way of doing general cross-language FFI with Java/Kotlin/Swift. We also have a generic pipeline for porting native APIs to Rust. Once this PR lands we should be able to start getting out native APIs quite rapidly. The FFI and manifest customization should land in v0.7.3. Direct DOM Access Through WebviewThis has also seen great progress. This repository has a working FFI bridge into the webview using the same web-sys API the rust ecosystem uses. paint.movMigrate to Winit for dioxus-webviewThis has also seen good progress. We have a few PRs on this front, though no full port yet, as we are waiting for winit 31 to land. Subsecond workspace supportWe have not worked on this yet. After we spin out DX into its own repository, we will start working on this. Dioxus Deploy v1We have actually made great progress here, but mostly for internal tool testing. We are working on adding deploy previews for native apps. With one click you can quickly (<1 sec) open a windows/mac/linux/ios/android VM. You can also snapshot the VM and share links to it. The Claude Agent SDK is wired up, so you can command the VMs. We are working on getting this production ready to start using on the Dioxus repo. skyvm-feature-demo.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
Hello, are there any components for developing table tables in the future? Rendering a lot of data |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Dioxus 0.7 is out and now it’s time to start work on Dioxus 0.8.
Dioxus 0.8 will be focused primarily on developing Native APIs, cross-platform compatibility, and squashing bugs. This means we are planning for a substantial overhaul of platform APIs. We have no plans to drastically change state management or fullstack.
Headlining Features
event.targetaccess and handles to elements across webview boundaryDXtool into its own repository“Stretch Goal” Features
dx deploycommand and deploy platformdxBreaking Ground: Dioxus Deploy
Dioxus 0.8 will require a substantial amount of cross-platform API development. To build this more efficiently, we will be building a developer-oriented cloud VM system. This system will help us provide better Quality Assurance across the wide range of targets we support.
We plan to release this tool as the very first Dioxus Deploy product. Running cloud VMs is complex and expensive, and we think our tool will solve a critical pain point for all application developers.
We plan to release more details as the product evolves, so stay tuned to our various social channels to be up to date.
Spinning out DX
We’re very proud of our build tool
DX. As we add more features, we are keen to get it into the hands of more developers outside Dioxus.DX brings a number of excellent features to Rust:
This means we will be pulling the
DXCLI out of the dioxus main repo and maintaining it as a standalone project. In the future we hope to add more features including:More Content, Tutorials, and Videos
The docsite received massive improvements with the 0.7 release. We plan to continue this work, adding more guides, tutorials, and example projects.
We’ll also do a bit more blogging and release a few youtube videos covering the various technical aspects of the project. These will include deep-dives into Subsecond, Manganis, fullstack, and tutorial content on how to do things like state management.
Timeline
We have no official timeline for Dioxus 0.8. We plan to release the building blocks for native APIs relatively soon since a community member has already contributed a substantial amount of work:
#4842
The various native APIs will be released during the 0.7 release cycle and thus have no official “release date” - these things will be released continuously as 0.7 is out.
What made 0.7 take so long?
In our 0.7 roadmap, we originally intended for the 0.7 release cycle to take about 3-4 months. And indeed, feature development finished in that timeframe. Unfortunately, polishing 0.7 took nearly 6 months. We release nine different releases of 0.7 alphas and pre-releases before feeling confident enough for release.
On the surface, releases appear to be just a collection of features, but in reality, the pieces of the puzzle must fit together properly. This led to us making changes like ripping out the old fullstack system, adding reactive stores, and working around various bugs in 3rd-party libraries. Arguably, these changes should have been postponed for a future release, but given the nature of how we do releases, they manifested as scope creep and deadline slip.
We have a strong desire to “1.0” the core of dioxus and then let dioxus itself update more frequently. This would let us iterate on the “puzzle” without blocking critical improvements to renderers and fullstack. There are no guarantees here, but hope this new approach will yield more consistent major releases.
Beta Was this translation helpful? Give feedback.
All reactions