■ 🕑 1. Writing app for terminal? No-Use Curses 
   I wanted to share some thoughts on why one might consider using direct ANSI escape codes instead of ncurses for modern terminal UI development. This isn't a dismissal of ncurses (which was revolutionary in its time), but rather a reflection on how terminal technology has evolved since the 1980s/90s. Here's the breakdown:
   
       The Shift in Terminal Technology
       Old World: ncurses and termcap were designed to abstract away wildly inconsistent hardware terminals (DEC VT100, WYSE, etc.). Each device had its own quirky command set, so a translation layer was essential.
       Modern World: Today's terminals (xterm, GNOME Terminal, libvte-based apps, macOS/iTerm2, Windows Terminal, etc.) all speak a common subset of ANSI/ECMA-48. This standardization eliminates the need for most of the abstraction ncurses provides.
   
       24-Bit Color Support & the "Color Pair" Problem
   
       ncurses uses a paletted color model (predefined color pairs for FG/BG), which works poorly with modern 24-bit color. With 16 million colors available, the combinatorial explosion of color pairs becomes unmanageable. Direct ANSI codes let you set RGB values on the fly, avoiding this limitation entirely.
   
       Fallback Complexity
   
       ncurses still prioritizes backward compatibility with ancient terminals (e.g., monochrome displays, terminals without cursor support). If your target audience uses modern terminals (which they almost certainly do), this forces you to write unnecessary fallback logic. Why spend time supporting DEC VT220 when everyone’s on xterm-256color?
   
       Simplicity & Control
   
       For most modern terminal UIs, the core features needed are:
       Clearing the screen \x1b[2J
       Moving the cursor \x1b[<row>;<column>H
       Setting 24-bit FG/BG colors \x1b[38;2;<R>;<G>;<B>m / \x1b[48;2;<R>;<G>;<B>m
       Basic styling (bold, underline, etc.)
       A lightweight header with ANSI escape helpers gives direct control over these features without the baggage of ncurses' stateful API or terminfo lookups. It’s simpler, leaner, and more flexible for modern use cases.
   
       Portability Isn’t (As) Painful Anymore
   
       The curses era began to end with the creation of the first terminal emulator software 35 years ago. Since then prgrammers of terminal applications can assume the terminal speaks ANSI/ECMA-48; xterm, gnome-terminal, urxvt, kitty, alacritty, zutty and even Winblows Terminal all support the same core ANSI features. If you’re not explicitly targeting old hardware serial terminals besides DEC, you might as well use the ANSI standard control codes.
   
   ncurses was a necessary solution for 1980s application programmers targeting broad terminal compatibility across different brands of hardware serial terminals.
   
   For modern terminal apps ANSI escape codes offer:
   
   * Less abstraction overhead
   * Direct access to modern features (like truecolor)
   * Simpler codebases (no need to manage color pairs or fallbacks)