[candrewlee14]

I am a big fan of Rust… but I don’t understand how this type of framework would be a better choice than something in the JS/TS realm: Svelte, Solid, React, Vue, Angular, etc. I’m not calling those frameworks ideal, but it seems like working in the native lang of the web in a more mature ecosystem would be a better choice for almost anything. Is this a proof-of-concept framework, is anyone using this in production? When would it make sense to pick this over the alternatives?

[Nullabillity]

Actix is a server framework (akin to Express.js), those are all client frameworks. Even if you use any of those client frameworks you'll still need an API backend managing the data.

That said, personally I'd prefer Axum over Actix since I am... uncomfortable with its concurrency model (Actix uses a single-threaded Tokio runtime per core, while Axum uses a single multi-threaded Tokio runtime, allowing request handlers to be migrated between cores as needed).

[legerdemain]

What? No. If you treat Solid/React/Vue as "client frameworks," you miss out on 80% of their purpose, things like server-side rendering, client-server isomorphism and sharing types across a network boundary, server components, smart hydration, and recent novelties like the "island architecture." All of these things rely on having full-stack JS, client and server.

I've used Actix. I'm fine with Actix, and I'm sure it works great for web APIs in production environments. But if you have GUI-based web applications or even just e-commerce in mind, that world has moved on from a simple bright line dividing client and server yeeeeears ago, and it has mostly converged on the kinds of full-stack JS architectures that React/Solid/Vue/whatever are pushing forward.

There is basically no story in the Rust ecosystem for the production story that Next/Remix/etc/etc are enabling. Compiling to WASM or serving WASM payloads, yes, pure web APIs, yes, "modern web apps," no.

[satvikpendem]

Again, those are for displaying data on a frontend, even if the content itself is server side rendered. Actix and others are made for API servers, ie authentication of users, accessing the database, performing computations, and returning the resultant JSON. You can return HTML too which is what I suspect you're referring to but most people simply use frameworks like Actix or express as a backend API server which connects to a client-side frontend or something like NextJS.

[simjnd]

Solid, Svelte, React and Vue are component frameworks and are client frameworks. In production, you have to bring in Next, Nuxt, SvelteKit, SolidStart, Remix or similar which are the "full-stack" frameworks using the component frameworks.

[candrewlee14]

Thanks for the clarification, totally missed that. Makes much more sense. I’m with you on the concurrency model. What was the reasoning for a runtime per core?

[Nullabillity]

Task migrations are (relatively) expensive, and runtime-per-core lets you write request handlers that aren't Send+Sync. It's the kind of thing that looks good in benchmarks.

I wouldn't want to rely on it, because you can't rebalance uneven loads between cores, and a single blocking task would block all requests assigned to that core.

[satvikpendem]

In practice though I haven't seen much of a difference. Actix and Axum are basically the same.

[zbaylin]

This is a backend framework, whereas the ones you mentioned are for the frontend

[candrewlee14]

Forgive me, completely missed that this is a backend framework. I mistook this for something like Leptos, a Rust frontend web framework. Makes more sense now, thanks!

[racketprogram]

Actix is web backend framework...