This. What I'd really like is some sort of simple API/structured data standard that tools could implement and then a "generic technical UI" which can automatically generate a UI for that tool. (the UI doesn't have to be pretty or fancy, as long as it lets me quickly and effectively make use of the tools).
I think REST endpoints with an OpenAPI definition that automatically lets you generate an HTML documentation with built-in API client goes a bit into that direction. As did Microsoft's idea of "commandlets" I believe. As, actually, did HTML+HTTP in its original inception. However, so far all of those massively fall short in the "allow effective use of the tool" metric: For actual work, it's still way faster and more convenient to make a REST call via curl (once you figured out how to assemble the call!) - than to click around in the OpenAPI client. But maybe some future tool/standard could bring something better to the table here.
> we don't have animation frameworks for the terminal is because it's not possible
We've had AAlib for 3 decades already: https://en.wikipedia.org/wiki/AAlib - and it's not the only game in town.
But things like smoothly opening a menu are doable by just adding line by line, and dialogs can be animated by doing an animation that expands a window from the center.
But we definitely did have it in the 90s:
No, thanks. My problem with such ideas is not the feature itself but the fact that UI tooling always aims to make use of the medium's full potential, and applications then always follow suit. The only reason we don't have animation frameworks for the terminal is because it's not possible, and I'd like it to stay that way.
More accessibility would be great but you don't need pixels for that either.
Better than images & pixels in the terminal would be a GUI platform that is as simple to use and integrate as the terminal and still feels natural to use with the keyboard. And has a toggle for animations.