[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2444jvzwz6wrg":3},{"code":4,"message":5,"data":6,"timestamp":34},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":22,"summary_md":23,"topic":24,"github_topics":27,"license":28,"homepage":29,"updated_at":30,"history":31},"tokio-rs\u002Ftopcoat",6,"A batteries-included framework for building web apps","Rust",6214,220,19,205,[16],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},48952067,"Topcoat: The full full-stack framework for Rust",134,48,"2026-07-17","A batteries-included Rust web framework that keeps templates, reactivity and assets in one typed codebase, aimed at teams already using Rust.","Topcoat is worth a look if your team already writes Rust and wants a single-language web app instead of gluing a Rust API to a separate JavaScript frontend. It is early, and its roadmap makes the gaps explicit.\n\n## The problem\n\nToday a Rust team building a typical web app often splits the work: an axum or similar service for the API, then a separate frontend project with its own build, routing and client state. Every form needs a serialized contract between the two halves, and simple UI interactions drag the client bundle and build pipeline along. Topcoat renders markup on the server while letting components be async and query the database directly, so the separate API layer disappears. The result is one Rust project that produces the page, the interactions and the served assets.\n\n## What's different\n\nThe distinguishing mechanism is how interactivity is produced. A `$(...)` expression is ordinary type-checked Rust: Topcoat evaluates it on the server for the initial render and translates it to JavaScript so it can re-run in the browser without a round-trip. That avoids a wasm bundle and a client build step, which is the main reason a Rust full-stack project would otherwise feel heavy. The `view!` macro sticks close to HTML and Rust control flow, and `topcoat fmt` formats macro bodies so templates do not escape normal tooling.\n\nTwo more choices shape daily use. Routes can be inferred from module structure without a build step, which makes the file tree the routing config. UI components are copied into the project via `topcoat ui`, shadcn\u002Fui-style, so you own and edit them rather than importing a versioned library. Asset handling scans the compiled binary for `asset!` calls and serves files with browser caching. The trade-off is coupling: you are adopting Topcoat's conventions for templates, routing and components together, and the reactivity story is still on the roadmap, so sufficiently rich client-side behavior is not the finished part of the design.\n\n## Who should try it\n\nGood fit: a team with Rust services that wants an internal dashboard, marketing-plus-app site, or small CRUD product in one language, and values type-checked templates over a mature JavaScript ecosystem. A contributor who already knows Rust and wants to skip the API boilerplate will recognize the appeal. Poor fit: teams needing a polished, feature-complete Rails\u002FDjango-style stack today, or projects whose UI depends on heavy client-side state. The documented roadmap still lists static export, pre-rendering, validations, OpenAPI endpoints, deployment docs and more reactivity, so anyone whose requirements land in those areas should treat them as unfinished. For agents and tooling, the project points to an `llms.txt` file describing APIs and conventions rather than requiring a special assistant.\n\n## Requirements and limitations\n\nYou need a working Rust toolchain and should follow either the [getting-started guide](https:\u002F\u002Fgithub.com\u002Ftokio-rs\u002Ftopcoat\u002Fblob\u002Fmain\u002Fdocs\u002Fgetting_started.md) or the [manual setup](https:\u002F\u002Fgithub.com\u002Ftokio-rs\u002Ftopcoat\u002Fblob\u002Fmain\u002Fdocs\u002Fmanual_setup.md); Tailwind integration is behind a feature flag, and the UI library expects a Tailwind-based workflow. The roadmap matters more than a typical \"limitations\" section: no static export or pre-rendering yet, no built-in validation, no deployment documentation, and image optimization and Markdown support are still planned. Those absences change what kind of site is practical, not just how convenient it is. Ongoing upkeep includes keeping formatting and UI components in sync with the framework as it evolves, and the project is young enough that conventions may move.\n\n## HotRepo's take\n\nHotRepo's only recorded trend sample is a single daily-board observation on 2026-10-25, at 6,207 stars with +19 that day, so persistence cannot be judged from it; the repository is about 204 days old at that point. The HN thread (2026-07-17, 134 points, 48 comments) is discussion volume, not endorsement. One substantive report: a commenter on [2026-07-17](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=48953279:) said they are a happy axum user but unsure that Topcoat and its ORM are a good direction for tokio-rs, worrying about adoption based on name recognition; a reply from carllerche on the same day said a split is likely but takes work. Check how the roadmap items you depend on have progressed before committing a production app.",{"slug":25,"name":26},"developer-tools","Developer Tools",[],"MIT",null,"2026-10-25T11:04:35Z",[32],{"date":33,"stars":11,"stars_gained":13},"2026-10-25",1792968702]