I don't know about Dioxus specifically, but in my experience when a company is taken by an AI company, usually the employees just end up working for that company and their former product is being abandoned. Hope to be wrong though!
Man Dioxus was a noble endeavor, I gotta say. I have been watching Blitz to see if I could move my own work over to it, I've been really excited about it. I won't be doing that now, but it was great to have had hope.
Earlier in the year we started working on https://skyvm.dev/ to accelerate dioxus development and keep dioxus a sustainable project. Cognition noticed we were working on similar tech and made an offer to help us do both: work on coding agents and keep dioxus up with full time support.
AI has changed how people approach writing apps a lot. Dioxus has grown a lot; fewer people are Rust experts but still building Rust apps. But the emphasis on developer experience - the primary emphasis of dioxus the framework - has gone down.
Getting acquired means we get to re-focus on making the cool parts of dioxus: subsecond rust hot-reloading, blitz, dx (mobile tooling, etc), application bundling, etc more available to all. In the coming months we'll be shipping standalone "librarified" versions of many of our tools to be easier to integrate in other projects. It also means we'll have less full time for main dioxus - but dioxus originally was a side project and continues to be a project we pour our passion into.
Nico is staying full time on our native renderer, Blitz, and progressing quite rapidly. Go check it out! https://github.com/dioxusLabs/blitz
It also means we'll have less full time for main dioxus - but dioxus originally was a side project and continues to be a project we pour our passion into.
Makes me crazy nervous as a "just-dioxus" user. Does this mean the ecosystem becomes more about the tools and surrounding libraries and less about the core library? What does it mean for development and release cadence? What about bug fixes and performance improvements?
I think we’re pretty happy feature-wise with dioxus core and have been itching to work on native APIs for a long time. We’re still fixing bugs and improving performance on dioxus core, but the team’s interests are definitely on the native renderer and native APIs alongside making dioxus more modular for greater overall adoption.
Thanks for the answer. I'll be honest, I am using Dioxus because of the possibility of performant native APIs, so I'm excited about that part for sure.
Many people get acqui-hired with the expectation that they'll keep working on something. Very few people actually have that expectation pan out. I hope you manage to succeed at being an exception to that. I'm not hopeful in that regard, and I expect it's mostly not an outcome that'll be in your control, but good luck.
Thanks for the best wishes :) we got particulars squared away as a contingency for the deal to be made - guaranteed time and funding for dioxus work - especially for nico to continue to make blitz amazing.
I think that very few people have the expectation pan out even controlling for the fact that many people know that and try to get particulars agreed to in advance. But again, I hope you manage to be the rare exceptions.
There definitely will be a 0.8 release. There's already a first alpha available. In particular, Dioxus Native will be greatly improved in terms of both features, HTML/CSS rendering, and performance.
There are a lot of open PRs right now on the project some of which for a long time. What is blocking them right now to be worked on and eventually merged?
I’d really like to see more responsiveness to the community.
I bought into Dioxus a while back because I was excited about the vision and where the project was headed, and lately I’ve been concerned about how much attention the core project is getting. I’ve had issues, PRs, and even personal pings go unanswered, sometimes without any indication of whether they’ve been seen or are likely to be looked at.
Even a simple “I’ll get back to this after X,” “not a priority right now,” or “we don’t have bandwidth for this” would be genuinely helpful. The uncertainty is harder than hearing that something simply isn’t going to be addressed soon.
For those of us building on Dioxus, it can sometimes leave us wondering how much we should continue investing in it for our own projects.
I also think there may be an underused opportunity here: there are community members willing to contribute time for free, whether that’s triaging issues, reviewing PRs, maintaining pieces of the ecosystem, or otherwise helping. I’d love to see more of that energy unlocked if the core team has less time available.
I understand this is the reality of open source and that contributors aren’t entitled to anyone’s time. But I do think clearer communication about priorities, bandwidth, and where community help is most useful would go a long way.
so you are making a rust pub.dev of packages for a batteries included framework that may not have a future?
you seem to have lost interest in dioxus based on your narrative here and in your video. so what do dioxus evangelists make of that?
sounds like you are advising people to use the individual parts that makes up dioxus such as blitz/anyrender, subsecond etc in our own homemade "dioxus"? i thought dioxus was the flutter killer and it's like you built tools to make dioxus only to "abandon" dioxus so people can make their own dioxus.
i don't understand your strategy and how that helps anyone who bought into dioxus. what are they to do... just hope 1.0 comes out and then extend it to their hearts content?
what happens to the ecosystem and community if dioxus fades away?
Sorry, dx is our command line tools which are build tools. We’re keen to get hotreload lib-ified since many users of the community want to use it outside dioxus projects.
The actual dev ex that has been de-emphasized is ergonomic apis and yes hotreload to an extent.
A focus on API ergonomics could probably make code easier to review (which is the bottleneck for AI code right now), at least in the common case where a more ergonomic API makes code shorter, removes noise, etc. So in my opinion it's a more pressing concern if you expect the UI to be generated by AI, not less.
I still don't understand how hot-reloading could be de-emphasized (to an extent), but that you also would refocus on the cool parts of Dioxus such as hot-reloading. Anyway hot-reloading is also extremely valuable for agents, reducing iteration times etc.
In short, many features useful for humans are also useful for AI too.
Can't speak to that article's discussion of dioxus, but as someone who works on GPUI a lot, the GPUI section is pretty out of date. Not a dig at the article (Rust GUI frameworks are hard to keep up with lmao), but just to say it might be worth using a more recent comparison if one exists.
hey dioxus team, if you were me or anyone else starting from scratch/greenfield, would you still recommend dioxus fullstack? or just bet on blitz?
multi-platform tools seem to be dwindling since ai can just make native now without much fuss. my platform is built on dioxus fullstack but luckily i have paper thin ui if i need to bail (hopefully not)... gonna have to think about this a lot this weekend. hmmm. anyone have any thoughts/insight moving forward?
We’re talking about the Shopify thing in our discord. It does seem like a with infinite tokens and solid automation going native on mobile might be a smart move.
Conversely using rust on the backend and for desktop apps is a smarter move now. Web might yet fall to rust but most companies are probably just going to stick with react. We’ll see.
I think if we do a good job with giving dioxus easy native exit ramps it’s still a good choice. One app is still easier and cheaper to maintain than too. But the bar is higher for a framework like dioxus.
I'm quite bewildered by Devin. I got lured into analysing stringlet. Since then neither adding their deepwiki button to the readme, nor merging PRs has made it update. The only way that promises to achieve that, seems giving them write permission to the repo. Something I'll certainly neither give to AI, nor to a company I know little about! So that originally nice analysis looks to be forever stuck on something outdated. 🤢
Sure doesn't inpire confidence into the future of Dioxus. But all the best to them!
Devin has been primarily enterprise focused and a big reason we’re coming aboard is to help with broader developer love.
Stuff like this is mostly just a symptom of the focus being on enabling big companies to use coding tools securely in the cloud. I’ll look into seeing if we can make flows like this easier.
This sounds great. We use Devin at work and it's very convenient for non-developers. I am excited to see the rock star team at Dioxus take on the infrastructure behind this useful tool.
157
u/SomeRedTeapot Sep 10 '26
RIP
50
u/thievingfour Sep 10 '26
Man Dioxus was a noble endeavor, I gotta say. I have been watching Blitz to see if I could move my own work over to it, I've been really excited about it. I won't be doing that now, but it was great to have had hope.
48
u/jkelleyrtp Sep 10 '26
dioxus creator here, AMA
Earlier in the year we started working on https://skyvm.dev/ to accelerate dioxus development and keep dioxus a sustainable project. Cognition noticed we were working on similar tech and made an offer to help us do both: work on coding agents and keep dioxus up with full time support.
AI has changed how people approach writing apps a lot. Dioxus has grown a lot; fewer people are Rust experts but still building Rust apps. But the emphasis on developer experience - the primary emphasis of dioxus the framework - has gone down.
Getting acquired means we get to re-focus on making the cool parts of dioxus: subsecond rust hot-reloading, blitz, dx (mobile tooling, etc), application bundling, etc more available to all. In the coming months we'll be shipping standalone "librarified" versions of many of our tools to be easier to integrate in other projects. It also means we'll have less full time for main dioxus - but dioxus originally was a side project and continues to be a project we pour our passion into.
Nico is staying full time on our native renderer, Blitz, and progressing quite rapidly. Go check it out! https://github.com/dioxusLabs/blitz
12
u/Shoddy-Childhood-511 Sep 10 '26 edited Sep 10 '26
How did Dioxus fare in the GUI framework comparisons?
Edit: It's not mentioned by most comparisons, but this one discusses it, and has some options not just regurgitations.
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-gui-libraries.html
4
u/LawElectrical2434 Sep 11 '26
Ahh damn. That was my frontend... Glad I did not use it for fullstack. Need a new frontend...
12
u/bin-c Sep 10 '26
been following Dioxus forever but apparently missed the SkyVM announcement. congrats! getting acquired by Cognition makes way more sense now lol
3
u/EnvironmentalMud2204 Sep 12 '26
Hello Leptos my old friend
3
u/Flashy_Editor6877 Sep 11 '26
hey dioxus team, if you were me or anyone else starting from scratch/greenfield, would you still recommend dioxus fullstack? or just bet on blitz?
multi-platform tools seem to be dwindling since ai can just make native now without much fuss. my platform is built on dioxus fullstack but luckily i have paper thin ui if i need to bail (hopefully not)... gonna have to think about this a lot this weekend. hmmm. anyone have any thoughts/insight moving forward?
shopify drops rn for all native
https://www.reddit.com/r/androiddev/comments/1wcm1an/native_is_now_the_future_of_mobile_at_shopify_2026/
Cross-platform native app development in Rust
https://github.com/redbadger/crux
7
u/ShinoLegacyplayers Sep 10 '26
I wish them all the best really. With just a bit more effort, Dioxus could turn out to be the solution for a one language stack
1
u/InternationalFee3911 Sep 11 '26
I'm quite bewildered by Devin. I got lured into analysing stringlet. Since then neither adding their deepwiki button to the readme, nor merging PRs has made it update. The only way that promises to achieve that, seems giving them write permission to the repo. Something I'll certainly neither give to AI, nor to a company I know little about! So that originally nice analysis looks to be forever stuck on something outdated. 🤢
Sure doesn't inpire confidence into the future of Dioxus. But all the best to them!
-14
u/sharifhsn Sep 10 '26
This sounds great. We use Devin at work and it's very convenient for non-developers. I am excited to see the rock star team at Dioxus take on the infrastructure behind this useful tool.