22 पॉइंट द्वारा GN⁺ 2026-02-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code का उपयोग करके Hatchet टीम ने टर्मिनल-आधारित UI (TUI) को तेज़ी से विकसित करने का एक उदाहरण साझा किया
  • Charm stack (Bubble Tea, Lip Gloss, Huh) का उपयोग कर React-स्तर की component-आधारित development और consistent styling लागू की गई
  • मौजूदा web UI के समान API का उपयोग करते हुए भी text-centric, information-dense interface के ज़रिये developer efficiency बढ़ाई गई
  • Claude Code ने tmux session चलाकर testing को automate किया, जिससे iterative development और stability सुनिश्चित करने में बड़ी भूमिका निभाई
  • सिर्फ 2 दिनों में पूरा हुआ Hatchet TUI, LLM-आधारित development से वास्तविक productivity improvement दिखाने वाले उदाहरण के रूप में आंका गया

TUI development की प्रेरणा

  • Hatchet टीम k9s जैसा TUI चाहती थी, और उपयोगकर्ताओं ने इसे web UI से तेज़ और अधिक सहज बताया
    • उपयोगकर्ता feedback में यह राय भी थी कि “CLI और TUI कहीं बेहतर perform करते हैं”
  • TUI में code वाले उसी environment में workflow को visualize और run किया जा सकता है, इसलिए tab switching की ज़रूरत नहीं होती
  • Hatchet के मुख्य उपयोगकर्ता IDE के भीतर काम करने वाले developers हैं, इसलिए लक्ष्य terminal के भीतर workflow management experience देना था

तकनीकी stack

  • सामान्य frontend stack (React, Tailwind आदि) के समकक्ष Charm stack का उपयोग किया गया
    • प्रमुख libraries: Bubble Tea, Lip Gloss, Huh
    • इसका maintenance Charm टीम करती है, और documentation व examples भरपूर हैं
  • Lip Gloss और Huh theme का उपयोग करके पूरे TUI में consistent style लागू की गई
    • Hatchet CLI commands में भी वही theme दोबारा उपयोग की गई, जिससे एकीकृत user experience मिला
  • Bubble Tea के बाहर custom composition कुछ कठिन है, लेकिन React-आधारित rendering engine को सीधे implement करने से यह कहीं अधिक सरल है

testing approach

  • Claude Code ने terminal-आधारित tools को सीधे चलाकर tests किए
    • tmux capture-pane का उपयोग करके rendered view को capture किया गया और सही output की जाँच की गई
  • यह तरीका पहले test pass के automation के लिए बहुत प्रभावी रहा, और views बढ़ने पर भी rendering को स्थिर रूप से verify किया जा सका
  • इसके बाद manual testing और unit testing को साथ में चलाकर स्थिर iterative development loop बनाया गया
  • Claude Code ASCII environment में repetitive work के लिए optimized है, इसलिए test feedback loop तेज़ी से converge हुआ

कुशल development environment की संरचना

  • Claude Code ने मौजूदा Hatchet frontend implementation को संदर्भ के रूप में इस्तेमाल कर development efficiency बढ़ाई
    • React-आधारित सरल component structure और OpenAPI spec का उपयोग करके स्पष्ट boundaries तय की गईं
    • auto-generated REST API client के माध्यम से spec-driven development संभव हुआ
  • DAG-आधारित renderer को implement करना सबसे कठिन हिस्सा था, लेकिन
    • mermaid-ascii को संदर्भ बनाकर ASCII graph renderer सफलतापूर्वक बनाया गया
    • यह पूर्ण नहीं है, फिर भी काम करने योग्य DAG visualization feature हासिल किया गया

परिणाम और सीख

  • कुल development अवधि लगभग 2 दिन रही, जो पिछले frontend refactoring की तुलना में कहीं तेज़ और अधिक स्थिर थी
  • Claude Code के साथ किया गया development गैर-यादृच्छिक और वास्तविक productivity improvement दिखाने वाले पहले उदाहरण के रूप में आंका गया
  • Hatchet टीम आगे भी non-core path features में LLM-आधारित development का उपयोग धीरे-धीरे बढ़ाने की योजना बना रही है
  • मुख्य सीख है छोटे feedback loops, modularity, spec-driven design, और continuous testing का महत्व
  • पूरा हुआ Hatchet TUI https://tui.hatchet.run पर सार्वजनिक है, और उपयोगकर्ता feedback एकत्र किया जा रहा है

