3 ms·

It would be interesting to see, in a real world app developed this way, how much weight is actually being carried by the Rust portion. I feel like it might not

It would be interesting to see, in a real world app developed this way, how much weight is actually being carried by the Rust portion. I feel like it might not be much? The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. And while can see the advantage of having a crossplatform layer for that stuff.. even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. But I'm willing to be convinced.

andrekandre 3y ago
> The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. its true, though it doesn't necessarily have to be that way (view models (or even bff) if done properly) speaking from experience, i think the big issue is how will your dev team be structured... will android/ios people be able to write idiomatic rust (or whatever language) or should that core be a completely separate team? now you cant just hire any dev, they need to understand how it's going to be used by multiple client languages specific to that cross-platform system though this framework looks like its pre-baking the architecture which means it probably wont look idiomatic from the client-side, so now your hiring for ui needs to take that into account... and now you have multiple teams that need to communicate adding overhead. using cross-platform sounds simple and easy in the beginning but its a big commitment with multiple facets i'm not sure what the real answer is... my guess is "it depends: what are you actually trying to do?"
mdgrech23 3y ago
This is a good point. I remember about 2005 time frame and probably even after everyone thought the front end was easy and the "real" work was on the server. What a joke.
- scns 3y ago
  Arrogance (trying to hide low self-esteem) has many faces.
fiedzia 3y ago
> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.
- raincole 3y ago
  > UI libraries aside I mean the rest of your comment may be 100% correct but we could stop reading at this point. Obviously the biggest pain point of Rust GUI app development is UI library.
  - fiedzia 3y ago
    True, it will take time. Tauri/Dioxus and others are still new and far from being mature. If you want to deliver project right now, Rust is not there, but moving in the right direction quickly.
- jeroenhd 3y ago
  Normally I agree with you on the tooling issue for JS/TS, but just look at the boilerplate you need for this Rust tool. I think it's very close in terms of obscure config files and tooling, complete with multi step build and generation processes. I think Rust isn't a great frontend language for mobile platforms. Mobile applications are full of weak references because of how they can be unloaded or cached at any moment when the user switches to another application. The native APIs dance around this issue, but Rust can't. Of course you can use weak reference in Rust, but I find that this leads to very ugly code full of macros that aren't very Rust looking.
  - fiedzia 3y ago
    Boilerplate and process: This in part is a matter of tooling maturity and can easily be solved, and in part will be hidden in some github action, so I am not bothered (as long as solution is maintained). With amount popularity Rust tools have and increasing amount of money invested, I am not concerned here. As for macros - yes, you will have them. Doesn't seem to be any more special than react or any other js framework where some magic is performed for you.
nijaar 3y ago
For mobile it may be very important performance for some cases (too repetitive or just heavy load) so using Rust allows to compile to the specific mobile architecture. The same is not possible with typescript which just run in the JSVirtualMachind
proxyon 3y ago
It's still mostly in the presentation layer. This framework is pointless and solves an already solved problem.
lukax 3y ago
It depends on the application. If your app just displays data from a REST or GraphQL API it does not really make sense. But if your app is self-contained (it's mostly logic inside the app) it makes sense to have a shared core for models and business logic.
erlend_sh 3y ago
Matrix (primarily developed by the Element company) is rewriting its mobile apps based on a common SDK and rich text editor written in Rust: https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rich-text-editor https://github.com/matrix-org/matrix-rich-text-editor The apps themselves are written in Swift and Kotlin respectively, but it’s notable that they can now do this duplicate work much more sustainably because the bulk of their app code lives in a unified Rust layer.

andrekandre 3y ago

> The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. its true, though it doesn't necessarily have to be that way (view models (or even bff) if done properly) speaking from experience, i think the big issue is how will your dev team be structured... will android/ios people be able to write idiomatic rust (or whatever language) or should that core be a completely separate team? now you cant just hire any dev, they need to understand how it's going to be used by multiple client languages specific to that cross-platform system though this framework looks like its pre-baking the architecture which means it probably wont look idiomatic from the client-side, so now your hiring for ui needs to take that into account... and now you have multiple teams that need to communicate adding overhead. using cross-platform sounds simple and easy in the beginning but its a big commitment with multiple facets i'm not sure what the real answer is... my guess is "it depends: what are you actually trying to do?"

mdgrech23 3y ago

This is a good point. I remember about 2005 time frame and probably even after everyone thought the front end was easy and the "real" work was on the server. What a joke.

scns 3y ago
Arrogance (trying to hide low self-esteem) has many faces.

fiedzia 3y ago

> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.

raincole 3y ago
> UI libraries aside I mean the rest of your comment may be 100% correct but we could stop reading at this point. Obviously the biggest pain point of Rust GUI app development is UI library.
- fiedzia 3y ago
  True, it will take time. Tauri/Dioxus and others are still new and far from being mature. If you want to deliver project right now, Rust is not there, but moving in the right direction quickly.
jeroenhd 3y ago
Normally I agree with you on the tooling issue for JS/TS, but just look at the boilerplate you need for this Rust tool. I think it's very close in terms of obscure config files and tooling, complete with multi step build and generation processes. I think Rust isn't a great frontend language for mobile platforms. Mobile applications are full of weak references because of how they can be unloaded or cached at any moment when the user switches to another application. The native APIs dance around this issue, but Rust can't. Of course you can use weak reference in Rust, but I find that this leads to very ugly code full of macros that aren't very Rust looking.
- fiedzia 3y ago
  Boilerplate and process: This in part is a matter of tooling maturity and can easily be solved, and in part will be hidden in some github action, so I am not bothered (as long as solution is maintained). With amount popularity Rust tools have and increasing amount of money invested, I am not concerned here. As for macros - yes, you will have them. Doesn't seem to be any more special than react or any other js framework where some magic is performed for you.

nijaar 3y ago

For mobile it may be very important performance for some cases (too repetitive or just heavy load) so using Rust allows to compile to the specific mobile architecture. The same is not possible with typescript which just run in the JSVirtualMachind

proxyon 3y ago

It's still mostly in the presentation layer. This framework is pointless and solves an already solved problem.

lukax 3y ago

It depends on the application. If your app just displays data from a REST or GraphQL API it does not really make sense. But if your app is self-contained (it's mostly logic inside the app) it makes sense to have a shared core for models and business logic.

erlend_sh 3y ago

Matrix (primarily developed by the Element company) is rewriting its mobile apps based on a common SDK and rich text editor written in Rust: https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rust-sdk https://github.com/matrix-org/matrix-rich-text-editor https://github.com/matrix-org/matrix-rich-text-editor The apps themselves are written in Swift and Kotlin respectively, but it’s notable that they can now do this duplicate work much more sustainably because the bulk of their app code lives in a unified Rust layer.