Dioxus 0.8 Roadmap

[jkelleyrtp]

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

• High-quality native APIs for cases like camera, location, storage, oauth, and more.
• “Infrastructure-as-code” approach for permissions and customizing info.plist / AndroidManifest.xml
• Unification of DOM apis like keyboard shortcuts, document title, etc
• High-quality example projects demonstrating various native APIs
• High-quality Swift/Kotlin/Java FFI system
• Support for proper event.target access and handles to elements across webview boundary
• Support for native SwiftUI/Kotlin widgets in Dioxus Native
• Portal support
• Extracting our DX tool into its own repository
• Subsecond workspace support
• Migrate to Winit for dioxus-webview
• Attempt to “1.0” a subset of Dioxus for library authors, freeing up “Dioxus” versions to update more frequently

“Stretch Goal” Features

• Rust-only builder pattern as an alternative to RSX macro
• HTML macro as an alternative for HTML macro
• Inline simulator for vscode/cursor (similar to Radon IDE) + Component Previews
• dx deploy command and deploy platform
• Plugin support for dx
• 1st-class web-worker support
• Generic android support not bound by wry/tao

Breaking 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:

• Rust hot-patching and macro hot-reloading
• Asset support
• Cross-platform bundling
• Unified dev-server for web, desktop, Android, and iOS
• cargo profile isolation for faster iteration
• Multi-binary serve (server + client)

This means we will be pulling the DX CLI out of the dioxus main repo and maintaining it as a standalone project. In the future we hope to add more features including:

• Better local build caching
• buck2 integration and remote build caching
• Swift/Kotlin FFI support
• dx deploy for deploying apps to aws/gcp/azure and/or app stores
• dylib-based plugin support

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.