Yew's release profile optimizes for size, not for speed

opt-level z and panic abort define what a Yew build actually is

The `[profile.release]` block in Cargo.toml sets `lto = true`, `codegen-units = 1`, `panic = "abort"` and `opt-level = "z"`. That last one is a size-first choice, so a release build is assembled for a small wasm artifact rather than for throughput, and `panic = "abort"` means a panic stops the program instead of unwinding, which removes the recovery paths you would otherwise have across the wasm boundary.

The benchmark profile is configured differently on purpose: `lto = true` and `codegen-units = 1` carry over, but `opt-level` moves to 3. So a number you read off a benchmark in this repository was produced under a different optimizer setting than the binary a user downloads. Treat benchmark figures here as a comparison between Yew revisions, not as a description of release performance.

rust-version 1.85 is the ceiling that dictates actix-web

`[workspace.package]` sets `rust-version = "1.85"`, and that single line has a visible consequence further down the same file. The workspace dependency on actix-web is written as `actix-web = "<4.13"`, with the comment `# 4.13 requires rustc > 1.85` directly above it.

That is the shape of a Yew upgrade in practice. The framework holds a Rust floor to keep its own build reproducible, and anything in the tree that would need a newer compiler gets an upper bound rather than a feature request. If your server code sits on actix-web, adopting a Yew workspace means accepting that ceiling, and if your application needs actix-web 4.13 or newer you are choosing between the newer server stack and a Yew tree that is one workspace member of many.

The workspace is not a single crate. Members are `packages/*`, `tools/*` and `examples/*`, with `packages/*` as the default members and `examples/.cargo` excluded, under resolver 3.

Two getrandom versions are compiled into the same tree

The workspace dependencies list `getrandom` at version 0.4 with `features = ["wasm_js"]`, and separately `getrandom_03 = { package = "getrandom", version = "0.3", features = ["wasm_js"] }`. The alias exists so a crate still pinned to the 0.3 line and a crate already on 0.4 can coexist, and both request the `wasm_js` feature that supplies entropy in a browser rather than through WASI.

Two copies of the same crate in one dependency graph is a maintenance cost, not a style choice. Each bump lands on one alias while the other stays behind, and any breakage shows up as a compilation error in a dependency rather than in your code, which is an unpleasant place to debug a front-end application. `futures` is trimmed the same defensive way, declared with `default-features = false` rather than the default feature set.

Two more entries carry a warning sign of their own: `bincode` is pinned to `2.0.0-rc.3`, a release candidate, and `wasm-bindgen` sits at 0.2 while `web-sys` is at 0.3.70.

Server-side rendering means picking actix or axum, and the examples split

Two directories in `examples/` are server-side rendering demos, `actix_ssr_router` and `axum_ssr_router`, and the workspace carries `axum = "0.8"` alongside the capped `actix-web`. The SSR story is therefore not one integration but two, and picking a server framework is a decision you make before you write a Yew router.

Both examples end in the same shape, a router, so the difference between them is your server rather than Yew's rendering model. Neither example is accompanied by guidance on which server to choose, or by any note about what hosting each of them implies.

The wider claim about speed rests on two mechanisms stated plainly in the project description: minimizing DOM API calls for each page render, and making it easy to offload processing to background web workers. Neither is benchmarked in the repository, and the multi-threaded part depends on browser worker support rather than on anything in Cargo.toml.

counter and counter_functional are two APIs in one examples tree

The examples directory carries a `counter` and a `counter_functional` side by side, and then a family with a `function_` prefix: `function_router`, `function_todomvc`, `function_memory_game` and `function_delayed_input`. Two ways of declaring a component live in the same tree, which is convenient for comparison and confusing for a newcomer, because whichever example a tutorial happens to link teaches only one of them.

The choice is not cosmetic. The macro form is the one the project description leads with, describing a macro for declaring interactive HTML with Rust expressions and noting that developers experienced with JSX in React should feel at home. Anything the function API supports and the macro does not, or the reverse, is a porting cost you absorb on your own.

Two other directories mark the edges of the framework. `inner_html` covers rendering raw markup, and `dyn_create_destroy_apps` covers starting and tearing down Yew applications at runtime rather than once at page load.

The crate is 0.23, the router 0.20, the agent 0.5

Three releases landed on the same day, 2026-03-10: `yew v0.23.0`, `yew-router v0.20.0` and `yew-agent v0.5.0`. A framework and its router on different minor numbers, with an agent library a third of the way along, is a description of a project still finding its shape across three crates rather than one.

None of them is 1.0, so nothing in the version numbers promises that a minor release will hold your code still, and CHANGELOG.md at the repository root is the file to read before pinning. The last push was on 2026-09-18, six months after those tags, which means the default branch has moved on from what the release names describe.

Licensing is the Apache 2.0 licence, with both LICENSE-APACHE and LICENSE-MIT sitting in the root, so a project choosing the MIT file has that option. A SECURITY.md is present for disclosure, and the repository is hosted on Firebase through `.firebaserc` and `firebase.json`, with `Makefile.toml` holding the task definitions.

The README is a contribution guide, so the setup steps are elsewhere

There is no build command in the README, and no getting-started section either. What the file does is describe how the project takes contributions: a Code of Conduct, a Discord chatroom, a Question issue template, a Good First Issues label, and an invitation to improve the documentation under `website/docs` or to raise test coverage.

For getting the library, the file points at crates.io, docs.rs and the site at yew.rs, which carries both stable documentation and a separate `next` build, a roadmap, and translations in Simplified Chinese, Traditional Chinese and Japanese. The examples tree under `examples/` is where a working project is meant to be read, with its own README. Who funds it is also stated: OpenCollective, taking both individual and organization contributions.

So an evaluation has to start outside the README. Read the examples for the API shape, the CHANGELOG for what changed, and the Cargo.toml for the constraints, because the project does not summarize any of them there.

Editorial conclusion

Yew fits a team that already writes Rust and wants its front-end types checked by the compiler. It does not fit a team hunting a drop-in replacement for React components, or one that wants a build walkthrough from the README, because the repository points at the docs site and the examples tree instead. Verify three things before committing: the `rust-version = "1.85"` ceiling in Cargo.toml, which has already forced actix-web below 4.13 and will constrain your own dependency choices; whether the function-component API or the macro API is what the surrounding examples use, since the tree carries both; and the CHANGELOG.md entry for whichever release you pin, because the crate is at 0.23 with no 1.0 promise attached to it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes