To further explain. Rust doesn't provide a runtime/framework for async/await, you have to bring your own. Tokio is (I believe) the most popular async/await framework for rust.
Topcoat (Rust) is aiming taking this approach as well: https://github.com/tokio-rs/topcoat. The project is still in the early days. It won't require WebSockets, but WebSockets will be an option.
I know the repo was posted here a few days ago (https://news.ycombinator.com/item?id=48952067). The intent was to open the repo at the same time as the blog post, but we ran out of private repo CI credits, so opened it up early and it got posted.
We still wrote the blog post. It provides a bit more context. Feel free to ask questions here.
All on the roadmap :) topcoat-ui is already usable with Shadcn components (recent Pr: https://github.com/tokio-rs/topcoat/pull/118) we are still working on pulling in more components.
Re: OpenAPi you want to consume or provide an OpenAPI endpoint? I’m assuming you want to provide one. This is probably on the medium term roadmap after other stuff like UI, tighter ORM integration, email, etc…
This would be consuming an openapi endpoint from my rust service generated using utoipa. Currently I generate an openapi.yaml file and use openapi-typescript to generate the api bindings.
Topcoat is entirely server rendered. Reactivity is added using attributes and other signals to a JS “runtime” shipped with topcoat. It is a similar idea to htmx/datastar/hotwire where as Leptos uses wasm to run rust in the browser as well as the server, more like nextjs or solidjs
Depends on what you mean by that. Tokio the runtime is lean, and stable. Tokio the org is a collective of devs working on creating and maintaining a full ecosystem for building client and server apps with rust.
yeah i mean more so, is the goal for topcoat and toasty and friends to become like Spring Boot from Java but for Rust.
(also it was nice meeting you at the zscaler talk you gave a couple of weeks ago)
I don't take offense from differences in design opinion. The goal of topcoat is to be opinionated and not make everyone happy. And JS libs are a heavy inspiration. They do a lot right and have years of experience in the browser-app space. If you don't like it, Axum aims to be the lower-level HTTP router that anyone can build their own abstractions on top of.
That said, if you are up to it, I would ask that you try using it and provide your thoughts after using it as an issue. Feedback is appreciated.
Thank you. I hope I didn't offend you. First, I think the len() part is problematic. Could you check that for me? I think it's calling Rust's str::len() and using JS's String.length, which I think should be aligned with UTF-8.
I'll try it out next time and give feedback later. And you're right, it's just a difference of opinion.
Also, for the API side, Unicode strings are usually 4 kinds right? I think using Rust-style snake_case, we might need separate functions like len(), utf16_len(), and so on. But I'm not sure how to handle the abstraction between libraries and browsers.
Sorry for being critical. I'm not that good of a programmer, so it might be a mistaken observation. Please check it.
reply