Jonathan Kelleyotgerrogla 2356820+otgerrogla@users.noreply.github.comNico BurnskokoDavid HusičkaluoxiaozeroEvan Almloff
12c6938346 feat: inline dioxus-native from blitz (#3675)
* Rename dioxus-blitz to dioxus-native

* Add CSS import support (#139)

* Remove data dependencie from NetProvider + global provider.

* Feat CSS import

* Move net handler code out of util

* Fixing test...

* Use the better suited OnceLock instead of LazyLock

* Removing static and move resource callback back out of the document.

Signed-off-by: koko <kokos.kekse@gmail.com>

* Make things work

Signed-off-by: koko <kokos.kekse@gmail.com>

* Fix the servo example

Signed-off-by: koko <kokos.kekse@gmail.com>

* Replace servo image with a more compact version

Signed-off-by: koko <kokos.kekse@gmail.com>

* revert: 8467b271

Signed-off-by: koko <kokos.kekse@gmail.com>

---------

Signed-off-by: koko <kokos.kekse@gmail.com>

* Create readme app

* WPT: reuse FontContext to avoid reloading system fonts

Takes runtime for css-flexbox from 12s -> 8s

* Move Devtools to traits crate

* Suppress unused variable warning

* Implement net for DioxusDocument

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Eliminate BlitzWindowEvent type

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Make net crate use document id instead of window id

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename and document net traits

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Split `dioxus-native` crate into `dioxus-native` and `blitz-shell` crates (#163)

* Rename waker module to event

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Create seperate DioxusNativeApplication

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename dioxus-native crate to blitz-shell

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Split blitz-shell out of dioxus-native crate

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Remove need for dioxus-native to depend directly on stylo

---------

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Unnest dioxus-native modules

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Split MutationWriter into it's own module

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Split HtmlDocument into it's own crate

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename dom field of Window to doc

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Support prefers-color-scheme (dark mode)

* Remove use of the `todo` macro in event handling and add a comment about it being a todo (#168)

Using the `todo` macro causes a panic when this event is encountered. Noop is preferable in this case as it does not crash the application. This is especially annoying on platforms where `Ime::Enabled` event is sent upon application start even when the user is using a keyboard layout that does not need an IME support. There was added a "TODO" comment that informs about this feature being missing. Most IDEs and code editors have support/plugins/extensions to work with this type of comments and this type of comment is already used widely across the codebase. As such, the information about this feature not being implemented is not lost.

* Upgrade to dioxus 0.6-rc.0

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Fix text input in dioxus-native

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Make dioxus-native depend dioxus-core and dioxus-html rather than dioxus

* Remove "full" feature from tokio

* Move Viewport to blitz_traits

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Make tokio optional in dioxus-native and blitz-shell

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Make SVG support optional

* Abstract renderer behind a trait

blitz-shell no longer depends on blitz-renderer-vello

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Split HTML launch functions out in `blitz` crate

* feat: Add mousedown and mouseup event (#172)

* feat: Add mousedown and mouseup event

* feat: Triggering :active pseudo-class

* fix: Triggering :active pseudo-class

* Rename RendererEvent to DomEvent

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename Document to BaseDocument. DocumentLike to Document

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Move event and document abstractions to blitz-traits

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename BlitzEvent to BlitzShellEvent

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Restyle when style attribute is mutated

* feat: Support text box mouse selection (#182)

* Rename raw_dom_data to data

Signed-off-by: Nico Burns <nico@nicoburns.com>

* Rename dioxus-native to native

* Add to workspace

* simplify launch module, integrate native

* Fix it up again

* Update cargo lock

* FIx: propagate accessibility feature fla

* implement asset resolver

* add native to feature match in cli

* Implement document and history for native

* use no-op eval

* clippy

* typos

* typo

* Convert logs to trace

* Bump blitz to alpha releases

* unset image data

* fix style integration with blitz

* fix a few lints

* wire up ids

* implement a few more events

* add more helpful todo note

* bump ci to allow edition 2024, use newer nightly

* make clippy happy

* also update matrix tests to rust 2024

* Add autofocus

Co-authored-by: otgerrogla 2356820+otgerrogla@users.noreply.github.com

* Wait for the suspense boundary above the router to resolve before sending the first streaming chunk (#3891)

* Change the suspense streaming context after suspense is resolved in the router

* Wait for the suspense context before streaming the first chunk in ssr

* forward more response parts

* warn

* extract the hydration format into a crate

* Fix hydration when no data is sent

* forward web and server features

* Fix suspense that starts on the client

* fix use_server_future on the client

* Add documentation for fullstack hooks and protocol

* downgrade rust edition

* fix clippy

* fix tests

* fix clippy

* Fix pure web compile

* undo changes to the fullstack router example

* fix formatting

* hoist a bunch of deps

---------

Signed-off-by: koko <kokos.kekse@gmail.com>
Signed-off-by: Nico Burns <nico@nicoburns.com>
Co-authored-by: Nico Burns <nico@nicoburns.com>
Co-authored-by: koko <72217393+kokoISnoTarget@users.noreply.github.com>
Co-authored-by: David Husička <25853767+DavidHusicka@users.noreply.github.com>
Co-authored-by: luoxiaozero <48741584+luoxiaozero@users.noreply.github.com>
Co-authored-by: Evan Almloff <evanalmloff@gmail.com>
2025-04-08 17:30:49 -07:00
2022-02-13 12:44:17 -05:00
2024-08-28 09:25:25 -05:00
2024-12-06 19:34:40 -08:00



✨ Dioxus 0.6 is released - check it out here! ✨


Build for web, desktop, and mobile, and more with a single codebase. Zero-config setup, integrated hot-reloading, and signals-based state management. Add backend functionality with Server Functions and bundle with our CLI.

fn app() -> Element {
    let mut count = use_signal(|| 0);

    rsx! {
        h1 { "High-Five counter: {count}" }
        button { onclick: move |_| count += 1, "Up high!" }
        button { onclick: move |_| count -= 1, "Down low!" }
    }
}

⭐️ Unique features:

  • Cross-platform apps in three lines of code (web, desktop, mobile, server, and more)
  • Ergonomic state management combines the best of React, Solid, and Svelte
  • Type-safe Routing and server functions to leverage Rust's powerful compile-time guarantees
  • Integrated bundler for deploying to the web, macOS, Linux, and Windows
  • And more! Take a tour of Dioxus.

Instant hot-reloading

With one command, dx serve and your app is running. Edit your markup and styles and see the results in real time.

First-class Android and iOS support

Dioxus is the fastest way to build native mobile apps with Rust. Simply run dx serve --platform android and your app is running in an emulator or on device in seconds. Call directly into JNI and Native APIs.

Bundle for web, desktop, and mobile

Simply run dx bundle and your app will be built and bundled with maximization optimizations. On the web, take advantage of .avif generation, .wasm compression, minification, and more. Build WebApps weighing less than 50kb and desktop/mobile apps less than 5mb.

Fantastic documentation

We've put a ton of effort into building clean, readable, and comprehensive documentation. All html elements and listeners are documented with MDN docs, and our Docs runs continuous integration with Dioxus itself to ensure that the docs are always up to date. Check out the Dioxus website for guides, references, recipes, and more. Fun fact: we use the Dioxus website as a testbed for new Dioxus features - check it out!

Community

Dioxus is a community-driven project, with a very active Discord and GitHub community. We're always looking for help, and we're happy to answer questions and help you get started. Our SDK is community-run and we even have a GitHub organization for the best Dioxus crates that receive free upgrades and support.

Full-time core team

Dioxus has grown from a side project to a small team of fulltime engineers. Thanks to the generous support of FutureWei, Satellite.im, the GitHub Accelerator program, we're able to work on Dioxus full-time. Our long term goal is for Dioxus to become self-sustaining by providing paid high-quality enterprise tools. If your company is interested in adopting Dioxus and would like to work with us, please reach out!

Supported Platforms

Web
  • Render directly to the DOM using WebAssembly
  • Pre-render with SSR and rehydrate on the client
  • Simple "hello world" at about 50kb, comparable to React
  • Built-in dev server and hot reloading for quick iteration
Desktop
  • Render using Webview or - experimentally - with WGPU or Freya (Skia)
  • Zero-config setup. Simply `cargo run` or `dx serve` to build your app
  • Full support for native system access without IPC
  • Supports macOS, Linux, and Windows. Portable <3mb binaries
Mobile
  • Render using Webview or - experimentally - with WGPU or Skia
  • Build .ipa and .apk files for iOS and Android
  • Call directly into Java and Objective-C with minimal overhead
  • From "hello world" to running on device in seconds
Server-side Rendering
  • Suspense, hydration, and server-side rendering
  • Quickly drop in backend functionality with server functions
  • Extractors, middleware, and routing integrations
  • Static-site generation and incremental regeneration

Running the examples

The examples in the main branch of this repository target the git version of dioxus and the CLI. If you are looking for examples that work with the latest stable release of dioxus, check out the 0.6 branch.

The examples in the top level of this repository can be run with:

cargo run --example <example>

However, we encourage you to download the dioxus-cli. If you are running the git version of dioxus, you can install the matching version of the CLI with:

cargo install --git https://github.com/DioxusLabs/dioxus dioxus-cli --locked

With the CLI, you can also run examples with the web platform. You just need to disable the default desktop feature and enable the web feature with this command:

dx serve --example <example> --platform web -- --no-default-features

Dioxus vs other frameworks

We love all frameworks and enjoy watching innovation in the Rust ecosystem. In fact, many of our projects are shared with other frameworks. For example, our flex-box library Taffy is used by Bevy, Zed, Lapce, Iced, and many more.

Dioxus places an emphasis on a few key points that make it different from other frameworks:

  • React-like: we rely on concepts like components, props, and hooks to build UIs, with our state management being closer to Svelte than to SolidJS.
  • HTML and CSS: we lean completely into HTML and CSS, quirks and all.
  • Renderer-agnostic: you can swap out the renderer for any platform you want thanks to our fast VirtualDOM.
  • Collaborative: whenever possible, we spin out crates like Taffy, manganis, include_mdbook, and blitz so the ecosystem can grow together.

Dioxus vs Tauri

Tauri is a framework for building desktop mobile apps where your frontend is written in a web-based framework like React, Vue, Svelte, etc. Whenever you need to do native work, you can write Rust functions and call them from your frontend.

  • Natively Rust: Tauri's architecture limits your UI to either JavaScript or WebAssembly. With Dioxus, your Rust code is running natively on the user's machine, letting you do things like spawning threads, accessing the filesystem, without any IPC bridge. This drastically simplifies your app's architecture and makes it easier to build. You can build a Tauri app with Dioxus-Web as a frontend if you'd like.

  • Different scopes: Tauri needs to support JavaScript and its complex build tooling, limiting the scope of what you can do with it. Since Dioxus is exclusively focused on Rust, we're able to provide extra utilities like Server Functions, advanced bundling, and a native renderer.

  • Shared DNA: While Tauri and Dioxus are separate projects, they do share libraries like Tao and Wry: windowing and webview libraries maintained by the Tauri team.

Dioxus vs Leptos

Leptos is a library for building fullstack web-apps, similar to SolidJS and SolidStart. The two libraries share similar goals on the web, but have several key differences:

  • Reactivity model: Leptos uses signals to drive both reactivity and rendering, while Dioxus uses signals just for reactivity. For managing re-renders, Dioxus uses a highly optimized VirtualDOM to support desktop and mobile architectures. Both Dioxus and Leptos are extremely fast.

  • Different scopes: Dioxus provides renderers for web, desktop, mobile, LiveView, and more. We also maintain community libraries and a cross-platform SDK. Leptos has a tighter focus on the fullstack web with features that Dioxus doesn't have like islands, <Form /> components, and other web-specific utilities.

  • Different DSLs: Dioxus uses its own custom Rust-like DSL for building UIs while Leptos uses an HTML-like syntax. We chose this to retain compatibility with IDE features like code-folding and syntax highlighting. Generally, Dioxus leans into more "magic" with its DSL including automatic formatting of strings and hot-reloading of simple Rust expressions.

// dioxus
rsx! {
  div {
    class: "my-class",
    enabled: true,
    "Hello, {name}"
  }
}

// leptos
view! {
  <div class="my-class" enabled={true}>
    "Hello "
    {name}
  </div>
}

Dioxus vs Yew

Yew is a framework for building single-page web apps and initially served as an inspiration for Dioxus. Unfortunately, the architecture of Yew didn't support the various features we wanted, and thus Dioxus was born.

  • Single-page apps: Yew is designed exclusively for single-page web apps and is intrinsically tied to the web platform. Dioxus is fullstack and cross-platform, making it suitable for building web, desktop, mobile, and server apps.

  • Developer Tooling: Dioxus provides a number of utilities like autoformatting, hot-reloading, and a bundler.

  • Ongoing support: Dioxus is very actively maintained with new features and bug fixes being added on a daily basis.

Dioxus vs egui

egui is a cross-platform GUI library for Rust powering tools like Rerun.io.

  • Immediate vs Retained: egui is designed to be re-rendered on every frame. This is suitable for games and other interactive applications, but it does not retain style and layout state between frames. Dioxus is a retained UI framework, meaning that the UI is built once and then modified between frames. This enables Dioxus to use native web technologies like HTML and CSS with better battery life and performance.

  • Customizable: egui brings its own styling and layout solution while Dioxus expects you to use the built-in HTML and CSS. This enables dioxus apps to use any CSS library like Tailwind or Material UI.

  • State management: egui's state management is based on a single global state object. Dioxus encourages encapsulation of state by using components and props, making components more reusable.

Dioxus vs Iced

Iced is a cross-platform GUI library inspired by Elm. Iced renders natively with WGPU and supports the web using DOM nodes.

  • Elm state management: Iced uses Elm's state management model, which is based on message passing and reducers. This is simply a different state management model than Dioxus and can be rather verbose at times.

  • Native Feel: Since Dioxus uses a webview as its renderer, it automatically gets native text input, paste handling, and other native features like accessibility. Iced's renderer currently doesn't implement these features, making it feel less native.

  • WGPU: Dioxus' WGPU renderer is currently quite immature and not yet ready for production use. Iced's WGPU renderer is much more mature and is being used in production. This enables certain types of apps that need GPU access to be built with Iced that can't currently be built with Dioxus.

Dioxus vs Electron

Dioxus and Electron are two entirely different projects with similar goals. Electron makes it possible for developers to build cross-platform desktop apps using web technologies like HTML, CSS, and JavaScript.

  • Lightweight: Dioxus uses the system's native WebView - or optionally, a WGPU renderer - to render the UI. This makes a typical Dioxus app about 15mb on macOS in comparison to Electron's 100mb. Electron also ships an embedded chromium instance which cannot share system resources with the host OS in the same way as Dioxus.

  • Maturity: Electron is a mature project with a large community and a lot of tooling. Dioxus is still quite young in comparison to Electron. Expect to run into features like deep-linking that require extra work to implement.

Contributing

License

This project is licensed under either the MIT license or the Apache-2 License.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Dioxus by you, shall be licensed as MIT or Apache-2, without any additional terms or conditions.

S
Description
Fork of DioxusLabs/dioxus v0.7.10 with the patches Coach vs Coach needs: iOS FFI Retained (PR #5733), Android versionCode (PR #5735), JNI classloader fix, Gradle pins. Branch: v0.7.10-sw
Readme
53 MiB
0 Stars 1 Watchers 0 Forks
Languages
Rust 92.8%
HTML 2.2%
R 2%
JavaScript 1.2%
TypeScript 1.1%
Other 0.5%