So the other option is to lean more heavily on native typescript — I did most of an implementation nd plan to finish it shortly. https://github.com/apache/burr/issues/610
On Mon, Mar 23, 2026 at 3:51 PM André Ahlert <[email protected]> wrote: > Hi all, > > Had a long conversation with Stefan on Discord about where the builder and > UI could and should go. And we've got had good ideas. Wanted to bring it > here for broader input before I go deeper. PR #687 ( > https://github.com/apache/burr/pull/687 ) has my current work. > What we're trying to solve: > > Right now, building a Burr app means writing Python, running it, then > switching to the tracking UI to see what happened. There's no way to go > from a visual graph back to code, or to prototype a flow visually before > writing the implementation. > > Stefan framed it as "code -> picture -> code", where the graph is the > shared representation between the two. I think that's the right north star. > build_graph() convention > > The simplest unlock is agreeing on a function signature: > > def build_graph() -> Graph: > return ( > GraphBuilder() > .with_actions(...) > .with_transitions(...) > .build() > ) > > The UI looks for this, calls it, gets the graph object. No regex, no > guessing. Should this live in core as a recommended pattern, or stay as a > UI convention? > Pyodide/WASM: > > Stefan pointed out that tryhamilton.dev already runs Pyodide. If we do the > same for Burr, the UI can execute build_graph() directly in the browser, > stub out non-burr imports, and use inspect to get action metadata. This > replaces the regex parser I built and makes the code-picture-code loop > actually reliable. > > Main question: should the WASM runtime be loaded on demand or always > bundled? Any concerns about scope here? > What I'm committing to: > > I can own the builder and UI side. Concretely: > > - *This month:* Get PR #687 reviewed and merged. Builder with node > types, Monaco editor, save/load. > - *Next month:* Pyodide integration spike. Starter templates (chatbot, > RAG, tool-calling agent). Serve/test functionality in the UI. > - *Ongoing:* VS Code extension exploration, template hub. > > Stefan also brought up Hamilton-Burr integration and the broader > Hamilton/Burr/Airflow stack vision. Happy to discuss that separately, > keeping this thread focused on the builder. > > Would appreciate thoughts on direction, priorities, or concerns about > scope. > > Andre Ahlert. >
