> But I think we will swing back to using GUIs

I've been pushing on BubbleTea Kitty and Ghostty quite a bit to hybridize this. The TUI / GUI distinction to me is about task centrism and delivery. There's an appropriate surface and workflow for every task; beyond TUI/GUI sometime it needs to be a VR headset or an immersive room or a literal sandbox.

A demo of this is web-delivery of our BubbleTea TUI examples ('t' toggles between glyph/kitty):

https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p...

The delivery uses our WIP Booba tool, which is Ghostty-based. The CLI tool can be used to remote or embed any TTY program, but was generally built for BubbleTea. https://github.com/NimbleMarkets/go-booba

I've recently made SVG, PDF, SVG, and OpenStreetMap widgets.... https://github.com/NimbleMarkets/ntcharts-svg https://github.com/NimbleMarkets/ntcharts-pdf https://github.com/NimbleMarkets/ntcharts-osm

Right now I'm working on multiple ds4 TUIs using this stack, for example generating SVGs from a prompt and then rendering it in TUI. Another generates CSG object graphs and renders/composites them in terminal. Here's a gist with screenshots:

https://gist.github.com/neomantra/ae47422c8daf7a458212c93992...

The upstream ds4 project is using C for their TUIs. I have done TUIs in C and C++ (and many other languages) and will not go back to that. Really fun engine though and a great place to stick a TUI. I am a Camel furry (https://cameltopia.org) but wouldn't use OCaml to make a TUI either (makes sense for Jane Street of course).

Toweled off and got to work:

https://github.com/NimbleMarkets/ds4-go

The concept is marrying the flexibility of Golang with a specific local high-performance inferencing engine. The clean C interface made it easy. Initial release wraps the API using purego and requires pointing to a DS4 installation.

I'm now adding some pre-built installer ergonomics and directory opinions and demos.

https://github.com/hybridgroup/yzma

And thank you antirez for using your rep and quality output to push this line of evangelism; it is even more important than the software itself.

As noted elsewhere, ASLR protects you. While you are waiting for your affected platform to get the fix, they note the mitigation:

"use named captures instead of unnamed captures in rewrite definition"

"To mitigate this vulnerability for this example, replace $1 and $2 with the appropriate named captures, $user_id and $section"

F5 patched 1.31.0 and 1.30.1.

OpenResty has a patch for 1.27 and 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...

You can track OpenResty's (a Lua application server based on Nginx) progress here: https://github.com/openresty/openresty/issues/1119

And I appreciate that the Hannes still appreciates the magic of the WASM. [And I keep hearing quark which makes me hungry for tangy creamy German yogurt]

I found that many dependencies in the ecosystem (especially older ones) do not support GOARCH=wasm nor GOOS=js / GOOS=wasip1. I've had to fork and add support and then do go.mod replace directives. It can get messy.

Golang build tags make it awesome to have different implementations for different systems.

In the browser, it's all single threaded, so goroutines starve each other. I had to put in "breaths" for interactivity.

There's no local filesystem, so you have to figure out other solutions. Some dependencies use the filesystem as an implementation detail or try to shell out. The program will build, but will error at runtime.

That said, it is pretty sweet when it works. You can make WASM games with ebitengine [1] and it emits instructions for a WebGPU renderer; very efficient and many interactivity concerns are handled for you. The NTCharts demo page [2] combines Zig (Ghostty), WASM+Typescript+GLSL (Ghostty Web), and Golang (booba/ntcharts). The WASM size for the demos there is ~5MB each.

My goal is to make tools for terminal remoting and simplify bringing TUIs to the browser. [1] https://ebitengine.org

[2] https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p... press 't' for kitty graphics

Then I added WebGL and WebGPU renderers [1], including support for Kitty.

Then I see this this project on a Monday morning... so now I have to implement Ratty Graphics Protocol?!?! [2].

ETA: I looked into this; Ghostty would need patched to support Ratty since Ghostty-Web now defers APC handling there. It would also require pulling in a 3D engine like three.js or otherwise implementing file parsing, lighting, etc. Finally, since local filenames are part of the protocol, a browser would need some file resolver helper, either to get the data over the APC channel or via a URL.

[1] https://github.com/NimbleMarkets/ghostty-web/tree/nm-webgpu

[2] https://github.com/orhun/ratty/blob/main/protocols/graphics....

But I will say... you have to know Golang. You have to have at least tried to make a BubbleTea app yourself and try to understand ELM architecture. You have to look at the code and increment with it.

It makes total sense for OP to switch to Rust and Ratatui if they don't know Golang well. But I don't think it's a better language for it. [Ratatui has brought me great inspiration though!]

Independent of framework, the LLMs get the spacial relationships. I say things like "the upper right panel's content is not wrapping inside and the panel's right edge should extend to the terminal edge" and the LLM will fix it. They can see the resultant text, I'm copy-pasting all the time.

TUI code is finicky; one mis-rendered component mucks everything up. The LLMs will decide themselves make little, temporary BubbleTea fixtures to help understand for itself when things aren't right.

The only real problem with LLMs and BubbleTea is that upon first prompt, they insist on using BubbleaTea v1 versus BubbleTea v2, released in December 2025. But then you just point it to the V2_UPGRADE.md and it gets back on track. That will improve as training cutoffs expand.

I vibe-coded this TUI for Mom's last night. I actually started with Grok (who started with v1) and then moved into Claude Code after some iteration:

https://gist.github.com/neomantra/1008e7f2ad5119d3dd5716d52e...

* “Not building a wall but making a brick”

I talk to laypeople about their AI work -- I am constantly doing this, inserting myself into AI conversations on the street like an anthropologist when I encounter them...

HTML artifacts are the new browser URL bar, wherein some users have a mental model that that bar is actually Google.

Many people now talk about their "spreadsheet" or their "presentation" or "marketing tear sheet", or "slide show", "competitive analysis", "hvac system diagram" or whatever the thing they were working on and how lame it was working with ChatGPT or Claude Web.... and how miraculous Claude Code or OpenClaw is with creating these new documents...

I will ask them what the documents actually are and what the difference in experience was. It takes a lot of teasing (because they don't have the computing vocabulary yet) or having them show me, and it will always come down to that the artifact is HTML.

Their pleasant experience is that it is iterating on an HTML file (+CSS +images) living on a filesystem with high quality instant rendering; plus it can sprinkle JavaScript when it needs to. It might even revision control it without them knowing if there's a git system. [I suggest they checkpoint their work if they don't; revision control is the next stage of learning for the laypeople?]

Whereas the Web-embedded experiences are stabbing multiple times on a DOCX/PPTX/XLSX lingering in a context window and a vague notion of local storage (rendered as HTML anyway in a sidebar), etc. The HTML workflow also allows other media to be integrated much more easily.

So really all this presentation work is Vibe-Coding by the masses; they don't need to know about all the turtles underneath them. But if they are willing, they could crack it open and see and edit it; or easily hand it off to another agent.

Go figure that the system created for collaborative multimedia communication ends up being useful for the machine intelligence to help us communicate.

[1] https://kristoff.it/blog/contributor-poker-and-ai/

For the past few weeks I've been wrapping up Booba [1], which is developer tooling to combine BubbleTea and Ghostty in WASM deployments (using ghostty-web).

It provides for some interesting deployment patterns both locally, over network, and embedded in a web page. It's intended to be very easy to adopt; at the simplest, one just changes `tea.NewProgram` to `booba.NewProgram`.

I used Booba to make a demo page [2] for our NTCharts TUI library published to GitHub Pages. The repo READMEs have GIFs... this page is all embedded WASM.

There's also new Kitty-Graphics-supported widgets in there (picture, chartpicture); I updated Booba and Ghostty-Web to support it. Still getting the kinks out.

[1] https://github.com/NimbleMarkets/go-booba

[2] https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p...

I'm adding a BubbleTea Picture widget to ntcharts. So the example is a (retro art of (retro art redone on retro tech)) done on (a redo of retro tech) ...

I've added it, but it's still on a feature branch :

https://github.com/NimbleMarkets/ntcharts/tree/picture/examp...

I’m just noting for interest that firms are applying transformers and other networks at this streaming microstructure level, but specially trained for feature extraction. HRT + Nvidia have some nice videos about it

I will also note that it is insane how much better all the LLMs are at calling MCP tools after just a year, especially the local ones.

One of the reasons I like DuckDB is the scale flexibility. I started with grabbing data and playing on my laptop, then I jumped to a server with high cores and a NAS.

I maintain an OSS SDK for Databento market data. A year ago, I naively wrapped the API and certainly felt this pain. Having an API call drop a firehose of structured data into the context window was not very helpful. The tool there was get_range and the data was lost to the context.

Recently I updated the MCP server [1] to download the Databento market data into Parquet files onto the local filesystem and track those with DuckDB. So the MCP tool calls are fetch_range to fill the cache along with list_cache and query_cache to run SQL queries on it.

I haven't promoted it at all, but it would probably pair well with a platform like this. I'd be interested in how people might use this and I'm trying to understand how this approach might generally work with LLMs and DuckLake.

[1] https://github.com/NimbleMarkets/dbn-go/blob/main/cmd/dbn-go...

That sort of GPU code has a lot of concepts and machinery, it’s not just a syntax to express, and everything has to be just right or you will get a blank screen. I also use them differently than most examples; I use it for data viz (turning data into meshes) and most samples are about level of detail. So a double whammy.

But once I pointed either LLM at my own previous work — the code from months of my prior personal exploration and battles for understanding, then they both worked much better. Not great, but we could make progress.

I also needed to make more mini-harnesses / scaffolds for it to work through; in other words isolating its focus, kind of like test-driven development.