1 टिप्पणियां

 
GN⁺ 2026-02-15
Hacker News टिप्पणियाँ
  • यह विडंबना है कि वेबपेज टर्मिनल UI performance की बात करता है, लेकिन CSS mask compositing या cubic gradient जैसे जटिल effects की वजह से मेरे high-end Dell XPS laptop पर भी scrolling अटकती है
    Gemini के अनुसार इसे “Scrim या Easing Gradient” कहा जाता है, और smooth fade बनाने के लिए 16 color stops का इस्तेमाल करने के बजाय, scroll करते समय हर बार लाखों pixels के color calculations फिर से करने पड़ते हैं
    Firefox में ज़्यादातर pages smooth scroll होते हैं, इसलिए इसे Mac के बजाय iGPU-आधारित hiDPI laptop पर भी test करने की सलाह है
    संदर्भ के लिए gradient disable किया हुआ image भी है — लिंक

    • सही बात है। पहले उस effect को हटाकर performance बेहतर करने या उसे पूरी तरह हटाने पर विचार करूँगा। feedback के लिए धन्यवाद
    • “Commodore 64 स्तर” कहना कुछ ज़्यादा ही है। C64 में वास्तव में smooth scrolling संभव थी
    • Firefox या दूसरे browser में CSS या JS के बिना पढ़ने का तरीका साझा किया गया। busybox ssl_client और grep का उपयोग करके HTML निकालने और उसे Firefox में खोलने वाला एक simple script दिया गया
    • ब्लॉग पोस्ट में Claude Code का जितनी बार ज़िक्र हुआ, वह काफ़ी ज़्यादा लगा
    • मेरे Commodore 64 को दोष मत दीजिए। प्रोग्राम load हो जाने पर वह 50~60Hz पर बहुत smoothly चलता है
  • मुझे लगता है कि TUI का GUI जैसा दिखने की कोशिश करना थोड़ा दुखद है। accessibility कम हो जाती है, structure सपाट हो जाता है, और user तयशुदा तरीके के अलावा इस्तेमाल नहीं कर पाता। इसके विपरीत modern GUI OS से structurally जुड़ा होता है, इसलिए कहीं ज़्यादा स्वतंत्र होता है

    • मैं सहमत नहीं हूँ। कुछ problem domains में TUI कहीं ज़्यादा उपयुक्त है। उदाहरण के लिए Debian package configuration dialogs साधारण text से कहीं अधिक सुविधाजनक हैं, और SSH या serial console पर भी अच्छे से काम करते हैं। CPU graph दिखाने वाले tools जैसे मामलों में, जहाँ visual information चाहिए, वहाँ भी यह उपयोगी है
    • मैं TUI इसलिए इस्तेमाल करता हूँ क्योंकि मुझे कोई और Electron app install नहीं करनी पड़ती। यह हल्का है और browser embed नहीं करता, इसलिए resource waste कम होता है
    • मुझे लगता है कि TUI की सीमाएँ ही UI designer की focus बढ़ाती हैं। आजकल apps में menu छिपे रहते हैं, जिससे असुविधा होती है, जबकि TUI ज़्यादा स्पष्ट होता है
    • मुझे पसंद है कि सब कुछ terminal के अंदर चलता है। मेरा workflow tmux जैसे multiplexer-केंद्रित है, इसलिए अलग window खुलने पर flow टूट जाता है। यह सीमा ही simplicity और consistency देती है
    • Emacs, Vim, mc, htop, mutt जैसे उदाहरण देखें तो TUI काफ़ी शक्तिशाली है। हर UI का चमकदार होना ज़रूरी नहीं है
  • पहले की तुलना में TUI development अब बहुत आसान हो गया है। इसकी वजह BubbleTea, Textualize, Ratatui जैसे frameworks हैं।
    LLM की वजह से अब ऐसे tools जल्दी बनाए जा सकते हैं, और मैं NTCharts नाम की TUI chart library maintain कर रहा हूँ
    Gemini की spatial understanding की मदद से bugs हल किए, और अभी BubbleTea से local LLM conversation viewer बना रहा हूँ
    संबंधित लिंक: NTCharts issue, thinkt project

  • मुझे समझ नहीं आता कि LLM apps में TUI के प्रति यह जुनून क्यों है। VS2026 के Copilot को देखें तो GUI बहुत अधिक information तेज़ी से दिखाता है। real-time में diff पर click करके जाँचा जा सकता है, इसलिए यह ज़्यादा efficient है

    • मैं VSCode इस्तेमाल करता हूँ, और AI agent sidebar को अलग window में खोल पाने के बाद यह Claude Code से कहीं अधिक सुविधाजनक हो गया है। visual information density और precision, दोनों ही TUI से बहुत बेहतर हैं
    • कारण सरलता है। TUI file system के ऊपर जल्दी से UI चढ़ाने का सबसे आसान तरीका है। web technology से करना हो to browser और server दोनों चाहिए
    • Claude Code की capabilities अच्छी हैं, लेकिन VSCode का AI diff preview UI मुझे कहीं बेहतर लगता है। हालाँकि नया integrated version अभी भी काफ़ी buggy है
    • सच कहें तो यह कुछ हद तक LARP(role-play) जैसा लगता है। “असल hacker” जैसा दिखने की एक symbolic activity, जबकि वास्तव में यह React/CSS से बना web app है
  • जिस दौर में LLM computing resources को निगल रहे हैं, उसी ने उल्टा हल्के stack वाले tools बनाने की प्रेरणा भी दी है।
    C में लिखकर CPU performance हज़ारों गुना बढ़ाई गई और RAM आधी कर दी गई। TUI इस तरह की efficiency का अच्छा उदाहरण है

    • फिर भी native GUI या Flutter जैसे frameworks, TUI से बेहतर performance दे सकते हैं
    • यह सवाल है कि LLM training में लगी energy को optimization से कितना offset किया जा सकता है
    • TUI dependencies कम करने में भी अच्छा है। पहले 100 npm packages चाहिए होते थे, अब 200 lines की JS काफ़ी है
  • मुझे लगता है Midnight Commander(mc) अब भी सबसे बेहतरीन TUI में से एक है। यह GUI version(Double Commander) के लगभग बराबर features देता है और remote पर भी चल सकता है।
    अभी नए skin पर काम चल रहा है, और उम्मीद है कि वह अगली release में शामिल होगा

    • व्यक्तिगत रूप से मुझे Far Manager या Dos Navigator ज़्यादा stable लगते हैं
    • mc developers का धन्यवाद
  • Gemini ने मेरे DHT scraper project के लिए TUI बना दिया — image
    पहले version में CJK character issues की वजह से कुछ fixes चाहिए थे, लेकिन कुल मिलाकर यह प्रभावशाली था। इसकी वजह से मैं algorithm पर ध्यान दे पाया

    • जानना चाहूँगा कि कौन-सी library इस्तेमाल की गई
    • DHT से जुड़े projects में रुचि है। search engine वगैरह में इसका उपयोग कैसे होता है, यह जानना चाहूँगा
    • यह पुष्टि की गई कि “DHT” का मतलब Distributed Hash Table है। TUI को शानदार बताया गया
  • मुझे ठीक से समझ नहीं आता कि TUI, web form या GUI से बेहतर किस बात में है। लेकिन CLI pipeline composition मुझे बहुत शक्तिशाली लगती है

    • कुछ संस्थाएँ(NSA, CSE, GCHQ आदि) security reasons से web admin UI पर प्रतिबंध लगाती हैं। इसलिए हमारा product local console या SSH-आधारित TUI से manage किया जाता है। बहुत restricted SELinux MAC settings इस्तेमाल होती हैं
    • CLI के साथ-साथ चल सकने वाले apps के लिए TUI सुविधाजनक है। tmux/zellij से windows बाँटना आसान होता है, और अलग-अलग OS में UI differences भी कम रहते हैं
    • TUI SSH environment में खास तौर पर उपयोगी है। smartphone SSH clients में भी यह अच्छी तरह काम करता है
    • Gemini ने मेरे C# project के लिए TUI बनाया था, लेकिन बाद में Kestrel webserver embed करना बेहतर बताया। वह बात सही निकली
    • TUI अच्छे keybindings देता है और command execution location से सीधे पहुँचा जा सकता है, इसलिए quick tasks के लिए उपयुक्त है
  • मुझे Claude Code पसंद है, लेकिन React-आधारित TUI architecture सच में बहुत inefficient लगती है

    • खासकर लंबे text को scroll करते समय performance drop काफ़ी गंभीर होता है। लगता है शुरू से यही structure था, समझ नहीं आता कि इसे ठीक करना इतना मुश्किल क्यों है
    • अगर rendering पहले से ही JS में हो रही है, तो React को reconciliation engine की तरह इस्तेमाल करना तर्कसंगत हो सकता है
  • मैंने Cursor CLI के आधार पर अपना prompt frontend बनाया है — image
    इसमें git, diff, chat history को integrate किया है, और Tailscale के ज़रिए phone से भी आसानी से access किया जा सकता है।
    यह मेरे rules को पहचान सकता है और project को grep कर सकता है, इसलिए usability बहुत ऊँची है