Trame v4: Your React Investment, Now Driven by Python

If your organization has spent years building a React-based front-end team — a component library, a design system, in-house widgets your users already know and trust — the idea of “rewrite it in something else” is usually where a good project idea goes to die. Trame v4 removes that trade-off.

Starting with this release, trame can drive React components natively, with the same single-language promise it has always made for its Vue.js core: describe your application — and the binding between server-side logic and client-side UI — entirely in Python.

The problem trame has always solved

trame exists to simplify the way distributed, interactive applications are built. Instead of splitting a team across a Python backend and a separate JavaScript front-end codebase — with all the coordination overhead, context-switching, and duplicated state management that implies — trame lets you describe the UI, the reactivity, and the server logic in one language: Python. The web layer is real, modern, and reactive; you just never have to leave Python to drive it.

That model has worked well for teams building on trame’s Vue.js core. But it created friction for a specific and increasingly common situation: teams that already have a mature React codebase — a component library, a branded widget set, years of accumulated UI investment — and don’t want to re-implement any of it just to get trame’s Python-driven workflow.

What’s new in v4

trame v4 adds a second, first-class client type: client_type="react". Where you previously wrote client_type="vue3", you can now target React instead — and everything else about how you build a trame app stays the same. Same TrameApp base class, same reactive state, same event/trigger model, same Python-only workflow.

Here’s a small example using MUI, one of the most widely adopted React component libraries, driven entirely from Python:

from trame.app import TrameApp
from trame.ui.html import DivLayout
from trame.widgets import mui, react


class MuiDemo(TrameApp):
    def __init__(self, server=None):
        super().__init__(server, client_type="react")
        
        with DivLayout(self.server) as self.ui:
            with mui.Card(elevation=4), mui.CardContent():
                mui.Typography([
                    "count = ", 
                    react.Bind("count", count=3)
                ], variant="h5")
                mui.Slider(
                    value=react.Bind("count"),
                    on_change=react.Callback(
                      "count = Number($event.target.value)"
                    ),
                    min=0, max=10, step=1,
                )
                mui.Button(
                    "Reset",
                    variant="contained",
                    on_click=react.Callback(self.reset),
                )

    def reset(self):
        self.state.count = 0
       

No JavaScript build step, no separate front-end repo, no hand-rolled REST or WebSocket plumbing to keep server state and UI in sync. react.Bind and react.Callback do for React what trame’s v-model-style bindings already do for Vue — they’re the two-way bridge between your Python state and the component library your team already knows.

Why this matters if you’re the one signing off on the roadmap

This isn’t about trame becoming a React framework. It’s about protecting an investment you’ve already made.

• Your React team’s work doesn’t get shelved. Component libraries, design systems, and branded widgets built over years of product work carry over into trame applications rather than being rewritten from scratch.
• Faster delivery, not a parallel front-end project. Application logic — the part that actually encodes your product’s behavior — is written once, in Python, by the people who best understand it. There’s no second codebase to keep in sync, no hand-off between a Python service and a separate React app.
• Consistent branding across tools. Internal tools, dashboards, and scientific/engineering applications can share the same look and feel as your customer-facing React product, because they’re built from the same components.
• Lower integration risk. State synchronization between client and server — usually a significant source of bugs and ongoing maintenance in hand-built full-stack apps — is handled by trame’s reactive state model instead of custom glue code.

In short: the React investment your organization already made is now a trame asset, not a trame alternative.

What’s supported today

Trame v4’s React support is deliberately scoped around bringing your own widgets, not building a new framework from the ground up. Today, the React path includes:

• Plain HTML elements — built into trame’s core, no extra dependency.
• MUI — one of the most popular React component libraries, for polished, ready-made UI out of the box.
• trame-rca — remote rendering, including VTK, streamed into your application.
• trame-vtklocal — local, in-browser VTK rendering using VTK.wasm.

A note to the trame community: Vue isn’t going anywhere

We want to be direct about this, because it matters: trame’s core development is not shifting away from Vue.js. Vue remains — and will remain — the default, most complete path through trame, and the one we continue to invest in first.

React support is an extension of trame’s core, built to answer a real, recurring need from the community: teams with existing React codebases who want trame’s Python-driven workflow without discarding that work. It sits alongside the Vue core; it doesn’t replace it.

That also means we’re not chasing feature parity between the two client types as a blanket goal. The Vue ecosystem around trame — trame-vuetify, trame-vtk, trame-plotly, trame-matplotlib, and the rest — represents years of investment and remains the deepest, most complete way to build with trame. Widening the React side beyond the widgets listed above is realistic where there’s clear community need or dedicated funding behind it, not as a default roadmap item.

If you don’t already have a React codebase you want to bring forward, our recommendation is straightforward: build with trame’s Vue-based core. It’s the more complete, more actively developed path, and it’s the one we’d point any new project toward. React support in trame is for teams who have existing React investment to leverage — not a second way to start from scratch.

Getting started

Trame v4 is a major release precisely because of what it opens up: a credible path for React-invested teams to adopt trame’s simplified, Python-first application model without a rewrite. If that’s your situation, this is the moment to take a look.

Learn more, browse examples, and get started at kitware.github.io/trame.

Bringing your team onto trame? Talk to the Experts

React support in trame v4 is new, and every existing codebase brings its own mix of components, patterns, and edge cases. Rather than letting your team discover the rough edges on their own, reach out to Kitware before you start. We can help you scope the integration, work through how your specific widget library maps onto trame’s React bindings, and fix issues you run into along the way — directly, from the team that builds trame.