Feature Request: First-class Bonito.jl support (for WGLMakie and interactive UI) #7

Closed
opened 2026-07-20 07:53:24 -07:00 by bdklahn · 5 comments
bdklahn commented 2026-07-20 07:53:24 -07:00 (Migrated from github.com)

I know this is early days for this KaimonSlate. I just wanted to set a "bookmark", while I'm thinking about it. I won't be hurt if this is closed as "won't do" or considered very low priority. Maybe this is totally off-base in terms of scope or plans/thoughts/progress you already have for this.

I was considering Bonito(Book) and any advantages there. It seems WGLMakie support is one. Maybe some nice widgets might be another. I asked Gemini to help me get my head around how to consider and reconcile. Below is revised by me, based on the PR text it generated.

"
Hi! First, KaimonSlate's fusion of Pluto-style DAG reactivity and AI orchestration looks very powerful. I am really enjoying the approach.

I’m opening this issue to request first-class integration for Bonito.jl.

While CairoMakie and ECharts are great, I consider a potential need to explore complex entity-relation graphs and interactive 3D visualizations with WGLMakie. Since WGLMakie relies on Bonito for its web and JavaScript bridging, getting Bonito to play nicely with KaimonSlate's reactive model would unlock not just WGLMakie, but the entire Bonito widget ecosystem.

From looking at how Bonito integrates with Pluto and VS Code, it seems there are a few specific architectural bridges that would need to be crossed:

  • The Communication Bridge: Bonito usually spins up its own WebSocket connection for data streaming. It would be amazing if there were a custom Bonito.Connection implementation that routed these binary messages through KaimonSlate's existing ZeroMQ (ZMQ) and Server-Sent Events (SSE) pipeline to avoid conflicting ports.
  • Cell Lifecycle & Memory: When the reactive DAG tears down and re-evaluates a cell (e.g., changing a variable), Bonito needs a cleanup hook to know the cell was destroyed, preventing the Julia process from holding old WebGL data in memory indefinitely.
  • JavaScript Injection: Ensuring the VitePress frontend is configured to trust and execute the text/html JavaScript payloads (like Three.js) that Bonito injects for rendering.

I know this is a non-trivial ask, but bringing Bonito's interactive visual layer into KaimonSlate's agentic environment would be incredibly powerful.

Thank you for your work on this project!
"

I know this is early days for this KaimonSlate. I just wanted to set a "bookmark", while I'm thinking about it. I won't be hurt if this is closed as "won't do" or considered very low priority. Maybe this is totally off-base in terms of scope or plans/thoughts/progress you already have for this. I was considering Bonito([Book](https://bonitobook.org/website/)) and any advantages there. It seems WGLMakie support is one. Maybe some nice widgets might be another. I asked Gemini to help me get my head around how to consider and reconcile. Below is revised by me, based on the PR text it generated. " Hi! First, KaimonSlate's fusion of Pluto-style DAG reactivity and AI orchestration looks very powerful. I am really enjoying the approach. I’m opening this issue to request first-class integration for [**Bonito.jl**](https://github.com/SimonDanisch/Bonito.jl). While `CairoMakie` and `ECharts` are great, I consider a potential need to explore complex entity-relation graphs and interactive 3D visualizations with `WGLMakie`. Since WGLMakie relies on Bonito for its web and JavaScript bridging, getting Bonito to play nicely with KaimonSlate's reactive model would unlock not just WGLMakie, but the entire Bonito widget ecosystem. From looking at how Bonito integrates with Pluto and VS Code, it seems there are a few specific architectural bridges that would need to be crossed: * **The Communication Bridge:** Bonito usually spins up its own WebSocket connection for data streaming. It would be amazing if there were a custom `Bonito.Connection` implementation that routed these binary messages through KaimonSlate's existing ZeroMQ (ZMQ) and Server-Sent Events (SSE) pipeline to avoid conflicting ports. * **Cell Lifecycle & Memory:** When the reactive DAG tears down and re-evaluates a cell (e.g., changing a variable), Bonito needs a cleanup hook to know the cell was destroyed, preventing the Julia process from holding old WebGL data in memory indefinitely. * **JavaScript Injection:** Ensuring the VitePress frontend is configured to trust and execute the `text/html` JavaScript payloads (like Three.js) that Bonito injects for rendering. I know this is a non-trivial ask, but bringing Bonito's interactive visual layer into KaimonSlate's agentic environment would be incredibly powerful. Thank you for your work on this project! "
kahliburke commented 2026-07-20 18:36:50 -07:00 (Migrated from github.com)

@bdklahn One of the goals for Slate is first class support for extensions to the system. There are some pieces in place already and I'm working on formalizing them and cleaning them up right now. On first glance I'd think that the integration could happen through these mechanisms. I'll do a pass on what Bonito would require to work as my familiarity with it is limited. Can't guarantee this would make it in before the official release but we'll see (as I keep saying "in a couple more days" for the past 2 weeks ;) )

@bdklahn One of the goals for Slate is first class support for extensions to the system. There are some pieces in place already and I'm working on formalizing them and cleaning them up right now. On first glance I'd think that the integration could happen through these mechanisms. I'll do a pass on what Bonito would require to work as my familiarity with it is limited. Can't guarantee this would make it in before the official release but we'll see (as I keep saying "in a couple more days" for the past 2 weeks ;) )
kahliburke commented 2026-07-20 18:39:03 -07:00 (Migrated from github.com)

@bdklahn If you're on the Julia discourse and have interest in tracking or collaborating on some of this in the near future, please DM me there under the same name.

@bdklahn If you're on the Julia discourse and have interest in tracking or collaborating on some of this in the near future, please DM me there under the same name.
kahliburke commented 2026-07-23 08:02:26 -07:00 (Migrated from github.com)
@bdklahn Should be appearing soon! https://github.com/user-attachments/assets/810eb805-7b84-4767-8449-ad38ff58fd5d
bdklahn commented 2026-07-23 15:34:06 -07:00 (Migrated from github.com)

@bdklahn Should be appearing soon!

slate-rec-20260723-075112.mp4

Very cool!

> [@bdklahn](https://github.com/bdklahn) Should be appearing soon! > > slate-rec-20260723-075112.mp4 Very cool!
kahliburke commented 2026-07-24 01:41:43 -07:00 (Migrated from github.com)

@bdklahn But wait, there's more! ;)

We're investing a lot in Slate's extension framework, providing powerful native widgets and editor extension features as well as compatibility with many systems, for example the widget spec at https://anywidget.dev, so ideally any tools you want to bring into Slate will be not just possible, but simple. For example:

https://github.com/user-attachments/assets/63b5c013-04bc-4666-855d-5984efd04b67

@bdklahn But wait, there's *more*! ;) We're investing a lot in Slate's extension framework, providing powerful native widgets and editor extension features as well as compatibility with many systems, for example the widget spec at https://anywidget.dev, so ideally any tools you want to bring into Slate will be not just possible, but simple. For example: https://github.com/user-attachments/assets/63b5c013-04bc-4666-855d-5984efd04b67
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kahliburke/KaimonSlate.jl#7
No description provided.