11–20 of 52 posts
Earlier quoted context omitted.
What is there not to like? RSCs simplify state management by so much. There is no longer any need for zustand, redux, etc.
As someone who lightly dabbles in React my interpretation of that comment is “what’s not to like? It solves at least some of the problems React itself introduced!”
I was looking for a solution like this as rspc isn't maintained anymore. I love how clean it looks. But I am a bit new to rust and I am not sure about poem. Axum is very popular and seems like a stable crate. Can you share your thoughts on Poem? Does it feel outdated or unstable? Does it cover all your needs?
There's the poem crate and then there is the poem-openapi crate. The latter is used in this case and it provides very ergonomic ways to define an OpenAPI service in pure Rust. It's nicer than using the utoipa crate with axum (whilch ist still fairly nice, so no shade here).
I'm happy with poem-openapi.
Earlier quoted context omitted.
What is there not to like? RSCs simplify state management by so much. There is no longer any need for zustand, redux, etc.
Really few applications ever needed redux, whatever the backend
I was looking for a solution like this as rspc isn't maintained anymore. I love how clean it looks. But I am a bit new to rust and I am not sure about poem. Axum is very popular and seems like a stable crate. Can you share your thoughts on Poem? Does it feel outdated or unstable? Does it cover all your needs?
> Can you share your thoughts on Poem? There's the poem crate and then there is the poem-openapi crate. The latter is used in this case and it provides very ergonomic ways to define an OpenAPI service in pure Rust. It's nicer than using the utoipa crate with axum (whilch ist still fairly nice, so no shade here). I'm happy with poem-openapi.
Earlier quoted context omitted.
What is there not to like? RSCs simplify state management by so much. There is no longer any need for zustand, redux, etc.
As someone who lightly dabbles in React my interpretation of that comment is “what’s not to like? It solves at least some of the problems React itself introduced!”
You never had to do state management before React? Maybe it wasn't called that but I definitely had to manage some state between frontend and backend in webapps.
Also it's hard to tell what problems come from React and what from any SPA. As I keep familiar with React development I'm inclined to say that almost all React problems people are complaining about are SPA problems and modern React is the only framework that even dares to try to solve them and does it increasingly successfully.
Was hoping this was about WebAssembly/WASM. You used to be able to import rust directly into your JS with Parcel, but sadly that feature was dropped in Parcel 2. Is there a simple pipeline for compiling and typesafe binding of Rust-WASM?
But, I did a brief exploration to see how I could compile those WASM Components in any language (including JavaScript), and as far as I can tell, if you could use ComponentizeJS + jco for compiling JavaScript to WASM Components, and if you need to run them in JavaScript too, StarlingMonkey seems to be able to handle that.
I'm not sure about the last part, typesafe bindings would require you to use TypeScript or similar, not just JavaScript. I don't use TypeScript myself so I don't know if the approach above would give you any type safety on the Component-implementation side.
Why do you need a separate back-end in Rust? Nothing beats Next.js + React server components for me.
Such a generic question, with probably hundreds of possible answers, it really depends on the context. From the top of my mind, whatever library/program you wanna use only being available in $Language comes to mind as something you encounter at least once in your career as a programmer.