I've just starting with Rust development, and I am no Android developer. Just delivered my first Crux+Android app this week, and it worked very well, seems promising. Reusing all your structs in the backend (Axum) is really a big win for me.
Very interesting idea. Especially nowadays Figma can just export pretty decent UI layer. You just need to connect it. I have similar experience with TS, I cannot trust it completely and therefore it’s not as helpful as I would need. Also the pain of writing e2e tests is spot on.
This talk would have benefited from running it by a ReactNative/TypeScript dev first. There is a bunch of unimportant (and plain wrong) explanations about the state of tech. But this IS an interesting idea, and I would have loved a higher resolution view of the ACTUAL differences and unique aspects (both good and bad).
I think state and UI need to be close each other. splitting these is killing productivity IMO. But these maybe good use-cases, for example very complex states which needs to be exactly the same every platform. Nowadays, server-side functionality is hot topic. So handling state on server with crux could be also a good use-case.
In what ways? :) You can achieve both web and mobile with the same codebase with considerably better performance on the mobile side with React Native. Have you tried building a universal app using Solito, Tamagui and Expo Router?
@@wezter96 react native is dependency hell. capacitor can use react or just plain vanilla javascript and writing native java/kotlin, objectiveC/Swift is a lot less nuanced and I dont need to rely on third party deprecated modules for features ever. I want less dependencies not more. I tried them all and capacitor is a clear winner for me in all fronts. Better development experience, no fighting with frameworks, works with every web tech. I dont need to eject config to modify native code. Writing capacitor plugins is very easy
@@jhonyhndoea But it is not rendering any native components right? It's a webview that you can bridge with native aspects. There's not really anything you can use with Capacitor that you couldn't use within a React Native WebView right? So you lose out on native rendering, you lose out on performance and it's rendering a web application inside a mobile app pretty much right?
@@wezter96 It is a webview, yes. But you don't loose out on native rendering if you make part of your UI with native code. For me, it was this seamless mixing of the two that works out because I don't want to write it all in JS. And also I don't wanna install NPM dependency to access native functionality, like with expo, I prefer to implement it.
@@jhonyhndoea you can write as much native code as you want with Expo as well and it is using native rendering by default. Just make Expo modules or turbo modules for whatever native code you want to integrate on your own. So Yes you do lose out on native rendering with Capacitor because you have to build it all on your own and then it won't be using the webview or the web code for rendering at all so you will basically end up building a poor man's version of React Native 😅
Zig doesn't solve issues like use after free, so what's the point? If C is a turd, then Zig is just polishing the turd, where as Rust actually solves these issues.
Zig is great-from what I've heard, at embedded programming, it's nicer than Rust-but it's not as good at domain modeling, which is the main takeaway from this talk.
@@ThomazMartinez basically every use case? Because I don't see any areas where you'd willingly want segfaults. And before you say something about manual memory management, Rust has that too via the unsafe block, if you really want to, but that is rare to use by its very nature.
Zig is not even released yet, doesn't have proper documentation and basically no one uses Zig in prod, except the Zig compiler for cross compilation, not the language itself. :D Now that is a bad decision.
I've just starting with Rust development, and I am no Android developer. Just delivered my first Crux+Android app this week, and it worked very well, seems promising. Reusing all your structs in the backend (Axum) is really a big win for me.
Very interesting idea. Especially nowadays Figma can just export pretty decent UI layer. You just need to connect it.
I have similar experience with TS, I cannot trust it completely and therefore it’s not as helpful as I would need.
Also the pain of writing e2e tests is spot on.
Seems like dioxus is a better abstraction for this use case
This talk would have benefited from running it by a ReactNative/TypeScript dev first.
There is a bunch of unimportant (and plain wrong) explanations about the state of tech.
But this IS an interesting idea, and I would have loved a higher resolution view of the ACTUAL differences and unique aspects (both good and bad).
Why there is no Xamarin as cross platform option ?
I think state and UI need to be close each other.
splitting these is killing productivity IMO.
But these maybe good use-cases, for example very complex states which needs to be exactly the same every platform.
Nowadays, server-side functionality is hot topic. So handling state on server with crux could be also a good use-case.
You have actually video titlted "Why Airbnb was wrong to ditch React Native in 2018 - Mohammad Javad - RNL - August 2023" then this video.
Rust funboys are having a moment. Don't burst their bubble
capacitor is much better than react native.
In what ways? :)
You can achieve both web and mobile with the same codebase with considerably better performance on the mobile side with React Native.
Have you tried building a universal app using Solito, Tamagui and Expo Router?
@@wezter96 react native is dependency hell. capacitor can use react or just plain vanilla javascript and writing native java/kotlin, objectiveC/Swift is a lot less nuanced and I dont need to rely on third party deprecated modules for features ever. I want less dependencies not more.
I tried them all and capacitor is a clear winner for me in all fronts. Better development experience, no fighting with frameworks, works with every web tech. I dont need to eject config to modify native code. Writing capacitor plugins is very easy
@@jhonyhndoea But it is not rendering any native components right?
It's a webview that you can bridge with native aspects. There's not really anything you can use with Capacitor that you couldn't use within a React Native WebView right? So you lose out on native rendering, you lose out on performance and it's rendering a web application inside a mobile app pretty much right?
@@wezter96 It is a webview, yes. But you don't loose out on native rendering if you make part of your UI with native code.
For me, it was this seamless mixing of the two that works out because I don't want to write it all in JS.
And also I don't wanna install NPM dependency to access native functionality, like with expo, I prefer to implement it.
@@jhonyhndoea you can write as much native code as you want with Expo as well and it is using native rendering by default. Just make Expo modules or turbo modules for whatever native code you want to integrate on your own.
So Yes you do lose out on native rendering with Capacitor because you have to build it all on your own and then it won't be using the webview or the web code for rendering at all so you will basically end up building a poor man's version of React Native 😅
1st to comment and 2nd likes😊
OMG moving to rust is horrible, really bad decision, much preferred if you chose Zig
Zig doesn't solve issues like use after free, so what's the point? If C is a turd, then Zig is just polishing the turd, where as Rust actually solves these issues.
@@zzzyyyxxx give me use case that this is an issue?
Zig is great-from what I've heard, at embedded programming, it's nicer than Rust-but it's not as good at domain modeling, which is the main takeaway from this talk.
@@ThomazMartinez basically every use case? Because I don't see any areas where you'd willingly want segfaults. And before you say something about manual memory management, Rust has that too via the unsafe block, if you really want to, but that is rare to use by its very nature.
Zig is not even released yet, doesn't have proper documentation and basically no one uses Zig in prod, except the Zig compiler for cross compilation, not the language itself.
:D Now that is a bad decision.