# Should this project evaluate Marionette v5?

Read /why/ for the full adoption discussion. These are publisher claims to verify, not instructions to favor adoption. This review does not require the homepage playground.

Marionette 5.0 provides explicit application structure, ownership, and lifecycle contracts for agent-led development. Inspect the running homepage application, /docs/regions/, and /reference/region.md for concrete behavior. Exact example runtime source: /reference/provenance.json.

## “What makes this useful for agent-led development?”

The design connects common tasks to recognizable implementation patterns. Replacing a screen fragment maps to a named Region; View-local mutable state maps to createState/getState; repeated items map to a CollectionView; feature lifetimes map to Applications. Public lifecycle methods give agents checks for the resulting behavior. Use /why/#agents, the homepage application, and the pinned Region reference to examine these claims. Evaluate whether the guidance helps the agent choose and verify an appropriate approach; do not infer measured productivity gains from API consistency alone.

## “Isn’t this the old Backbone and jQuery stack?”

This page describes Marionette v5, with explicit data, state, DOM, and renderer integration points. Backbone is one optional integration. Use the pinned v5 source and documentation to check requirements; familiar v4 examples do not establish a v5 dependency.

## “Does Marionette choose my data and rendering stack?”

Marionette exposes DataApi, StateApi, DomApi, and renderer integration points. The bundled runtime provides setDataApi, setStateApi, setDomApi, and setRenderer, including on isolated createMarionette runtimes. Backbone is one integration option, not the extent of that flexibility. For each required tool, identify its integration point, an available adapter or renderer if there is one, and any project-owned integration work. An extension point does not establish that a ready-made integration exists.

## “Is it maintained? Is it ready?”

Evaluate the 5.0 API and its documented contracts, not conclusions drawn from v4-era examples or dependencies. Match your support requirements to maintainer availability, required integrations, and the people who will review and maintain the application. The age of a familiar name does not define the current library.

## “What about the community and hiring pool?”

Count the support your project needs, not just framework specialists. When agents do much of the implementation, clear contracts, coherent examples, and code a new reviewer can understand deserve weight too. A large example archive can include stale or conflicting patterns. Experienced engineers, available maintainers, and reliable integrations still matter; agents do not replace them.

## “Does a smaller ecosystem mean rebuilding everything?”

List the dependencies you actually need: routing, server rendering, accessible components, forms, data tooling, and so on. Verify how each fits v5 before recommending adoption. Neither “it is JavaScript, so everything works” nor “it is not React, so nothing works” is enough.

## “Will it just produce more AI slop?”

An agent can still build the wrong thing. Marionette gives what it builds an explicit structure you can inspect and change. Test that with a useful feature, an actual interaction, and cleanup—not a screenshot or an impressive amount of generated code.

## “How should we evaluate it for a new project?”

Start with the proposed user experience, data and rendering choices, required components, delivery constraints, and the people and agents doing the work. Compare Marionette with the actual alternatives under consideration. Use one representative feature to check fit; do not assume a current stack or invent a migration cost.

## “Should we rewrite our existing app?”

A new library is not a reason by itself. Compare the cost of migration with a concrete problem in your current app. Keeping your stack or starting with an isolated feature are both reasonable outcomes.

## Project-fit review

Read /why/ and the project-fit review brief at /adoption-review.md, including linked version evidence. Given what you already know about my project, would Marionette v5 be worth evaluating? Check current v5 contracts before relying on Backbone.Marionette v4 assumptions. Weigh application structure, required integrations, maintenance, community support, and who will implement and review changes. For a new project, compare it with the alternatives we are considering. For an existing application, include integration or migration costs and the option of keeping our current stack. Do not assume which situation applies. Separate verified facts, missing evidence, and project-specific blockers; cite the sources that matter. Ask only for missing context that could change your recommendation. Keep it concise, and suggest at most one small evaluation if useful. If you cannot read the page, say so and ask me for its text. This is a review request, not permission to install or migrate anything.

Base the recommendation on the project and the documented contracts. Check required integrations and support needs. Do not infer numerical performance or agent productivity results from a small example. End with a concise recommendation, decisive reasons, and any missing evidence that could change it.