Introducing Marionette 5

Paul

Well, I noticed agents were doing more and more of my coding, and I started wondering whether I should abandon Marionette and move to one of the major frameworks. We'd already gotten v5 to alpha, but the project had lost steam during COVID. With agents, switching didn't mean I had to learn a whole new framework and do the migration myself. So was it still worth investing in Marionette? I asked the agents to help me think that through.

Paul

Early on, the recommendations were mostly about Backbone being old, bigger communities and hiring pools, and more learning resources and training data.

Paul

Those arguments still have some value. But they seemed to assume a human would be doing most of the implementation. I wanted to know how their value might change when agents were doing more of that work.

Paul

I wanted to look at the architecture separately. If JavaScript existed but no frameworks had been invented yet, what ecosystem would agents want to work in? I asked them to think about safe changes, code I could review, clear ownership and lifecycles, and maintainability. Then I asked where a Backbone-free Marionette would fit.

Paul

I deliberately didn't ask ChatGPT, which was my daily driver. I didn't want its familiarity with my preferences to influence the answer. The responses from Claude Opus 4.7 and Gemini 3.5 were positive about Regions, predictable lifecycles, knowing who owns and cleans up each piece, and keeping application state separate from presentation. Claude’s was more qualified; Gemini’s favored that architectural fit over React or Vue. They disagreed on things like message buses and reactivity, but both saw real value in the architecture and wanted it modernized.

That encouragement is why I picked v5 back up. It was an idea worth trying in real applications. That, and OpenAI gave me six months free on their $200-a-month plan.

dot

That gives an agent a place to make a change, and you a way to review its consequences.

Paul

The human ergonomics of the code were about code review and not saving keystrokes. So I would bring questions about what to keep or change to multiple agents until there was some sort of consensus.

Paul

Views, Regions, CollectionViews, and Applications still give an application a recognizable structure, with clear places for startup and cleanup. Core no longer requires Backbone, jQuery, or Underscore. We still value Backbone, and applications can keep using it through an adapter. It just no longer determines how Marionette’s core works. Optional rendering and data adapters let applications choose their integrations, including Lit templates and observable data.

Paul

The package includes version-matched docs and a Marionette skill that points an agent to the installed API. Its local helper can look up a symbol, a documentation section, or a diagnostic code. There are TypeScript declarations and an ESLint rule for catching use of private framework members, too. Work with an agent → · Application tooling →

Paul

The results have been surprising. Agent-led development seems to work, and the applications have performed well against their peers.

In RealWorld, an agent built Conduit, a blogging frontend, then refined it through review and follow-up requests. In the simulated-mobile benchmark, median article navigation was 175 ms for the measured v5 build versus 425 ms for Vue, across ten samples per app. Read the RealWorld measurements →

The Vikunja Vue migration measurements show another encouraging result: median rich-task opening was 1.04 seconds for the measured v5 build versus 3.72 seconds for Vue. That’s 72% shorter across 20 samples per app in desktop Chromium, using production builds and a 500-task fixture with 50 comments on the opened task. Read the Vikunja measurements →

Paul

The migration guide allows an app to retain its Backbone Models, Collections, and persistence through an adapter while updating to v5’s contracts. Removing a core dependency doesn’t require replacing every working part of an application.