Should I use
Marionette?

01 / GIVE YOUR AGENT A BETTER START

Help it find the right approach.

Marionette is tuned to help agents find the right approach for the task, with consistent APIs, explicit contracts, and guidance designed for how they work.

A useful library gives an agent more than methods to call. It gives familiar problems recognizable solutions:

• Change part of a screen. A named Region identifies where the new View belongs and handles replacing the old one.
• Keep each instance independent. View-local state has an explicit home, including the objects and collections inside it.
• Check that a change is complete. Public lifecycle methods let the agent verify that a View was attached, replaced, or destroyed.

Those patterns give the agent a route from the request to the implementation—and give you something specific to review.

02 / A PLACE FOR THE WHOLE APPLICATION

Build features that fit together.

Applications manage feature lifecycles. Views compose screens through named Regions. CollectionViews manage repeated pieces. Behaviors share interaction logic. State and events connect the parts.

A feature can own its screen and the work that starts and stops with it. The next feature gets the same vocabulary, without having to recreate the first feature’s internal decisions.

03 / BRING YOUR TOOLS

Your data. Your rendering.
Your application.

Marionette separates application structure from data, state, DOM, and rendering integrations. Choose how your application gets its data and produces its interface, then connect those choices through explicit integration APIs.

For a new project, that means choosing the tools that suit the work. For an existing application, it means evaluating how Marionette can fit alongside the tools you already use.

Check the integrations your project needs, including any framework-specific components. An integration point gives you a defined way to connect a tool; a ready-made adapter is a separate question.

04 / MORE THAN A STAR COUNT

What will help your team build?

Framework familiarity is useful. So are engineers who understand the application, agents that can find the right pattern, and reviewers who know what to test.

A large archive can hold years of conflicting advice. The answer may be stuck in 2013, but your agent is delighted to report that it has the most votes.

As agents do more of the implementation, the quality of the guidance they find deserves more weight in your choice of library. So do the maintainers, integrations, and experienced people your project will rely on.

Your next contributor might be an agent.
The next reviewer still needs to follow the change.

05 / AN ENTIRELY FAIR QUESTION

Will this make more AI slop?

The agent will still have ideas. Some of them will even be good.

A consistent implementation makes those ideas easier to inspect and revise. You can try the interaction, question the behavior, and ask for a change in a specific part of the application.

You still decide whether it solves the right problem. Marionette helps make the next change manageable.

06 / FOLLOW A REAL CHANGE

See what moves.
And what stays put.

Choose an item in the homepage application. Its detail View is replaced and the previous one is destroyed. The screen and list keep their identities. That is a real Marionette Application doing the work.

Then bring your agent to the workshop. Have it build something for you, try the result, and ask what it found useful—or awkward—along the way.

07 / MAKE IT CONCRETE

Start with something you need.

Choose one useful feature: the first screen of a new product, or a part of an existing application. Include an interaction, a data or state change, and a way to check its behavior.

Use that feature to judge how Marionette fits your tools, how your agent works with it, and how easily you can understand the result.