Define terrible. Wasteful, yes. But when we run chat programs inside electron apps, does it really matters?
> is the superior approach
My idea of superiority is linked to availability and support. Multiple competing formats are often a problem
> Kitty has an (incompatible) variant
Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.
From a dev perspective, it's a lot easier to base64 an image you already have, with a base64 that's already in your stdlibs, than to scour github for a passable sixel library to pre-rasterize that jpeg & reformat it as sixel. I say this as someone who's written a sixel conversion library.
> competing formats
It's not a very old format, yet already supported on 4-5 terminals last I checked.
&& find a decent FFI wrapper if my app isn't in C-land
&& read the docs
&& static link hassles so I don't have to sort-out dynamic-link hassles for every platform
|| round-up a collection of dynamic libsixel libs & figure out how to bundle them with my script if I'm not using a compile-to-machine-code language
vs
b64 := base64.Encode(myImg)
fmt.Printf("\x1b]1337;inline=1;size=%d:%s\n", len(b64), b64)
Any hope for standardization?
I do everything I can to help popularize sixels - it could be a default fallback format: sixel-tmux could "rewrite" on the fly sixel sequences into kitty iterm2 or whatever
https://sw.kovidgoyal.net/kitty/graphics-protocol/
If the goal is to hot-patch graphics into existing TUIs, Kovid is probably on the right track with this. It needs to be something richer than what sixel or iTerm2 provide--with pixel placement, play/pause, scaling, etc. Though for a do-over of piping a UI over a (relatively) low-bandwidth wire, I think something like Sun NeWS would have been a simpler & more feature-complete approach.
(disclaimer: I'm the wezterm guy)