Stop Making TUIs: почему терминальные интерфейсы устарели

Stop Making TUIs: почему терминальные интерфейсы устарели

Автор, разработчик с 30-летним стажем, утверждает, что TUIs (терминальные пользовательские интерфейсы) — пережиток 1970-х, и их создание почти всегда ошибка. Вместо них он предлагает использовать LLM-агенты для генерации нативных GUI-приложений, которые проще, удобнее и не уступают по функциональности. Он приводит примеры своих SwiftUI-приложений, созданных с помощью ИИ, и объясняет, почему CLIs остаются полезными, а TUIs — нет.

Мы строим терминальные интерфейсы, потому что вынуждены, а не потому что должны.
  1. joshka

    Возможно, на macOS есть отличные API, библиотеки и тулкиты для создания качественных GUI, но если вы хотите писать open source ПО или ориентироваться на open source платформы, ваш выбор ограничен и плох. На стороне Linux/BSD большинство тулкитов не очень хорошего качества, вы получите в наследство всевозможные тонкие баги и странное поведение. Большинство ПО _отличного_ качества не использует тулкит, а взаимодействует с композитором напрямую. Усилия по разработке GUI в таких условиях значительно выше, чем TUI, и TUI обычно «достаточно хорош». Я бы действительно предпочёл GUI для многих вещей. Но когда TUI занимает несколько недель, эквивалентный GUI занял бы несколько месяцев.

  2. omnibrain

    Забавно, я сейчас создаю TUI. Почтовый клиент вроде mutt. У меня не было ни секунды сомнений, чтобы рассматривать GUI для этого проекта, потому что это настолько нелепо. Он изначально кроссплатформенный (msys под windows). Он позволяет копировать любую часть интерфейса. Ему не нужны зависимости, кроме curses.

  3. tescreal

    Табы против пробелов. Я всегда ценил положительные стороны TUI и меньше ценил положительные стороны GUI. Я вообще не вырос с компьютером, и на одной из моих первых взрослых работ мне пришлось использовать TUI в Papa John's для ввода заказов — это было в 20 раз быстрее, чем всё, что я использовал после в других ресторанах с GUI (скорость клавиатуры для меня выигрывает, идеально подходит моему мозгу). Думаю, я научился за 5 минут. Я был просто обычным человеком, пытающимся оплатить счета. Не знаю, зачем нам оскорблять чьи-то предпочтения — статья в этом отношении действительно плоха.

  4. yipinwong

    Как мейнтейнер библиотеки ratatui, НЕТ — пожалуйста, не прекращайте делать TUI ;) Как разработчик вне этого, я люблю приложения «почесать зуд», упомянутые здесь. У меня есть виброкодированное приложение для построения шахматного репертуара на SwiftUI, которое попадает в ту же категорию, над которым я сейчас работаю, и я, вероятно, не выбрал бы исследовать эту идею, если бы не кодирующие агенты. Я согласен со статьёй, что терминал имеет странную форму, с которой ты борешься против исторических спецификаций и т.д. Ключевое наблюдение, которое у меня есть, — это то, что несоответствие терминальных приложений и библиотек для работы с этим в основе построено на символьных ячейках и перемещении курсора плюс различные протоколы CSI/OSC/ASC/DEC/xterm/..., которые сложны, имеют разную поддержку и взаимодействуют странными способами. Чтобы получить хороший терминальный UX, я думаю, ответ — выбросить весь этот бардак совместимости и перепроектировать современный терминальный протокол, который включает доступность, регионы, прокрутку, выделение, правильную клавиатуру и т.д. Я знаю, что у Митчелла Хашимото немного другой взгляд на это, который, похоже, заключается в определении дополнительных протокольных вещей и продолжении развития на их основе. Я думаю, это, вероятно, достигает 95% довольно хорошо. Но 100% хорошее — это полная замена.

  5. matheusmoreira

    Одно из самых больших преимуществ TUI перед GUI — я могу запускать любое количество экземпляров TUI. Между тем разработчик GUI должен решить, оказать ли мне честь возможностью открыть более одного окна. «Вкладки будет достаточно!» — ура, я никогда не смогу видеть два экрана информации одновременно.

  6. pkulak

    Продолжайте делать TUI. Продолжайте делать всё, что хотите. Эти комментарии вроде «терминалы не для этого созданы» немного утомляют. Я могу запускать TUI на машинах, к которым у меня есть только ssh-доступ, и они часто легче, чем соответствующий GUI-вариант — хотя, возможно, с сегодняшними более навороченными TUI это уже не так. 'top' имеет TUI и не нов, некоторая интерактивность — да, даже в терминале — может быть приятной. Я сейчас пытаюсь создать GUI-версию (библиотека immediate mode) своего CLI-инструмента, и это в основном полный бардак и в три раза больше работы, чем CLI-инструмент с данными на входе и выходе. Хороший опыт обучения, правда. Стоит отметить, что мне не важно, имеет ли GUI-версия «нативное ощущение» или нет (если у вас есть время на это — милости просим), важно только, функциональна ли она и достаточно быстра, поскольку иначе это ещё больше работы для open source инструмента. Хотя, когда я, несомненно, позже сделаю более интерактивную TUI-версию (ratatui просто слишком хорош, чтобы не попробовать! :-)), она, вероятно, принесёт схожую сложность в разработке. С другой стороны, я вообще не увлекаюсь агентным кодированием, так что, возможно, шутка надо мной. С другой стороны, сейчас мне нужно изучать данные, которые я обрабатываю, библиотеку/фреймворк GUI, который я использую, и уметь помогать людям, с которыми я работаю, устранять неполадки оборудования, собирающего эти данные. Я бы упустил большую часть этого, если бы кодировал по подсказкам. Возможно, попробую позже, возможно, нет. Продолжайте делать TUI или GUI, если на то пошло.

  7. israrkhan

    Согласен с остальными комментариями здесь: продолжайте делать TUI. Полностью управляемые с клавиатуры, компактные интерфейсы, которые живут в моём терминале вместе с остальными моими CLI-инструментами, — это лучшее!

  8. sjbzbeiks

    «В: Сынок, для чего нужен оконный менеджер? О: Чтобы запускать несколько терминалов на одном дисплее.»

Ещё за этот день

2026-08-22