TUI फिर से क्यों लौट आया है
(wiki.alcidesfonseca.com)- TUI को उसकी तुरंत मिलने वाली feedback, automation में आसानी, और अलग-अलग operating systems पर चलने की क्षमता की वजह से फिर से ध्यान मिल रहा है; Claude और Codex जैसे tools ने भी command line पर बड़ी सफलता पाई है
- Windows, Linux, macOS के native GUI अपने-अपने अस्थिर API strategy, toolkit और environment के बिखराव, और पुराने guidelines के साथ कमज़ोर होती consistency की वजह से developers और users दोनों पर बोझ बढ़ाते हैं
- Electron apps में memory usage से बड़ा मुद्दा visual consistency की कमी और keyboard-centric workflow में मौजूद खालीपन है; menu और shortcut integration भी कमज़ोर हो गई है
- Google के Flutter UI प्रयास और Zed के GPUI जैसी नई UI stack बनाने की कोशिशें हुईं, लेकिन अगर operating system integration कमज़ोर हो तो सिर्फ तेज renderer काफ़ी नहीं होता
- अच्छी interface की कुंजी consistency है, जो users को कम सोचने पर मजबूर करती है; developers और operating system/toolkit बनाने वालों को UI theory और अधिक सुलभ toolkits में ज़्यादा निवेश करना चाहिए
TUI पर फिर से ध्यान क्यों जा रहा है
- DHH का Omarchy एक मिश्रित रूप में बना है, जिसमें TUI, web apps, और gnome शैली के native apps शामिल हैं; TUI का इस्तेमाल तुरंत feedback और “geek points” के लिए होता है
- लगभग 10 साल पहले code editors में भी ऐसा ही रुझान था
- BBEdit, Textmate, Notepad++, Sublime जैसे native editors से Atom, VSCode और उनके derivative apps जैसे Electron-आधारित apps की ओर बदलाव हुआ
- जिन users की पसंद बहुत मज़बूत थी, वे vim या emacs की ओर चले गए; वहाँ उन्हें तुरंत feedback और ऊँची usability मिली, लेकिन बदले में बहुत कठिन learning curve स्वीकार करनी पड़ी
Native GUI कमज़ोर क्यों हुए
-
Windows
- Windows एक consistent GUI library strategy बना नहीं पाया, और अगर एक API सफल नहीं हुई तो दूसरी API बनाने का क्रम बार-बार दोहराता रहा
- Jeffrey Snover ने Microsoft hasn’t had a coherent GUI strategy since Petzold में लिखा कि MFC, OLE, COM, ActiveX ने पूरे Windows development में complexity फैला दी
- इसके बाद Microsoft ने WinForms, WPF, Silverlight, WinUI, MAUI तक का सफर किया, लेकिन सफलता नहीं मिली; कई enterprise और consumer desktop apps आज भी Electron apps पर निर्भर हैं
- पूरे Windows के visually consistent होकर integrated दिखने का आख़िरी दौर Windows 98 या Windows 2000 के करीब था
- Domenic Denicola ने Windows Native App Development Is a Mess में तर्क दिया कि हर कुछ साल में OS और UI API को फिर से बनाने की कीमत बहुत ज़्यादा है, और sandboxing तथा feature deprecation की कोशिशों के साथ हर नई layer में ऐसे gaps बन जाते हैं जिनमें पहले frameworks से संभव काम अब नहीं हो पाते
-
Linux
- Linux में UI inconsistency लगभग design का ही नतीजा है, जहाँ अलग-अलग teams को अलग-अलग goals का पीछा करने की आज़ादी रही
- GTK और Qt प्रमुख frameworks बने, और दोनों ने cross-platform native development का लक्ष्य रखा, लेकिन इनका सबसे व्यापक उपयोग मुख्यतः Linux में ही है
- अलग-अलग toolkits से बने Linux apps को साथ रखो तो वे कुछ हद तक ठीक दिख सकते हैं, लेकिन Windows के कई frameworks उस स्तर की harmony नहीं बना पाते
- distributions, desktop environments, और hardware combinations बहुत ज़्यादा होने से testing कठिन है, इसलिए कई कंपनियाँ native Linux apps बनाती ही नहीं हैं
- कंपनियाँ आमतौर पर Linux support के लिए Electron का सहारा लेती हैं, या फिर public API होने पर open source community को इसे खुद सुलझाने देती हैं
-
macOS
- Apple की Human Interface Guidelines इतनी मज़बूत कसौटी थीं कि दुनिया भर में user interface की classes में उनका हवाला दिया जाता था
- Xerox PARC और Apple को इस बात पर शोध करने वाली प्रमुख संस्थाओं में गिना जाता है कि अच्छा human interface क्या होता है
- हाल के समय में Apple अपने पुराने guidelines और consistency को तोड़ने वाली दिशा में बढ़ रहा है
- macOS Fitts's law को नज़रअंदाज़ कर रहा है, window resizing को लगभग असंभव बना रहा है, इसे ठीक करने की कोशिशों के बाद भी समस्या बनी हुई है, और हर menu में icons जोड़ने की दिशा में जा रहा है
- macOS को अब ऐसा सुरक्षित क्षेत्र मानना मुश्किल हो गया है जहाँ designers शांति से काम कर सकें
Electron apps की सीमाएँ
- सबसे ज़्यादा उठाया जाने वाला मुद्दा memory usage है, लेकिन पिछले 10 सालों में memory usage घटने की ओर ही रुझान रहा है
- इससे बड़ा मुद्दा visual consistency की कमी और keyboard-centric workflow का अभाव है
- 64GB RAM वाले MacBook Pro के environment में भी Dock पर 8 native apps और 6 Electron apps साथ मौजूद हैं
- Native apps: TextMate और macOS system utilities
- Electron apps: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
- Cursor और VSCode जैसे apps में agent panel में कोई feature माँगने के बाद सिर्फ keyboard से side panel की agent list तक जाना या उसे archive करना स्वाभाविक नहीं लगता
- ऐसे actions ideally हर macOS app में एक ही तरीके से संभव होने चाहिए, लेकिन shortcut होने पर भी कई बार वे menu में दिखाई नहीं देते
- पिछले 10 सालों में developers में यह प्रवृत्ति बढ़ी है कि app में संभव actions को menu में जोड़ना भूल जाते हैं; यह उस संरचना से जुड़ा है जिसमें applications sandbox के अंदर HTML के रूप में implement होती हैं
- Slack इस मामले को दूसरे Electron apps की तुलना में बेहतर संभालता है, लेकिन वह भी पूरी तरह सही नहीं है
नई UI stack फिर से बनाने की कोशिशें
- Google, Dart के साथ Android की legacy से मुक्त एक नए operating system और नए devices के लिए UI toolkit बनाना चाहता था
- Google को Flutter UI नाम का एक नया UI toolkit चाहिए था, लेकिन असली product launch होने से पहले ही उसने project छोड़ दिया
- ऐसी कोशिशें तभी सफल हो सकती हैं जब आपके पास monopolistic position या बहुत बड़ा market share हो
- Zed ने Rust के साथ इसी तरह का रास्ता चुना और अपना GPU renderer library GPUI बनाया, जो cross-platform होने का लक्ष्य रखता है
- GPUI तेज़ है, लेकिन host operating system के साथ इसका integration अपने आप में पर्याप्त नहीं है, इसलिए developers को ज़रूरी bindings खुद जोड़नी पड़ती हैं
- तेज renderer से बेहतर वह धीमा renderer है जो operating system के साथ अच्छी तरह integrate हो
TUI किस खालीपन को भर रहा है
- Apple Automator के पतन की याद दिलाने वाले संदर्भ में, TUI automation-friendly interface के रूप में फिर महत्वपूर्ण हो गया है
- TUI को remotely चलाना भी काफ़ी आसान है, और इसके लिए सिरदर्द पैदा करने वाले X forwarding पर निर्भर रहने की ज़रूरत नहीं पड़ती
- जब native UI toolkits असफल होते हैं, तो चीज़ें फिर basics पर लौटती हैं, और उसी का नतीजा है कि TUI एक विकल्प के रूप में उभरता है
- Claude और Codex ने command line पर बड़ी सफलता हासिल की है, और users आसपास के operating system की चिंता करने के बजाय interaction पर ध्यान दे सकते हैं
- TUI के ज़रिए cloud machines पर code और apps को संभाला जा सकता है, या iPad से GPU-सक्षम machine पर remote access लिया जा सकता है
- TUI उस खालीपन को भर रहा है जो Apple और Microsoft ने ऐसी दुनिया में छोड़ा है जहाँ हर application अलग दिखती है
- अलग-अलग रूप कला या computer games के लिए अच्छे हो सकते हैं, लेकिन उस उद्देश्य के लिए उपयुक्त नहीं हैं जहाँ interface को पीछे हटकर user को अपना काम करने देना चाहिए
आगे किस दिशा की ज़रूरत है
- John Loeber ने Bring Back Idiomatic Design में कहा कि checkbox भी system के साथ interact करने का interface है, और अच्छी interface वह है जो users को कम सोचने दे
- users बहुत-सी चीज़ों के साथ interact करते हैं, इसलिए उन्हें consistent experience देने वाला homogeneous interface चाहिए
- अगर Command+C copy shortcut है, तो उसे हर जगह काम करना चाहिए; ऐसा तरीका जिसमें किसी खास स्थिति में CTRL+Shift+C या right-click → copy अलग से याद रखना पड़े, असुविधाजनक है
- हर developer को सिर्फ software ही नहीं, बल्कि अच्छे general user interface बनाने की theory भी सीखनी चाहिए
- user design को software engineering curriculum में महत्वहीन soft skill की तरह देखने का रवैया बंद होना चाहिए
- किसी भी process में अगर UI समझ में नहीं आता, तो project को असफल माना जाना चाहिए; HCI courses में लक्ष्य perfect UI होना चाहिए
- अच्छी UI बनाने में ज़्यादातर मेहनत ज़रूरतों को समझने में लगती है; programming खुद तो पहले ही automate हो रही है
- operating systems और toolkits बनाने वालों को ऐसे अधिक सुलभ toolkits बनाने और entry barrier घटाने में निवेश बढ़ाना चाहिए जिन्हें developers इस्तेमाल करना चाहें
- यह ज़रूरी नहीं कि cross-platform support पर ही ज़ोर दिया जाए, लेकिन अगर ऐसा कोई एक समाधान भी हो तो वह Electron और TUI पर निर्भरता कम करने में मदद कर सकता है
4 टिप्पणियां
मुझे भी ऐसा ही लगता है, लेकिन मेरा मानना है कि dev scene ज़रूरत से ज़्यादा trends के प्रति संवेदनशील है। TUI को बस वे कंपनियाँ आगे बढ़ा रही हैं जिनके पास GUI को ठीक से बनाने की क्षमता या इच्छा नहीं है; पता नहीं वास्तव में कितने लोग TUI का इस्तेमाल कर रहे हैं।
Hacker News की राय
सिर्फ़ संख्याएँ देखें तो TUI के लोकप्रिय होने की असली वजह Claude Code है, और बाकी सब उसके मुकाबले बैकग्राउंड नॉइज़ जैसा लगता है
मुझे पहली बार TUI बनाना चाहने की प्रेरणा SSH के ज़रिए ऐप डिलीवर करने के विचार से मिली थी। SSH ऐप इस मायने में ब्राउज़र जैसे हैं कि इनमें लोकल इंस्टॉलेशन की ज़रूरत नहीं होती
मैं https://pico.sh के साथ इतना मज़े से छेड़छाड़ भी इसलिए करता हूँ क्योंकि TUI डिप्लॉयमेंट में यूज़र की किसी भी तरह की दखलअंदाज़ी की ज़रूरत नहीं पड़ती
शायद इसकी वजह भारी-भरकम ब्राउज़र-आधारित UI से निकलने की इच्छा और टर्मिनल रेंडरिंग की सीमाओं को आज़माने की जिज्ञासा है
नए और दिलचस्प टेक से नए सिस्टम बनाने के बजाय हम GPU-accelerated typewriter emulator बना रहे हैं। यह नॉस्टैल्जिया और तकनीकी अंधविश्वास का अजीब मिश्रण है
SSH के ऊपर किसी भी प्रोटोकॉल को चलाया जा सकता है। बेहतर होगा कि हम रिमोट बिटमैप डिस्प्ले पर ड्रॉ करने जैसी दिशा में बढ़ें
X Window की डिज़ाइन भले शानदार नहीं थी, लेकिन उसमें नेटवर्क ट्रांसपेरेंसी थी, और Plan 9 का devdraw ऐसा रेंडरिंग इंजन था जहाँ रिमोट ग्राफ़िक्स प्रोग्राम एसेट अपलोड करने के बाद लाइन ड्रॉइंग कमांड RPC के रूप में भेजता था
vim में सचमुच मुश्किल बस यही है कि मोडल एडिटर का सबसे अहम हिस्सा, यानी कमांड मोड में वापसी, करने के लिए उंगलियों को Escape तक ले जाना पड़ता है
आदर्श फ़्लो यह है कि तेज़ी से एडिट करो और तुरंत कमांड मोड में लौट आओ, इसलिए Escape का इस्तेमाल एक ऐतिहासिक अवशेष है, यह बात माननी चाहिए
इसलिए CapsLock को Escape पर ग्लोबल रीमैप कर दो। Linux और macOS में यह सिर्फ़ GUI सेटिंग्स से हो जाता है, और Windows में भी रजिस्ट्री की बनाओ या बदलो, एक मिनट में काम हो जाता है
इसके अलावा vim-tutor से बेसिक्स सीख लो, और जब कोई काम ज़्यादा समय लेने लगे तो उसे खोज लो, इसलिए मुझे समझ नहीं आता कि सीखने की कठिनाई असल में कहाँ है। असली समस्या यह है कि मोडल एडिटिंग की इतनी जल्दी आदत पड़ जाती है कि उसके बिना माहौल पाषाण युग जैसा लगता है
आजकल मुझे लगता है कि vim में hjkl की ज़रूरत की असली वजह यह है कि कीबोर्ड लेआउट एरो कीज़ के लिए ख़राब है। टाइपराइटर में एरो कीज़ नहीं थीं, लेकिन कंप्यूटर में वे बहुत अहम हैं
स्पेसबार के इतने बड़ा होने की ज़रूरत भी नहीं है, और न ही दोनों अंगूठों से इस्तेमाल करने की। अगर छोटे एरो-की क्लस्टर को स्पेसबार के बाएँ या दाएँ किसी हिस्से में ले जाया जाए तो ज़्यादा बेहतर होगा
hjkl वाला हैक सिर्फ़ हैकरों के एडिटर में चलता है, लेकिन आम सॉफ़्टवेयर में भी एरो कीज़ बहुत इस्तेमाल करनी पड़ती हैं, और मौजूदा लेआउट हाथों के लिए बहुत ख़राब है। पूरे हाथ को हिलाए बिना अंगूठे से एरो की दबाने की कोशिश करते-करते मुझे सूजन होने लगी थी
इससे हाथ होम पोज़िशन से उठकर बाहर जाता है और फिर वापस आता है, जिससे अन्यथा चुपचाप जमा होने वाले RSI पॉइंट्स कम हो जाते हैं
इसी वजह से दूसरे हाथ से मैं एरो कीज़ भी काफ़ी इस्तेमाल करता हूँ। हालाँकि hjkl भी काफ़ी इस्तेमाल करता हूँ
https://github.com/microsoft/PowerToys
jjपर मैप कर दो और काम ख़त्मऔर
Ctrl + [मानक टर्मिनल/ASCII में Esc है, इसलिए Esc तक हाथ ले जाने से थोड़ा आसान हो सकता हैऑपरेटिंग सिस्टम कंपनियों के अपने हित टूटने के बाद जो राख बची है, वही TUI ट्रेंड जैसी दिखती है
एक भी अच्छा जनरल-पर्पज़ UI नहीं है। ब्राउज़र सबसे बेहतर है और काफ़ी सफल भी रहा है, लेकिन sandboxing की वजह से लोकल फ़ाइल या नेटवर्क एक्सेस चाहिए होने पर वह अनुपयुक्त हो जाता है या बहुत friction पैदा करता है। और साधारण चीज़ चलाने के लिए उसका ओवरहेड भी बेतुका है
रिमोट एक्सेस तो और भी बदतर है। जैसे Windows होस्ट पर चल रहे ऐप को Mac से एक्सेस किया जा सकता है या नहीं, या उसे टनल्ड कनेक्शन पर फ़ॉरवर्ड किया जा सकता है या नहीं
TUI एक सरल general-purpose protocol है जो ज़रूरी काम कर देता है, और remote होना उसकी मूल प्रकृति है। जो चीज़ लोकली चलती है, वही SSH कनेक्शन पर भी स्वाभाविक रूप से चलती है
यह उन OS कंपनियों के लिए एक बड़ा मिडल फिंगर भी है जिन्होंने सोचा कि सब कुछ असंगत बना देना या लोगों को इकोसिस्टम में बाँध देना ही जीतने की रणनीति है
Notcurses और Ratatui ने ncurses को बहुत मदद दी है
Windows 11 इसका बहुत अच्छा उदाहरण है, और वह सारा दिखावा सच में ज़रूरी नहीं है
काश TUI वापस न आता। मैं किसी भी दिन TUI के बजाय web interface चुनूँगा
मुझे कोई ज़्यादा चालाक फ़ॉन्ट इंस्टॉल नहीं करना पड़ता, सही दिखाने के लिए टर्मिनल सेटिंग्स नहीं छेड़नी पड़तीं, और यह अनुमान नहीं लगाना पड़ता कि बनाने वाले को कौन-से नेविगेशन शॉर्टकट सबसे महान लगे
असली टेक्स्ट एडिटिंग मिलती है जिसमें ऑपरेटिंग सिस्टम के मानक टेक्स्ट नेविगेशन काम करते हैं, पासवर्ड मैनेजर और टेक्स्ट एक्सपैंडर जैसी चीज़ों के साथ बेहतर इंटीग्रेशन भी मिलता है
मैं CLI के अंदर रहता हूँ और एक शॉर्टकट से टर्मिनल खोल लेता हूँ, लेकिन जब से टर्मिनल ही एकमात्र विकल्प था उस दौर के बाद टेक बहुत आगे बढ़ चुकी है, और UI बनाने के लिए अब बेहतर विकल्प मौजूद हैं
यह पूरा TUI ट्रेंड मुझे बस एक fashion trend जैसा लगता है
क्योंकि कोई भी native UI डेवलपमेंट में निवेश नहीं कर रहा। Electron इस बात का सबूत है कि अगर इस्तेमाल करने लायक GUI stack हो तो कंपनियाँ उसे अपनाती हैं
बड़े ऐप में packaging और deployment में लगने वाला समय कुल काम का छोटा हिस्सा होता है और फ़ाइल साइज़ भी बहुत मायने नहीं रखता, लेकिन छोटे ऐप में ऐसा नहीं है
Windows के लिए ऐप बनाना आसान है, और एक छोटा binary form खोल सकता है, डबल-क्लिक से चल सकता है, और इंस्टॉल भी नहीं चाहिए
Linux में वही चीज़ करने के लिए यह गारंटी नहीं होती कि GTK या Qt इंस्टॉल होगा, इसलिए अगर standalone बनाना है तो लगभग पूरा OS साथ भेजना पड़ता है। फिर फ़ाइल साइज़ बढ़ जाता है
Python भी Windows यूज़रों के लिए मुश्किल है क्योंकि या तो उनके पास Python होना चाहिए या फिर interpreter साथ भेजना पड़ता है
जो एक विकल्प बचता है वह Java की तरह एक single
.jarफ़ाइल है जिसे किसी भी सिस्टम पर चलाया जा सके, लेकिन Oracle ने लाइसेंस बदल दिया और JavaFX अब Java के साथ शामिल नहीं आता। Swing अभी भी शामिल हैमैं तो बस कीबोर्ड शॉर्टकट वाला menubar दिखाना चाहता हूँ, समझ नहीं आता कि ऐसा कोई menubar VM क्यों नहीं है जो हर OS पर menubar तक पहुँच दे
Electron के साथ पूरा ब्राउज़र भेजना मूर्खतापूर्ण है। सही मॉडल यह होना चाहिए कि यूज़र Flash के desktop app version जैसी कोई platform चीज़ इंस्टॉल करे, और सारे ऐप उसी का इस्तेमाल करें
हो सकता है DOS गेम डिस्ट्रीब्यूट करना desktop app से आसान हो। क्योंकि जिसे DOS गेम चलाना होगा, उसके पास DOS emulator पहले से इंस्टॉल होगा
ज़रूरत ऐसी framework की है जो इस्तेमाल में आसान हो, cross-platform हो, open source हो, और संभव हो तो चुनी हुई programming language से इस्तेमाल की जा सके
बड़ी समस्या workforce की है। web development जानने वाले लोग बहुत हैं, इसलिए desktop पर भी वही लोग काम करें यह चाहत होती है, और अगर desktop JavaScript वाला Electron हो तो यह बहुत आसान हो जाता है
टर्मिनल UI को GUI जैसी सुविधाएँ दोबारा बनाते देखना मुझे समझ नहीं आता। क्या कंप्यूटर इंटरफ़ेस को बेहतर नहीं होना चाहिए
अब सिर्फ़ लाइनें और आकृतियाँ बनाने का दिखावा करने के लिए character grid में सीमित रहने की ज़रूरत नहीं है। Kitty या iTerm जैसे non-standard terminal के बिना image display तक नहीं हो सकता
अफ़सोस यह है कि कोई शानदार cross-platform streaming UI system नहीं है। web अपने तरीके से काफ़ी अच्छा है, लेकिन इस काम के लिए निश्चित रूप से उससे बेहतर कुछ हो सकता है। Flutter ठीक है, लेकिन उसमें on-demand nature की कमी है और वह Dart से बहुत बँधा है
लोग GUI चाहते हैं, लेकिन अंत में TUI के भीतर GUI जैसी चीज़ से काम चलाना पड़ता है
उन्हें कुछ ऐसा चाहिए जो portable हो, remote run हो सके, socket expose किए बिना ज़्यादा सुरक्षित तरीके से चल सके, और जिसके लिए पूरा desktop environment उठाना न पड़े
rootless window लगभग मर चुका है, और अब या तो web interface बचे हैं उनके सारे झंझटों के साथ, या TUI है जिसके लिए बस SSH कनेक्शन चाहिए जो सबके पास पहले से है
पहले Tcl/Tk में कुछ जुगाड़ कर के X Window पर विंडो खोल लेना काफ़ी था, लेकिन आज यह आसान नहीं है, और remote X इस्तेमाल करने वाला भी कोई नहीं है
सबसे छोटा साझा हर SSH है, और वही चीज़ें बचती हैं जो उसके हिसाब से ढल सकें
जिन कई terminals का ज़िक्र support न होने के रूप में हुआ, वे भी GNOME VTE आधारित हैं, और वहाँ support पर काम चल रहा है; bug tracker देखें तो लगता है लगभग पूरा हो चुका है
X11 पर सबसे standard terminal के सबसे क़रीब xterm भी इसमें शामिल है
[0] https://www.arewesixelyet.com/
कोई ठोस और भरोसेमंद GUI toolkit भी नहीं है; सब अलग-अलग bugs और caveats से भरे हैं
Flutter को ठीक कहा जाता है, लेकिन यह नज़रअंदाज़ करना पड़ता है कि Flutter से ऐप build करने की प्रक्रिया अपने-आप में एक दुःस्वप्न है। Flutter भी ऐसा नहीं लगता कि उसे किसी के भी compile करने के लिए डिज़ाइन किया गया हो; असल में distro बस उस समस्या को छिपा देता है
और web-based UI का भारी होना ज़रूरी भी नहीं है। जैसे HN भारी नहीं है
मैं हमेशा terminal खुला रखता हूँ, Bash scripts से अपनी ज़िंदगी automate करता हूँ, और VIM/TMUX इस्तेमाल करता हूँ, फिर भी ज़्यादातर TUI किसी अच्छे GUI से दो क़दम पीछे हैं
मनमाना navigation और shortcuts, टूटी-फूटी copy-paste, और environment integration की कमी इसके प्रमुख उदाहरण हैं
असली समस्या यह है कि कोई ढंग का cross-platform GUI platform नहीं है जो या तो programming languages में ठीक से integrated हो या standard library का हिस्सा हो
Swing में native browser elements तक पहुँच की कमी है, Tk में browser components और drag-and-drop की कमी है, wxWidgets की community छोटी है और उसके bindings को भी शायद एक से ज़्यादा बार पुनर्जीवित करना पड़ा है
Qt किसी भी समय ज़्यादा पैसे कमाने के लिए चीज़ें बिगाड़ सकता है, मुझे KDE इतना महत्वपूर्ण भी नहीं लगता, और यह भी संदेह है कि KDE community लंबे समय में fork संभाल पाएगी या नहीं
आख़िर में Electron या browser component पर JavaScript/CSS चढ़ाकर local server callbacks जोड़ने वाले विकल्प बचते हैं; मामूली ऐप्स के लिए memory और runtime overhead तो छोड़ ही दें, programming model खुद ही ख़राब है
एक सचमुच अच्छे cross-platform GUI toolkit के लिए usability, accessibility, design, documentation, testing—सबमें बहुत पैसा और लोग चाहिए। open source community यह कर नहीं पाई, GTK व्यवहार में Linux-only बन गया, और Qt या Swing की जगह लेने वाला कोई आधुनिक दावेदार भी नहीं है
TUI मूल समस्या का समाधान नहीं है, लेकिन दूसरे विकल्पों को देखकर cross-platform UI के लिए TUI चुनने वाले developers समझ में आते हैं। GUI की लगभग 80% ज़रूरतें शायद ऐसे GUI toolkit से भी पूरी हो सकती हैं जिसमें TUI renderer हो
तभी स्थिर API और ABI दिया जा सकता है, और कई दूसरी भाषाओं से बिना जटिल workaround के bindings बनाए जा सकते हैं। compiled languages में यह और भी ज़रूरी है
Qt को Python में bind करना आसान हो सकता है, लेकिन Free Pascal जैसी language में जोड़ने के लिए C API expose करने वाली एक मध्यवर्ती C++ library चाहिए, और ऐप को वह library भी साथ भेजनी पड़ती है
दुर्भाग्य से ज़्यादातर GUI toolkits C में नहीं बल्कि C++ या दूसरी भाषाओं में लिखे गए हैं, जिससे अगर वह developer की पसंदीदा language न हो तो उनका इस्तेमाल कष्टदायक हो जाता है। mainstream में C में लिखा हुआ लगभग अकेला उदाहरण GTK है, और GTK backward compatibility की लगभग परवाह ही नहीं करता
आप सोच सकते हैं कि library किसी भी language में लिखी हो, बस C API expose करे, लेकिन अगर वह व्यापक रूप से वितरित न हो तो आप static linking चाह सकते हैं। और C/C++ के बाहर यह समस्या बन जाता है
उदाहरण के लिए, मैंने Lazarus के लिए FLTK backend बनाने की कोशिश की थी[0]। FLTK एक C++ library है और static linking को प्रोत्साहित करती है, इसलिए लगा था कि standalone GUI binary बनाई जा सकेगी
लेकिन पहले C wrapper बनाना पड़ा, और Linux पर g++ द्वारा linker को दिए जाने वाले जादुई flags के बिना C++ library को गैर-C/C++ भाषा से static link करना बेहद पीड़ादायक था; Windows या कम-से-कम msys2 पर तो यह संभव ही नहीं था, इसलिए छोड़ना पड़ा
[0] https://i.imgur.com/W6XbLkr.png
macOS और Windows पर यह native look के बहुत क़रीब पहुँच जाता है, और Qt की तुलना में प्रोग्राम करना भी बहुत आसान है। एक user के रूप में और कभी-कभी programmer के रूप में भी, multi-platform GUI के लिए मेरी सबसे पसंदीदा चीज़ wxWidgets ही है
इसके उलट Electron या browser component के साथ JavaScript/CSS और local server callbacks का संयोजन मुझे user के तौर पर सच में नापसंद है। भले मुझे functionality छोड़कर command line पर लौटना पड़े, फिर भी ऐसे ऐप्स से बचना चाहूँगा
ये standard keyboard shortcuts भी support नहीं करते, दिखते भी अटपटे हैं, और अनपेक्षित जगहों पर अटकते हैं
कुछ TUI frameworks तो लगभग उस स्तर तक पहुँच चुके हैं। SSH वगैरह पर बिना ख़ास मेहनत के इस्तेमाल हो जाना अच्छी बात है, लेकिन लगता है कि वे ग़लत समस्या हल कर रहे हैं
हर चीज़ को IDE जैसा दिखाने या चलाने के बजाय, मैं कमज़ोर window management और persistence वाले tmux जैसी चीज़ के साथ ज़्यादा केंद्रित और composable CLI पसंद करूँगा
अगर आप readline वाला साधारण REPL बना लें तो standard और predictable behavior मिल सकता है
फिर भी इस ट्रेंड की एक बात अच्छी लगती है: यह terminal emulator improvements को आगे बढ़ा रहा है
जिन TUI को मैंने देखा है, वे ज़्यादातर NPM dependencies पर टिके लगते हैं
यह अजीब है, मानो agents के पास security tire fire के अलावा कुछ और बनकर खुद को फिर से लिखने का भी समय नहीं है
agents सब कुछ अपने क़ब्ज़े में ले लेंगे वाला यह पूरा ट्रेंड आख़िरकार मुझे ऐसा लगता है कि इसे ऐसे garbage-in-garbage-out startup लोग चला रहे हैं जिन्हें बस इतना डर है कि वे काफ़ी तेज़ नहीं हैं
उदाहरण के लिए OpenCode आज तक यह बेसिक चीज़ ठीक से नहीं कर पाया कि हर message log बनाए रखे और वही logs उसी क्रम में SSE endpoint पर भेजे ताकि अगला response मिले, और context pruning बंद होने पर भी prompt cache miss अक्सर होते रहते हैं
developer experience भी शानदार है और npm की ज़रूरत नहीं पड़ती
curl | bashवाले शांतिपूर्ण security दिनों, वापस आओयह अपने-आप में अजीब है कि software developers को user interface डिज़ाइन करने दिया जाता है
लगता है वे non-text user interface बनाने में सक्षम ही नहीं हैं। जैसे अगर plumber से घर डिज़ाइन करवाओ तो वह शायद हर फ़र्श को नीचे की ओर ढलवा दे ताकि पाइपिंग आसानी से निकल सके
अगर कई windows को move और resize करना है तो वे text windows बना देते हैं, अगर जल्दी options चुनने हैं तो text boxes बना देते हैं, और अगर style तथा formatting वाले documents जल्दी लिखने हैं तो formatting के लिए और ज़्यादा text लिखवाते हैं
लेकिन उस text को formatted रूप में आसानी से देखने वाला ऐप वे बनाते ही नहीं
यह करने की छूट है, और अगर पसंद न हो तो इस्तेमाल मत करो
देखने में सुंदर हैं, लेकिन app-style development या file manager से जटिल कामों में वे लगभग बेकार हैं
जो लोग terminal के भीतर रहते हैं, उनके लिए TUI अच्छा है
visual content से ध्यान नहीं भटकता, keyboard से बहुत दक्षता मिलती है, और अब AI इसे तेज़ी से बना भी सकता है। पहले यह सचमुच कष्टदायक था
TUI का दर्शक वर्ग बढ़ा है, इसलिए TUI भी ज़्यादा आम हो गया है
80-column text के भीतर product manager के पास simplification के नाम पर बिगाड़ने के लिए भी बहुत कम गुंजाइश होती है
क्या यह गलत नहीं है कि ऐसी स्थिति में कोई भी big tech ब्राउज़र को छोड़ नहीं रहा है?
Lobste.rs की रायें
अच्छा होता अगर लोग native apps ही बनाते। TUI मुझे command-line interface और असली GUI — दोनों की कमियों का मिला-जुला रूप लगता है
हर TUI प्रोग्राम को scrolling खुद दोबारा implement करनी पड़ती है, इसलिए terminal pixel-level scrolling support करता हो तब भी TUI programs अक्सर सिर्फ line-by-line scrolling देते हैं, और उनका व्यवहार भी अलग-अलग होता है। senpai का scrollback मेरे बाकी programs से अलग चलता है, इसलिए मैं बार-बार गड़बड़ा जाता हूँ
Terminal को यह बताने का कोई तरीका भी नहीं होता कि interface सिर्फ एक text panel से ज़्यादा है, इसलिए text selection अक्सर टूट जाती है। Mouse events को hijack करके यह किया जा सकता है, लेकिन वह भी अपने आप में खास अच्छा नहीं है। एक TUI IRC client में text select करने के लिए मुझे बाएँ-दाएँ के बेकार panels छिपाने वाला shortcut दबाना पड़ता था, और यह काफ़ी बेवकूफ़ी भरी प्रक्रिया थी
Grid के हिसाब से चलने की बाध्यता layout और design की संभावनाओं को बहुत सीमित कर देती है। जैसे clickable buttons जैसा styling, या context menu जैसी चीज़ें। मैंने पहले भी इस समस्या पर शिकायत की थी
मुझे लगता है TUI का बढ़ना इस दुखद स्थिति का नतीजा है कि पारंपरिक GUI frameworks की हालत अच्छी नहीं है। TUI frameworks तुलनात्मक रूप से स्थिर हैं, और बहुत पुराने वाले भी इस्तेमाल करो तो ज़्यादा खटकते नहीं। ncurses programs आज भी अक्सर इस्तेमाल होते हैं, लेकिन Motif programs इस्तेमाल होते हुए कल्पना करना मुश्किल है
दूसरी ओर GUI frameworks के विकल्प ज़्यादा नहीं हैं और उन्हें maintain भी कहीं अधिक करना पड़ता है। Desktop environments बदलते रहते हैं, और GUI से लोगों की अपेक्षाएँ भी बढ़ती रहती हैं। TUI accessibility मुझे सच में बहुत खराब लगती है, हालाँकि मैं पूरे यक़ीन से नहीं कह सकता। बदलाव भी इतने आते रहते हैं कि GTK2 में बनाया तो deprecated, GTK3 पर गए तो अब GTK4 पर जाओ — ऐसा सिलसिला चलता रहता है
थोड़ा निंदक होकर देखें तो Omarchy जैसी चीज़ों के पीछे और भी कारण हैं। साधारण GUI xfce4-taskmanager उबाऊ दिखता है, लेकिन TUI btop बहुत hacker-जैसा दिखता है। लोगों को terminal aesthetics पसंद हैं (/r/unixporn देखें), और वे vibe के लिए usability की क़ुर्बानी देने को भी तैयार लगते हैं। btop सचमुच process list को fade out करता है, यह देखकर यही लगता है
मुझे उम्मीद थी कि अब तक entry barrier कम हो चुका होगा। जब ज़्यादातर developers high-level languages में प्रशिक्षित होते हैं, तब यह ज़्यादा समझदारी भरा नहीं लगता, और शायद C++ की complexity ही मुझे डरा देती है
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix client Nheko तो एक बार में एक से ज़्यादा line select भी नहीं करने देता
जबकि IRC clients by default यह रूप देते हैं
20:41 <username1> message1
20:42 <username2> message2
कभी-कभी ये ठीक लगते हैं, लेकिन आदर्श रूप से इन्हें छोटे, थोड़ी देर के लिए इस्तेमाल होने वाले apps या text editing जैसी exceptions तक सीमित रहना चाहिए
जैसे lf, tig, kakoune shell scripts के साथ अच्छी तरह मेल खाते हैं, इसलिए वही scripts दोबारा इस्तेमाल की जा सकती हैं और तीनों apps में features बढ़ाए जा सकते हैं। ये तीनों alacritty में चलते हैं, इसलिए मैं ऐसे hyperlinks भी बना सकता हूँ जो इन तीनों apps और पूरे shell environment में काम करें
अगर सपने देखूँ, तो मैं ऐसी monochrome minimalist GUI toolkit चाहूँगा जो Emacs या acme-style integration की अनुमति दे
मुझे समझ नहीं आता कि TUI को “automation-friendly” कैसे कहा जा रहा है। क्या यह बस console में दिखने वाला GUI नहीं है?
इस लेख ने TUI के “वापस आने” की सबसे अहम वजह छोड़ दी। खुद यह दावा भी संदिग्ध है, लेकिन Claude जैसे coding agents के ज़रिए बड़े पैमाने पर vibe coding होने से हाल में इसकी लोकप्रियता बढ़ी है, यह सही लगता है
Developers आसान रास्ता पसंद करते हैं। cross-platform TUI बनाना GUI बनाने से आसान है
Web apps के लोकप्रिय होने की वजह भी यही थी। Browser tools से cross-platform apps बनाना आसान था, और Electron के उभरने के पीछे भी लगभग यही कारण था, बस cross-browser support का बोझ हट गया। Responsive UI बनाना, UI को cross-platform तरीके से render करना, और user input को, खासकर accessibility को ध्यान में रखकर, संभालना — ये सब मुश्किल काम हैं। इसलिए developers तुरंत ऐसी किसी चीज़ पर कूद पड़ते हैं जो यह आसान बना दे
हाल में TUI बनाना आसान करने वाले कुछ बदलाव भी आए हैं। Advanced features के cross-platform support में सुधार हुआ है, और ऐसी लोकप्रिय libraries आई हैं जो जटिल बारीकियों को abstract कर देती हैं। शायद इन्हीं चीज़ों ने हाल की TUI renaissance को जन्म दिया है
इसके अलावा लेख के कुछ तर्क संदिग्ध लगते हैं। उदाहरण के लिए लेखक Electron apps की कमी के रूप में consistency का ज़िक्र करता है, लेकिन लोकप्रिय TUI में भी conventions को छोड़ दें तो consistency लगभग नहीं के बराबर है। Coding agents ने मिलते-जुलते shortcuts अपनाए हैं, पर ज़्यादातर ने एक ही स्रोत Claude की नकल की है। वे shortcuts coding agents के बाहर ज़्यादा काम नहीं आते, और जिन अधिकांश TUI का मैं इस्तेमाल करता हूँ, उनके shortcuts और visual language काफ़ी अलग हैं
“UI को cross-platform तरीके से render करना मुश्किल है” यह भी कुछ अजीब लगता है। Compatibility layer चाहिए और जितने platforms हों उतने implementations भी, लेकिन single-platform support से यह इतना ज़्यादा मुश्किल नहीं लगता। हाँ, अगर target platforms की rendering styles इतनी अलग हों कि common API बनाना कठिन हो, तो बात अलग है, लेकिन screen पर pixels डालने के स्तर पर ऐसा नहीं होना चाहिए। Scaling जैसी चीज़ें संभालनी पड़ेंगी, लेकिन उसके आगे यह काफ़ी सीधा होना चाहिए, और नहीं तो SDL है ही
शायद आपका मतलब हर platform पर UI को “native जैसा दिखाना” था। उसके लिए हर platform की पसंदीदा native GUI toolkit इस्तेमाल करनी पड़ सकती है, और वे न सिर्फ़ बहुत अलग हैं बल्कि low-level rendering API की तुलना में कहीं बड़ी और कम स्थिर भी हो सकती हैं। उसके लिए ज़िंदगी बहुत छोटी है। मैं रंग theme या graphic style के कुछ हिस्से बदलने की गुंजाइश दूँगा, लेकिन उसे app-level setting ही रखूँगा। हर OS की graphics settings पढ़ने में समय बर्बाद नहीं करना चाहता
“User input, खासकर accessibility को संभालना मुश्किल है” यह भी अजीब लगता है। Keyboard और mouse events सुनना बहुत मामूली काम है। Accessibility के लिहाज़ से सही keyboard navigation ज़रूरी है, और overall usability के लिए भी महत्त्वपूर्ण है; standard और custom shortcuts का support भी चाहिए, लेकिन कुल मिलाकर यह बाकी सब चीज़ों से कहीं आसान लगता है
Screen reader support संबंधित platform API और platforms के बीच differences के कारण मुश्किल हो सकता है, लेकिन वह input से ज़्यादा rendering की समस्या के करीब है
TUI का “comeback” कम और native GUI programming knowledge खो देने के बाद उपलब्ध tools से काम चलाने जैसा ज़्यादा है। यह लगातार development और investment की कमी का नतीजा है
Qt जैसी कुछ चमकीली exceptions को छोड़ दें तो UI civilization ढह चुकी है और हम किसी post-apocalyptic दौर में जी रहे हैं
यह Preventing the Collapse of Civilization वाली talk के साथ तुक मिलाता सा लगता है, और अब जब AI बहुत-सा code लिख रहा है, तो डर है कि यह knowledge collapse और न फैल जाए
लगता है जैसे computer science की दुनिया को After Virtue जैसी किसी चीज़ की ज़रूरत है, और शायद Blow की online मौजूदगी थोड़ा-बहुत वही भूमिका निभा रही है। खैर, मुझे वह दौर याद आता है जब computer interfaces consistency दिखाते थे, user का सम्मान करते थे, और सीखने व मेहनत का इनाम देते थे
इस लेख में ठोस बात बहुत कम है; बस इतना लगता है कि लेखक को बाकी सब कुछ बेकार लगता है
अगर एक बात कहनी हो, तो Emacs text, keyboard, buttons, और rich media interfaces के लिए एक शानदार platform है
शायद इसलिए कि लोग Go, Rust, और अब Zig में ncurses की जगह TUI libraries इस्तेमाल करने लगे हैं। फिर भी उन्होंने उन भयानक portability problems को हल कर दिया जिनके कारण ncurses की ज़रूरत पड़ती थी
उसके बाद लोगों ने नए terminals बनाना शुरू किया और उस तरफ़ की technology को भी आगे बढ़ाया। आंशिक कारण यह है कि अब यह सब C की जगह Go, Rust, Zig में बनाया जा सकता है
जब आप C और C++ से ज़्यादा मज़ेदार और कम परेशान करने वाले अच्छे विकल्प देते हैं, तो लोग स्वाभाविक रूप से नया और उपयोगी code लिखना शुरू कर देते हैं
TUI के वापस आने की असली वजह यह है कि 2026 में signed और notarized GUI distribute करने के लिए Apple को पैसे देने पड़ते हैं, और Windows के लिए certificate authority को भी पैसे देने पड़ते हैं
एक छोटी technical correction: Zed की GPU-accelerated UI library cross-platform API wgpu नहीं, बल्कि gpui है
पक्का नहीं कि लेख ने अपनी बात ठीक से साबित की या नहीं, लेकिन MS-DOS era से गुज़रा हूँ और हमेशा TUI पसंद रहा है, इसलिए मैं भी कुछ कहूँगा। अगर आपने afl-fuzz इस्तेमाल किया है, तो शायद समझेंगे
सिद्धांततः Linux पर TUI को कहीं ज़्यादा सफल होना चाहिए था। वहाँ text-based aesthetics पसंद करने वाला technical user base था, और खुरदरे, inconsistent GUI environments का “फ़ायदा” भी था। वह समय भी था जब video card को X server में सही तरह चलाना ही एक समस्या होता था
साथ ही, दशकों तक *nix software developers खुद को इस बात के लिए बाध्य महसूस करते रहे कि उन्हें पुराने और विचित्र terminal types तक support देना है। अगर application DECwriter पर ठीक से render न हो तो मानो कोई आपदा आ जाएगी — ऐसी मानसिकता थी, और उन constraints के भीतर अच्छा TUI बनाना मुश्किल था
MS-DOS के दौर में Microsoft, Borland, Norton जैसी कंपनियों ने functional और responsive text-based interfaces को काफ़ी निखार लिया था। Linux में लंबे समय तक TUI design की “चोटी” menuconfig जैसा एक राक्षसी example था, और अगर बहुत आँखें मिचमिचाएँ तो vim को भी TUI कह सकते हैं। जब लोग सचमुच text-mode console इस्तेमाल करते थे, उस दौर का मुझे याद रहने वाला अच्छा Linux TUI शायद सिर्फ़ Norton Commander से प्रेरित file manager Midnight Commander है