-
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).
https://github.com/charmbracelet/bubbletea/discussions/434
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
This was a great read.
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/
-
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.
We're building a lot of SSH apps over at https://pico.sh
-
This is the same TUI app workflow I've settled on in other languages. 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.
