Bubble Tea: fun, functional and stateful way to build terminal apps
11–20 of 116 posts
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#12This and the surrounding ecosystem was recently featured on an episode of The Changelog podcast. https://changelog.com/podcast/481
https://changelog.com/podcast/481#transcript
And a couple audiogram snippets from the conversation:
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#13Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#14I don't like things that pollute our natural language namespace. Couldn't you have named it something unique?
Ruby, Python, Java, Rails, React, Go, Rust, Elm, Dart, C, C#, Node, Next, Nest, Kafka, LaTeX, bash, fish, cat, Android, Apple, Windows…
I'd be happy to search for this with "bubble tea framework" or "bubble tea tui" or similar and it doesn't bother me.
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#15Earlier quoted context omitted.
Just curious, I'm not familiar with Go. Will it copy the references anyway, meaning both structures now have a pointer to the same object? That's the way it works in other languages I'm familiar with, so you have to be careful about what you copy and how you use it.
Yes, but it doesn't actually matter. You can use pointers for models, return the same pointer, and it will re-render fine. We do this for our CLI at https://www.inngest.com for creating new serverless functions via a quick walkthrough. It's actually the `tea.Msg` that causes re-renders. Here's the code: https://github.com/charmbracelet/bubbletea/blob/v0.20.0/tea.... . tea.Msg is, in Redux land, an "action" that trigg…
For example, say you needed an undo/redo mechanism. If the model were guaranteed to be immutable model, you could simply hang on to the previous models as a sequence of state changes; undoing/redoing is trivial. If the model is mutable, then the undo/redo system has to defensively make a copy before update is called
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#16Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#17The achilles heel of terminal UIs is that they can't display images.
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#18I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…
Sure, it's something you can do with SSH via X11 forwarding since forever, but it seems the ecosystem never quite stuck the landing, and now we're here trying to figure out how to make CLI more like GUI for our own sanity.
Maybe we should give it another shot? It seems Windows is trying to do something similar with WSLg to achieve seamless integration of Linux apps within Windows 11 (using RDP under the hood), what is everyone else doing?
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#19I don't like things that pollute our natural language namespace. Couldn't you have named it something unique?
An overwhelming number of programming-related things "pollute our natural language namespace". Off the top of my head: Ruby, Python, Java, Rails, React, Go, Rust, Elm, Dart, C, C#, Node, Next, Nest, Kafka, LaTeX, bash, fish, cat, Android, Apple, Windows… I'd be happy to search for this with "bubble tea framework" or "bubble tea tui" or similar and it doesn't bother me.
Re: Bubble Tea: fun, functional and stateful way to build terminal apps
#20One thing that I like about this is the implementation of returning state from the Update function. My only experience with Elm-style architecture is with react / redux which involves meticulously copying pieces of the state object to return two distinct before / after states. Using a Go struct with copy semantics makes this extremely easy and more natural to write in an imperative fashion. One limitation of this is…
>One limitation of this is that the model structure can only contain value type (e.g. no pointers, arrays, or maps) How does one manage dynamically sized lists of elements, if arrays are disallowed?