rust-web-framework-comparison: a generated table of Rust web frameworks

What the repository actually is, and who it is for

The project is a comparison table, not a framework and not a benchmark suite. The README opens by saying it is "A comparison of some web frameworks written in Rust", and it states one inclusion rule: "This overview only contains frameworks that work on stable Rust." That single sentence does more work than it looks like. It excludes anything that needs nightly features, which rules out a number of experimental HTTP stacks, and it means every row is supposed to compile on a normal toolchain.

The audience is narrow and practical. Someone who has decided to write a web service in Rust, has not yet chosen a stack, and wants to see the field laid out by category before reading individual docs. The table of contents splits the field into frontend frameworks compiled to WASM, server frameworks split again into high-level and low-level, client frameworks, templating, and websocket libraries. Each of those groups also carries an "Outdated" subsection, which is the part most readers skip and probably should not, because a framework that moved out of the main table tells you something about churn in this ecosystem.

What it is not: a place to find throughput numbers. Despite the related searches that bring people here, the README does not present a benchmark harness. The columns are metadata about each project, not measurements.

How the table is generated: data.toml, Tera and README.tmpl

The repository layout explains the mechanism better than the README does. The top level holds README.md, README.tmpl, data.toml and a src directory, and Cargo.toml describes a binary crate named rust-web-framework-comparison with publish = false. The dependency list is the giveaway: tera with default-features = false for templating, toml for parsing, serde with the derive feature for deserialising into structs, plus url with its serde feature for the link columns.

So the data flow runs in one direction. Framework metadata lives in data.toml. The program parses that file into Rust structs, hands the result to a Tera template, and writes the rendered output. README.tmpl is the template, README.md is the rendered product. That is why the README is full of badge URLs rather than static numbers: the Stars, Contributors, Activity, License and Version cells are shields.io image links, and the crate version and licence badges point at crates.io endpoints. Those cells update on their own when GitHub or crates.io serves the image, without anyone editing the repository.

The remaining dependencies point at a second job. reqwest is configured with rustls-tls, blocking and json, and crates_io_api is present with rustls. Those are there to talk to crates.io, which is how the Downloads column gets its values. anyhow and log with env_logger handle error reporting and diagnostics on the command line.

One consequence worth stating plainly: the numbers in the frontend table are not comparable across rows in the way a reader assumes. egui shows a downloads figure in the tens of thousands of thousands while Silkenweb shows a small number, and those are crates.io download totals accumulated over different lifetimes, not activity or quality signals. The project itself does not claim otherwise, but the column sits in a table next to Stars and Activity, which invites exactly that misreading.

Running it and regenerating the README

There are no installation instructions in the README, and no published crate, since Cargo.toml sets publish = false. The way in is a git clone of the repository and a Cargo build against the local checkout. The package name in Cargo.toml is rust-web-framework-comparison, and Cargo.lock is committed, so a fresh checkout resolves to the pinned dependency set.

git clone https://github.com/flosse/rust-web-framework-comparison
cd rust-web-framework-comparison
cargo build

The first build compiles the dependency tree, which includes reqwest and its TLS stack, so expect it to take a while. Because the crate depends on crates_io_api and reqwest, any step that fetches crate data needs network access.

To change the table rather than just build it, edit data.toml. That file is the input the program deserialises with serde, and README.tmpl is the shape it renders into. Adding a framework means adding an entry to data.toml in the same structure as the existing ones, then regenerating README.md. The README does not document the expected keys of a data.toml entry, so the existing entries are the only specification you get. Read them before you add anything.

Where the comparison stops being useful

The stable-Rust rule is the project's only stated filter, and it is a coarse one. Two frameworks can both compile on stable and still differ enormously in how much of the ecosystem they pull in, how they handle async runtimes, and whether their middleware story is mature. None of that appears in the columns. Virtual DOM, SSR, Rendering and Architecture are listed for the frontend frameworks, which is genuinely useful for separating a React-style model from an immediate-mode GUI from an Elm-style one, but the server table is thinner on the axes that decide real deployments.

The Activity column is a shields.io commit-activity badge, and it is the weakest signal in the table. A yearly commit count tells you nothing about whether the project responds to issues, whether a major rewrite is in flight, or whether the maintainer has stepped back. If you are choosing a framework you will depend on for years, the badge is a starting point for a look at the repository, not a substitute for it.

The outdated sections are a reminder that the main table is a snapshot with a shelf life. Frameworks move between sections. If you are looking for a framework that has been stable in the main table for a long time, the table does not show you history, only the current classification, and the classification is edited by hand in data.toml.

Finally, this is the wrong tool if you need to justify a choice to someone else on performance grounds. The README does not rank frameworks by speed and links no benchmark suite. For that question you have to go to a dedicated benchmark project and read its methodology, which is a different kind of work.

Alternatives and how they differ in approach

The closest thing to a substitute is the framework documentation itself. If you already know you want axum or actix-web, the crate docs and the project's own examples answer more questions per minute than a comparison table, because they show the routing API and the extractor model rather than a row of badges. The table's value is upstream of that decision: it tells you which names exist and which layer they occupy.

A second alternative is a benchmark-oriented comparison project, which measures request throughput under a fixed workload instead of collecting metadata. That answers a different question, and it answers it with numbers you can inspect. The trade-off is that benchmark projects tend to cover the HTTP server layer only, so they say nothing about WASM frontends, templating engines or websocket libraries, which is roughly half of what this repository covers.

A third option, and the one this repository most resembles in spirit, is a hand-maintained awesome-list. The difference is mechanical. An awesome-list is edited as Markdown by humans and drifts; this project keeps the rows in data.toml and renders them through Tera, so the badge cells stay live and the structure stays consistent. Whether that is worth a Rust build step depends on how often the list changes. For a table updated a few times a year, a Markdown file is simpler. For one where you want crate versions and licences pulled automatically, the generator earns its place.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-04-20. That is roughly five months before the date of writing, so treat it as a maintained but not fast-moving project. There are no releases, which fits a tool that is run from a checkout rather than installed. The package sets publish = false, so you will not find it on crates.io as a library, and there is no versioned artefact to upgrade to. You track master.

The upgrade cost is therefore the cost of keeping a Rust binary compiling. The dependency list is small but not trivial: reqwest 0.12, crates_io_api 0.11, tera, toml 0.8, serde, url, anyhow, log and env_logger. Cargo.lock is committed, which pins the working set, so a fresh clone builds against known-good versions. When you do refresh the lockfile, the two crates most likely to need attention are reqwest and crates_io_api, since both sit on the network boundary and both are configured with reduced feature sets (default-features = false, with rustls rather than the default TLS stack) that upstream changes can disturb.

The licence is the open question. The repository metadata does not state one, and the README does not contain a licence section. The licence badges in the table describe the frameworks being compared, not this project. If you intend to reuse the generated table or the template in your own documentation, check the repository for a licence file before you do, since the absence of a declared licence is not the same as permission. That is a factual gap, not a legal opinion.

Editorial conclusion

Use it if you are starting a Rust web project and need a shortlist of stable-Rust frameworks grouped by layer, or if you want a data.toml-driven table you can edit yourself. Do not use it to pick a winner on speed: the README links no benchmark methodology, and the downloads column in the frontend table mixes crates.io totals rather than measuring runtime. Before you commit to anything from the table, open the linked repository, check the licence badge on the crate page, and confirm the framework still builds on stable Rust, since that is the only inclusion rule the README states.

Frequently asked questions

Official sources

1. flosse/rust-web-framework-comparison on GitHub
2. Issues
3. README