Dioxus 0.6 – Crossplatform apps with Rust
dioxuslabs.com
dioxuslabs.com
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!
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.
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.
We don't need the OSS crowdsourced funding. Early 2025 I have plans to distribute whatever OSS capital we still have back into the Rust community, so at least donors won't feel like their money went directly into a company.
Fortunately, we did raise a good round and have plans to get "more serious" about it. Hiring is hard and this year it was challenging to balance hiring with solving users' issues in a timely manner. It's my first time doing it. Lots of the project's details are tucked deep in the depths of my brain.
We sadly have the curse of maintaining a project where the devtools need to work on mac/win/linux/wsl and the apps need to work on mac/win/linux/wasm/wsl/android/ios. I don't think people grok the scope of this work and the permutation explosion it brings. We test against mac/windows/linux of course, but there's always some weird issue with WSL or Windows Paths or some dependency's missing system library.
For example, we had to drop 3rd party tooling for mobile this release since that was constantly breaking our setups. There's still more dependencies we don't own completely that break frequently. I'm hopeful that hiring a larger team and prioritizing quality for the next few months will "solve" the majority of issues people run into.
I really hope one cements itself as the "go to" framework in the next couple of years. Good luck!
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.I had OpenSSL as a dependency, and if `PKG_CONFIG_PATH` changes it rebuilds it (this is correct), which means if you make an edit to a file and save it, rust-analyzer would blow away the cache, then you build it on the command line and it blows it away again.
To test:
1. If you quit VSCode and do an incremental build is it still slow? 2. Try `CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build` (took me a while to find that; there is a bug open to make it less stupidly hard to find).
That will print a load of info about why Cargo is rebuilding stuff. Note that it isn't really in a sensible order - the first message isn't necessarily the cause. The message about the environment variable changing was somewhere in the middle for me, so read the whole log.
I actually figured out the issue! It turns out, I had unquestioningly transplanted the following from the blog post in discussion, and that is the cause of all my issues:
[profile.dev]
opt-level = 1
[profile.dev.package."*"]
opt-level = 3
(Worth noting: it was passing RUSTFLAGS=-Ztime-passes that made me look here because, apparently, `llvm_passes` was taking the majority of the time).
One thing that popped out is that you might want to try to define dependencies at the workspace level and then in the sub-crates point to those instead.
Otherwise you are correct, your setup is already very granular. Furthermore, I have no clue about why it takes so long on your end :/ . I am running on Linux, so I wonder if there's something in the MacOs stack that messes things up and so you end up recompiling dependencies over and over.
Another thing I noticed in my setup is that one of the biggest offenders was sqlx if the macro feature was enabled since the queries were ran at each incremental compilation.
I figured out the issue: I transplanted the bit about setting optimization levels from the blogpost into my setup (which sets opt-level = 3 for all dependencies), and when I removed that, my compile times went down by a factor of 5-10!
Make sure that your ide/vscode is using the exact same rust toolchain as you to build/check/run. Otherwise you don't get incremental compiling but recompilation a lot. I think there's an environment variable to force it.
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!
As my little side project, we pioneered html-templates, wasm-bindgen string interning, macro hot-reloading, macro auto-formatting, multi-platform builds, native HTML/css rendering, and a number of other "awesome" things before raising a dollar.
Users want a guarantee the project isn't going to disappear tomorrow and sadly 100 bucks a month on open collective isn't a great guarantee.
I'm particularly excited about your research on actually hot-reloading Rust binary code. I hope it leads to reduced incremental compilation times (IIUC).
VC capital is just one indicator. Maybe you can answer:
Do you require a CLA or copyright assignment? I don't see it on the GitHub page but then again other projects (like MongoDB) have hidden theirs pretty well.
How many of the contributors are directly payed for their contributions?
There's no CLA. Dioxus is MIT/Apache-2 licensed.
> How many of the contributors are directly payed for their contributions?
I unfortunately feel like you're asking this in bad faith. Our team is very small, we're very lean, and we have funding sources that aren't just venture. We also have a very active community and people are building new libraries and becoming dioxus contributors every day.
https://github.com/DioxusLabs/dioxus/releases/tag/v0.6.0 (scroll to contributors)
If you say your team is small I understand that it is not the majority of contributors that are on your payroll and that is good enough for me to see Dioxus as a real community project.
Thanks for your answers.
I don’t see why volunteer dev work would be more valuable. It’s the same work. Those people have the same living costs.
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.
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.
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.
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).
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?
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.
What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?
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.
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?
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.
> 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.
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).
Do they require copyright assignment or a CLA? I could not find anything on their GitHub.
How many of their contributors are payed?
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.
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?
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.
Tauri is an electron alternative. It handles windows creation, rendering of web pages as well as IPC between frontend and backend.
Dioxus is a frontend framework similar to Next.js and other react-based frameworks.
Flutter uses an entirely different approach to GUI.
When I say we use a webview, people immediately jump to Tauri. But we're very architecturally different than Tauri. No WASM on native, just a regular old executable.
When I compare us to Flutter, people immediately think of Flutter's negatives (poor web support). We have excellent web support (DOM is 1st class).
When I compare us to React Native, people immediately think the web is 2nd-class and then wonder why we don't implement NSScrollView and all that.
We are shooting for something like Flutter (web, desktop, mobile, embedded) but where the web is the defining feature.
As someone outside Dioxus, how do you think I should describe it?
ah I missed that... I read something about Flutter and WASM and kind of assumed it was rendering to canvas
that's very nice
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.
You want to use a macro for this so you can do hot-reloading - doing it with native Rust is currently impractical for rapid dev.
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
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.
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.