Bubble Tea (a Go TUI framework) recently hit 1.0 [1] and the author's tool that is built with it is called pug [2] which is an awesome terminal user interface for terraform which we featured on Terminal Trove [3] a while back.
The author describes the same TUI app workflow I've settled on. Three notes:
- entr is a good livereload tool: https://eradman.com/entrproject/. I prefer to wrap the livereload scripts in a Makefile, under something like `make dev`.
- Managing layout arithmetic by yourself is a real pain. A widget abstraction like Bubbletea's is very helpful. Also, don't forget about weird Unicode characters (eg. emoji) potentially breaking width calculations.
- Since this follows the Elm architecture, consider storing your data the Elm way into one big, flat Model. Elm webapps turn into headaches when you split state among submodels. I think the same happens in TUI apps. I'm glad the author found a solution with a tree of models and message passing. But personally, I'd rather have a Model with 100 fields than the complexity of sumbodels.
Very coincidentally I actually found myself needing a Go TUI library for a small program I wrote just last week with pretty simple needs (some basic dynamic list views including a file picker view) and I spent about half an hour messing with bubbletea before tossing it away and switching to tview
I don't doubt that bubbletea is a far more elegant and powerful library than tview for writing Go-based TUIs but for my relatively simple application I didn't need that power and yet bubbletea still expected me to pay for it in terms of understanding its architecture at a pretty deep level just to make it do anything at all.
It very much does not adhere to the idea of "keep the simple things simple" (which IMO makes it kind of a strange fit for Go, as that's the primary thing I love about Go).
And this is coming from someone who spent a lot of time in the past doing C-based Win32 programming which actually has a lot of similarities to bubbletea's message-based architecture and despite that I still couldn't be assed to deal with learning bubbletea's complexity when my needs didn't feel like they called for it.
I have to agree. At first I loved the idea of bubbletea but I have given up on using it because I feel it is too immature. There are some poor/unfinished design choices that make widgets from different authors take different approaches. Layouting is very difficult as this is not part of the framework and depends on often half-baked third party widgets. Theres this discussion where there seems to be very little movement from the authors to improve the situation (also linked from OP's blogpost).
Yeah I am testing using it on an SSH server I wrote for a service that I have to have some interactive management UI. It is nice for small menus and things similar to the example but building an entire complex application with it would be hard to maintain.
> go func() { […] m.content = "initialized\n" }() […]
> …but only once a key is pressed several seconds later does it return:
> initialized
> For this reason, making changes to the model is best done in the normal message flow, either in Update() or via a tea.Cmd.
Not just best practice, but absolutely necessary because the code has a proper race condition. It must absolutely be avoided at all cost. Fortunately, it’s easy to do: never mutate the model outside of the event loop (ie a separate goroutine). Fortunately Go’s race detector is generally excellent at detecting this at runtime as well, so it’s always a wise idea to add -race to your testing/QA process. It surprises me Google built such an awesome and easy-to-use tool yet few seem to use it.
Great post btw. I use a homegrown similar architecture myself. I do wish Go had better dispatch architecture than a switch statement but it’s not the end of the world.
I've wanted to write a TUI with Bubbletea, but as the author points out, getting started with it is very intimidating. I feel the brute-force approach of "just doing it" is probably the only way to produce something as nice as pug.
That said, I've bookmarked this excellent resource should I decide to pursue that path soon. Thanks for the write-up!
I’ve been writing small web apps for internal teams and Bubble Tea has been super helpful for building TUI managers for these apps. The article does a good job explaining some of the finer details of the library.
A lot of the apps need to interface with our ERP's database so I have to build out the interface layer. Since I'm already writing in Go, it's super easy to add a TUI to call the interface layer for testing/ one off interactions. For example, one app has a pretty simple auth rolled into it. I wrote a quick user manager to handle creating and updating users in the database. Recently, I've actually been making more use of Huh since the TUI's usually aren't stateful, but I still really like the model of Bubble Tea
good stuff thanks. even though i dont use go nor bubbletea for my tui app work in progress this had a lot of good insights. might even consider go and bubbletea if i get really stuck :D
At least for SSH apps that run TUI programs the answer is obvious: golang implements the SSH protocol as a library. It is probably one of the greatest features of the stdlib.
Charm provides an excellent suite of tools for building TUIs; bubble tea is only one of them. It’s gotten me interested in building CLI programs, as an anecdote.
Bubble Tea (a Go TUI framework) recently hit 1.0 [1] and the author's tool that is built with it is called pug [2] which is an awesome terminal user interface for terraform which we featured on Terminal Trove [3] a while back.
[1] https://github.com/charmbracelet/bubbletea/releases
[2] https://github.com/leg100/pug
[3] https://terminaltrove.com/