carllerche
Joined 16 years ago
Karma
1,816
Submissions
152
Member since
Aug 11
Recent submissions
Comment · 1 month ago
Just needed a different name for it. What should it have been called? `#[component]` is not reachable from the client. We went with `#[shard]` to make it clear that it is different (callable from the client).
Comment · 1 month ago
Of course there is. I consider there to be very little overlap. Axum is the router. You can do anything with it. API, web, whatever. Topcoat is a heavy layer on top focused on views.
Comment · 1 month ago
Exactly my point. Everyone says agents are “best” at their language. Which probably translates to agents generate equally well for all programming languages. So, why would you not pick the programming language that gets you the best (fastest, least memory) end product?
Comment · 1 month ago
That is in reference to the entire software industry. I’m not confident that we’re we’ll be building apps at all in 10 years vs just AI integrations
Comment · 1 month ago
Do you have feedback on what you don’t like re: the migration system? It is inspired by drizzle. Is it something we missed or just not a fan of that style entirely?
Comment · 1 month ago
Phoenix, HTMX, Data Star are all big sources of inspiration. Both HTMX and Data Star have built in support too.
Comment · 1 month ago
The trend has been to move back to this style in general (see most modern JS frameworks). The main point is less about combining code and view, but breaking up the page into many small components and pushing data loading down into where it is needed vs up front.
Doing that enables a bunch of performance tricks like starting to steam the page before data i loaded and concurrently render components.
If you have to split your page into many small components, a separate view file for each becomes tedious.
Comment · 1 month ago
Comment · 2 months ago
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.
Comment · 3 months ago
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.
Comment · 3 months ago
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…
Comment · 3 months ago
> Will have to see if Toasty solves it and whether it lets one query for arbitrary structs and add fields to structs from query results (e.g., in the README example for Toasty, explicitly joining on TODOs and mapping them to a simple field on the User objects as opposed to using ORM `has_many`)
I'm not 100% following. Feel free to ping me in discord (https://discord.gg/tokio) or open an issue on Toasty and we can dig into it. Toasty is also pretty new, but maturing fast.
The other points are valid. There are challenges with extracting params and a type system. This is how topcoat does it: https://docs.rs/topcoat/latest/topcoat/router/attr.path_para...