4 ms·

I’ve been watching this for a while. It’s the most promising tech framework I’ve seen. If they succeed, it could obsolete all other frameworks. Mobile, deskt

I’ve been watching this for a while. It’s the most promising tech framework I’ve seen. If they succeed, it could obsolete all other frameworks. 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.

J_Shelby_J 2y ago
Imagine hitting deploy and your app builds for every platform that exists.
- highwaylights 2y ago
  There’s this https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... And to a lesser extent this: https://expo.dev/ https://expo.dev/ (It won’t target games consoles or non-headless edge devices, that I know of).
- bitbasher 2y ago
  ^ Like a website? https://xkcd.com/1367/ https://xkcd.com/1367/
- jcelerier 2y ago
  idk I do this in plain ol' C++ with Qt & CMake, every commit builds for mac, windows with msvc and mingw, 15-ish linux distros / configurations, web, bsd... https://github.com/ossia/score?tab=readme-ov-file#build-status https://github.com/ossia/score?tab=readme-ov-file#build-stat...
highwaylights 2y ago
It could well become very popular, but using words like “magical” and “blazing fast” immediately triggers my framework fatigue. 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.
- aloisdg 2y ago
  > To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim. 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.
  - diablozzq 2y ago
    With ChatGPT they may not need to learn it the same way. 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.
- jkelleyrtp 2y ago
  Our hot-reloading is "magic" for the Rust ecosystem (this post's original intended audience). Hot-reloading formatted strings and simple Rust code is basically magic in Rust land. 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_chrome_116.0.5845.82.html https://krausest.github.io/js-framework-benchmark/2023/table...
  - highwaylights 2y ago
    It seems like an interesting project, but using Skia (or any canvas/GPU render) concerns me for a bunch of reasons, not unlike Flutter. 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.
risyachka 2y ago
All in one (Mobile, desktop, web) always sounds nice until you actually do a multi platform app. 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.
airstrike 2y ago
For cross-platform desktop (and WASM), I'm still betting on iced, which I use daily. It's just so. blazing. fast. 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.
bryanhogan 2y ago
Is there really more potential compared to Capacitor or Tauri?
cardanome 2y ago
I don't see any use case where you couldn't write your app in a garbage collected language. 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.
klabb3 2y ago
> If they succeed, it could obsolete all other frameworks > 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.
- jkelleyrtp 2y ago
  Not sure if you grok 100% what we're building. 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.
  - klabb3 2y ago
    > Not sure if you grok 100% what we're building. 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?

J_Shelby_J 2y ago

Imagine hitting deploy and your app builds for every platform that exists.

highwaylights 2y ago
There’s this https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... And to a lesser extent this: https://expo.dev/ https://expo.dev/ (It won’t target games consoles or non-headless edge devices, that I know of).
bitbasher 2y ago
^ Like a website? https://xkcd.com/1367/ https://xkcd.com/1367/
jcelerier 2y ago
idk I do this in plain ol' C++ with Qt & CMake, every commit builds for mac, windows with msvc and mingw, 15-ish linux distros / configurations, web, bsd... https://github.com/ossia/score?tab=readme-ov-file#build-status https://github.com/ossia/score?tab=readme-ov-file#build-stat...

highwaylights 2y ago

It could well become very popular, but using words like “magical” and “blazing fast” immediately triggers my framework fatigue. 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.

aloisdg 2y ago
> To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim. 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.
- diablozzq 2y ago
  With ChatGPT they may not need to learn it the same way. 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.
jkelleyrtp 2y ago
Our hot-reloading is "magic" for the Rust ecosystem (this post's original intended audience). Hot-reloading formatted strings and simple Rust code is basically magic in Rust land. 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_chrome_116.0.5845.82.html https://krausest.github.io/js-framework-benchmark/2023/table...
- highwaylights 2y ago
  It seems like an interesting project, but using Skia (or any canvas/GPU render) concerns me for a bunch of reasons, not unlike Flutter. 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.

risyachka 2y ago

All in one (Mobile, desktop, web) always sounds nice until you actually do a multi platform app. 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.

airstrike 2y ago

For cross-platform desktop (and WASM), I'm still betting on iced, which I use daily. It's just so. blazing. fast. 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.

bryanhogan 2y ago

Is there really more potential compared to Capacitor or Tauri?

cardanome 2y ago

I don't see any use case where you couldn't write your app in a garbage collected language. 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.

klabb3 2y ago

> If they succeed, it could obsolete all other frameworks > 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.

jkelleyrtp 2y ago
Not sure if you grok 100% what we're building. 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.
- klabb3 2y ago
  > Not sure if you grok 100% what we're building. 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?