เหตุผลที่ TUI กลับมาอีกครั้ง

(wiki.alcidesfonseca.com)

6 คะแนน โดย GN⁺ 2026-05-04 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

TUI กำลังกลับมาได้รับความสนใจอีกครั้ง เพราะให้ฟีดแบ็กได้ทันที ทำงานอัตโนมัติได้ง่าย และใช้งานข้ามระบบปฏิบัติการได้ โดยเครื่องมืออย่าง Claude และ Codex ก็ประสบความสำเร็จอย่างมากบนบรรทัดคำสั่ง
Native GUI บน Windows, Linux และ macOS กลับสร้างภาระเพิ่มให้ทั้งนักพัฒนาและผู้ใช้ จากยุทธศาสตร์ API ที่ไร้เสถียรภาพ การกระจายตัวของทูลคิตและสภาพแวดล้อม ไปจนถึงความสอดคล้องกับแนวทางเดิมที่อ่อนลง
แอป Electron มีปัญหาที่ใหญ่กว่าการใช้หน่วยความจำ คือความไม่สม่ำเสมอด้านภาพลักษณ์และช่องโหว่ในเวิร์กโฟลว์ที่เน้นคีย์บอร์ด รวมถึงการผสานเมนูและคีย์ลัดที่อ่อนลง
แม้จะมีความพยายามสร้าง UI stack ใหม่อย่าง Flutter UI ของ Google และ GPUI ของ Zed แต่ถ้าผสานกับระบบปฏิบัติการได้ไม่ดี แค่มี renderer ที่เร็วก็ยังไม่เพียงพอ
อินเทอร์เฟซที่ดีมีหัวใจสำคัญอยู่ที่ ความสม่ำเสมอ ซึ่งช่วยให้ผู้ใช้คิดน้อยลง และทั้งนักพัฒนา รวมถึงผู้สร้างระบบปฏิบัติการและทูลคิต ควรลงทุนกับทฤษฎี UI และทูลคิตที่เข้าถึงง่ายมากขึ้น

เบื้องหลังที่ทำให้ TUI กลับมาได้รับความสนใจ

Omarchy ของ DHH เป็นองค์ประกอบผสมระหว่าง TUI, เว็บแอป และแอปเนทีฟสไตล์ gnome โดย TUI ถูกใช้เพื่อฟีดแบ็กที่ตอบสนองทันทีและ “geek points”
ราว 10 ปีก่อนก็มีแนวโน้มคล้ายกันในโลกของโปรแกรมแก้ไขโค้ด
- มีการย้ายจากโปรแกรมแก้ไขแบบเนทีฟอย่าง BBEdit, Textmate, Notepad++, Sublime ไปยังแอปบน Electron อย่าง Atom, VSCode และแอปสายต่อยอดต่าง ๆ
- ผู้ใช้ที่มีความชอบชัดเจนจำนวนหนึ่งหันไปใช้ vim หรือ emacs เพื่อแลกกับฟีดแบ็กทันทีและการใช้งานระดับสูง แม้ต้องยอมรับเส้นโค้งการเรียนรู้ที่ชันมาก

ทำไม Native GUI ถึงอ่อนแรงลง

Windows
- Windows ไม่สามารถสร้างยุทธศาสตร์ไลบรารี GUI ที่สม่ำเสมอได้ และเมื่อ API หนึ่งไม่สำเร็จ ก็จะวนไปสร้าง API ตัวใหม่อีกครั้ง
- Jeffrey Snover เขียนใน Microsoft hasn’t had a coherent GUI strategy since Petzold ว่า MFC, OLE, COM และ ActiveX ได้กระจายความซับซ้อนไปทั่วการพัฒนาบน Windows
- หลังจากนั้น Microsoft ก็ผ่านทั้ง WinForms, WPF, Silverlight, WinUI และ MAUI แต่ก็ยังไม่ประสบความสำเร็จ และแอปเดสก์ท็อปทั้งฝั่งองค์กรและผู้ใช้ทั่วไปจำนวนมากยังคงพึ่งพา Electron
- ช่วงสุดท้ายที่ Windows ทั้งระบบมีความกลมกลืนด้านภาพอย่างแท้จริง น่าจะใกล้เคียงกับยุค Windows 98 หรือ Windows 2000
- Domenic Denicola มองใน Windows Native App Development Is a Mess ว่าค่าใช้จ่ายจากการสร้าง OS และ UI API ใหม่ทุก ๆ ไม่กี่ปีนั้นสูงมาก และเมื่อรวมกับการทำ sandboxing และการพยายามเลิกใช้ฟีเจอร์เดิม แต่ละชั้นใหม่จึงเกิดช่องว่างที่ทำสิ่งซึ่งเฟรมเวิร์กก่อนหน้าทำได้ไม่ครบ
โฆษณา
Linux
- ความไม่สอดคล้องของ UI บน Linux เป็นผลลัพธ์ที่แทบจะเกิดจากการออกแบบตั้งต้น เพราะทีมที่ต่างกันมีอิสระในการไล่ตามเป้าหมายที่ต่างกัน
- GTK และ Qt กลายเป็นเฟรมเวิร์กหลัก และทั้งคู่ต่างมุ่งสู่การพัฒนาแบบเนทีฟข้ามแพลตฟอร์ม แต่พื้นที่ที่ถูกใช้อย่างแพร่หลายจริงยังคงอยู่บน Linux เป็นหลัก
- แอป Linux ที่สร้างจากทูลคิตต่างกัน เมื่อนำมาวางข้างกันก็ยังดูเข้ากันได้ในระดับหนึ่ง แต่เฟรมเวิร์กหลายชุดบน Windows กลับไม่สามารถให้ความกลมกลืนได้ถึงระดับนั้น
- เนื่องจากมีชุดผสมของดิสทริบิวชัน เดสก์ท็อปเอนวायरอนเมนต์ และฮาร์ดแวร์มากเกินไปจนทดสอบได้ยาก บริษัทจำนวนมากจึงไม่สร้างแอป Linux แบบเนทีฟ
- โดยทั่วไปบริษัทมักรองรับ Linux ผ่าน Electron หรือไม่ก็ปล่อยให้ชุมชนโอเพนซอร์ซจัดการเอง หากมี API แบบเปิดให้ใช้งาน
macOS
- Human Interface Guidelines ของ Apple เคยเป็นมาตรฐานที่แข็งแกร่งถึงขั้นถูกอ้างอิงในชั้นเรียนด้านส่วนติดต่อผู้ใช้ทั่วโลก
- Xerox PARC และ Apple มักถูกยกให้เป็นสองสถาบันตัวอย่างที่ศึกษาว่า human interface ที่ดีควรเป็นอย่างไร
- แต่ระยะหลัง Apple กำลังขยับไปในทิศทางที่ทำลายความสอดคล้องกับแนวทางเดิมของตนเอง
- macOS กำลัง เมินกฎของ Fitts, ทำให้การปรับขนาดหน้าต่างแทบเป็นไปไม่ได้, และปัญหายังคงต่อเนื่องแม้พยายามแก้แล้ว, รวมถึง เพิ่มไอคอนให้ทุกเมนู
- จึงยากขึ้นเรื่อย ๆ ที่จะมอง macOS ว่าเป็นพื้นที่ปลอดภัยที่นักออกแบบยังสามารถทำงานได้อย่างสงบ

ข้อจำกัดของแอป Electron

ปัญหาที่ถูกพูดถึงมากที่สุดคือ การใช้หน่วยความจำ แต่ตลอด 10 ปีที่ผ่านมา การใช้หน่วยความจำกลับมีแนวโน้มลดลง
ปัญหาที่ใหญ่กว่าคือ ความไม่สม่ำเสมอด้านภาพลักษณ์ และการขาดเวิร์กโฟลว์ที่เน้นคีย์บอร์ด
แม้ในสภาพแวดล้อมที่ใช้ MacBook Pro RAM 64GB ก็ยังมีทั้งแอปเนทีฟ 8 ตัวและแอป Electron 6 ตัวอยู่บน Dock พร้อมกัน
- แอปเนทีฟ: TextMate และยูทิลิตีระบบของ macOS
- แอป Electron: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
ในแอปอย่าง Cursor และ VSCode เมื่อขอฟีเจอร์จาก agent panel แล้ว การย้ายไปยังรายการเอเจนต์ใน side panel หรือการเก็บรายการด้วยคีย์บอร์ดอย่างเดียว ยังไม่เป็นธรรมชาติ
พฤติกรรมแบบนี้ควรทำได้ด้วยวิธีเดียวกันในทุกแอปบน macOS แต่ในความเป็นจริง ต่อให้มีคีย์ลัด บางครั้งก็ไม่ถูกแสดงไว้ในเมนู
ตลอด 10 ปีที่ผ่านมา นักพัฒนามีแนวโน้มลืมเพิ่มการกระทำที่ทำได้ในแอปเข้าไปในเมนูด้วย และเรื่องนี้เชื่อมโยงกับโครงสร้างที่แอปถูกสร้างเป็น HTML ภายใน sandbox
Slack จัดการประเด็นเหล่านี้ได้ดีกว่าแอป Electron ตัวอื่น ๆ แต่ก็ยังไม่สมบูรณ์

ความพยายามสร้าง UI stack ใหม่อีกครั้ง

Google เคยต้องการสร้างทูลคิต UI สำหรับระบบปฏิบัติการและอุปกรณ์แบบใหม่ ที่ไม่มีมรดกตกค้างจาก Android พร้อมกับ Dart
Google ต้องการทูลคิตใหม่ชื่อ Flutter UI แต่ก็ยกเลิกโครงการนี้ก่อนที่ผลิตภัณฑ์จริงจะออกสู่ตลาด
ความพยายามลักษณะนี้จะสำเร็จได้ มักต้องอาศัยสถานะกึ่งผูกขาดหรือส่วนแบ่งตลาดที่ใหญ่พอ
Zed เลือกแนวทางคล้ายกันด้วย Rust โดยสร้างไลบรารี renderer บน GPU ของตัวเองชื่อ GPUI ซึ่งมุ่งสู่การใช้งานข้ามแพลตฟอร์ม
GPUI แม้จะเร็ว แต่ก็ยังผสานกับระบบปฏิบัติการเจ้าบ้านได้ไม่ดีพอในตัวเอง ทำให้นักพัฒนาต้องเพิ่ม binding ที่ต้องใช้ด้วยตนเอง
renderer ที่ช้ากว่าแต่ผสานกับระบบปฏิบัติการได้ดี ยังดีกว่า renderer ที่เร็วแต่เชื่อมต่อได้ไม่แนบแน่น

ช่องว่างที่ TUI เข้ามาเติม

ในบริบทที่ชวนให้นึกถึงการเสื่อมถอยของ Apple Automator, TUI จึงกลับมามีความสำคัญอีกครั้งในฐานะอินเทอร์เฟซที่ทำงานอัตโนมัติได้
TUI ยังรันจากระยะไกลได้ค่อนข้างง่าย และไม่ต้องพึ่ง X forwarding ที่ชวนปวดหัว
เมื่อ native UI toolkit ล้มเหลว สิ่งที่เกิดขึ้นคือผู้คนย้อนกลับไปหาพื้นฐาน และผลลัพธ์ก็คือ TUI กลายเป็นตัวเลือกที่โดดเด่น
Claude และ Codex ประสบความสำเร็จอย่างมากบนบรรทัดคำสั่ง และผู้ใช้ก็สามารถโฟกัสกับตัวปฏิสัมพันธ์ได้โดยไม่ต้องกังวลกับระบบปฏิบัติการรอบข้าง
ผ่าน TUI ผู้ใช้สามารถจัดการโค้ดและแอปบนเครื่องคลาวด์ หรือเชื่อมต่อจากระยะไกลจาก iPad ไปยังเครื่องที่มี GPU ก็ได้
TUI กำลังเข้ามาเติมช่องว่างที่ Apple และ Microsoft ทิ้งไว้ ในโลกที่ทุกแอปดูแตกต่างกันไปหมด
รูปลักษณ์ที่แตกต่างกันอาจเหมาะกับงานศิลปะหรือเกมคอมพิวเตอร์ แต่ไม่เหมาะกับเป้าหมายที่อินเทอร์เฟซควรถอยออกไปเพื่อให้ผู้ใช้ทำงานของตัวเองได้

ทิศทางที่จำเป็นต่อจากนี้

John Loeber เขียนใน Bring Back Idiomatic Design ว่าแม้แต่ checkbox ก็เป็นอินเทอร์เฟซสำหรับโต้ตอบกับระบบ และอินเทอร์เฟซที่ดีคือสิ่งที่ทำให้ผู้ใช้คิดน้อยลง
ผู้ใช้ต้องโต้ตอบกับหลายสิ่งหลายอย่าง จึงจำเป็นต้องมีอินเทอร์เฟซที่เป็นเนื้อเดียวกันและมอบประสบการณ์ที่สม่ำเสมอ
ถ้า Command+C คือคีย์ลัดสำหรับคัดลอก มันก็ควรใช้ได้ทุกที่ การต้องจำแยกว่าบางสถานการณ์ต้องใช้ CTRL+Shift+C หรือคลิกขวา → คัดลอก ถือว่าไม่สะดวก
นักพัฒนาทุกคนควรเรียนรู้ทฤษฎีที่ทำให้ไม่ใช่แค่ซอฟต์แวร์ แต่รวมถึงส่วนติดต่อผู้ใช้โดยทั่วไปดีขึ้น
- Nielsen
- Norman
- Johnson
ต้องเลิกมองการออกแบบสำหรับผู้ใช้เหมือนเป็น soft skill ที่ไม่สำคัญในหลักสูตรวิศวกรรมซอฟต์แวร์
ไม่ว่าในกระบวนการใด หาก UI ยังไม่เป็นที่เข้าใจ โครงการนั้นก็ควรถูกมองว่าล้มเหลว และในรายวิชา HCI ก็ควรมุ่งเป้าไปที่ UI ที่สมบูรณ์แบบ
งานสร้าง UI ที่ดีนั้นใช้แรงส่วนใหญ่ไปกับการทำความเข้าใจความต้องการ ขณะที่ตัวการเขียนโปรแกรมเองกำลังถูกทำให้เป็นอัตโนมัติอยู่แล้ว
ผู้สร้างระบบปฏิบัติการและทูลคิตควรผลักดันการลงทุนเพื่อสร้างทูลคิตที่เข้าถึงง่าย ซึ่งนักพัฒนาอยากใช้ และลดอุปสรรคในการเริ่มต้น
ไม่ได้ยืนกรานว่าต้องรองรับข้ามแพลตฟอร์มเสมอไป แต่หากมีทางออกแบบนั้นอย่างน้อยสักหนึ่งอย่าง ก็อาจช่วยลดการพึ่งพา Electron และ TUI ได้

4 ความคิดเห็น

colus001 2026-05-04

ผมก็คิดแบบนั้นเหมือนกัน แต่รู้สึกว่าวงการนักพัฒนานั้นไวต่อกระแสมากเกินไป TUI ก็เป็นแค่สิ่งที่บริษัทที่ไม่มีความสามารถหรือความตั้งใจจะทำ GUI ให้ดีเป็นคนผลักดันอยู่เท่านั้น แต่ก็ไม่แน่ใจว่าจริง ๆ แล้วมีคนใช้ TUI กันมากแค่ไหน

GN⁺ 2026-05-05

ความคิดเห็นจาก Hacker News

ถ้าดูแค่ตัวเลข เหตุผลจริง ๆ ที่ TUI ได้รับความนิยมก็คือ Claude Code ส่วนที่เหลือนั้นแทบจะเป็นแค่เสียงรบกวนเมื่อเทียบกัน
สิ่งที่ทำให้เริ่มอยากสร้าง TUI ตั้งแต่แรกคือแนวคิดเรื่องการส่งแอปผ่าน SSH แอปบน SSH มีความคล้ายเบราว์เซอร์ตรงที่ไม่ต้องติดตั้งอะไรไว้ในเครื่องก่อน
อีกเหตุผลใหญ่ที่ผมสนุกกับการเล่น https://pico.sh ก็เพราะการแจกจ่าย TUI ไม่ต้องให้ผู้ใช้เข้ามายุ่งเลยแม้แต่นิดเดียว
- ผมว่าไม่ใช่อย่างนั้นนะ จุดที่โปรแกรม TUI ใหม่ ๆ เริ่มเพิ่มจำนวนขึ้น ดูจะมาก่อนที่ Claude Code จะดังจริงจังเสียอีก
- จริงอยู่ที่ Claude Code ขยายกระแสนี้แรงขึ้นสักร้อยเท่า แต่ TUI ก็เพิ่มขึ้นมากอยู่แล้วตั้งแต่ยุคของ go fzf, Rust ratatui, Python Rich
  น่าจะเป็นเพราะคนอยากหนีจาก UI บนเบราว์เซอร์ที่หนักอึ้ง และอยากลองทดสอบขีดจำกัดของการเรนเดอร์ในเทอร์มินัลด้วย
- ผมเข้าใจแนวคิดการแจกจ่ายแอปผ่าน SSH แต่น่าเสียดายที่อีมูเลเตอร์เครื่องพิมพ์ดีดพอร์ตอนุกรมยังอยู่มาถึงทุกวันนี้
  แทนที่จะสร้างระบบใหม่ด้วยเทคโนโลยีใหม่ที่น่าสนใจ เรากลับกำลังสร้าง อีมูเลเตอร์เครื่องพิมพ์ดีดที่เร่งด้วย GPU กันอยู่ มันเป็นอะไรที่แปลก ๆ ระหว่างความโหยหาอดีตกับความบอดทางเทคนิค
  บน SSH จะส่งโปรโตคอลอะไรก็ได้อยู่แล้ว ผมว่าไปทางวาดลงบนจอแสดงผลบิตแมประยะไกลน่าจะดีกว่า
  X Window แม้จะไม่ได้ออกแบบมาดีเยี่ยมนัก แต่ก็มีความโปร่งใสด้านเครือข่าย ส่วน devdraw ของ Plan 9 เป็นเอนจินเรนเดอร์ที่ให้โปรแกรมกราฟิกระยะไกลอัปโหลดทรัพยากรก่อน แล้วค่อยส่งคำสั่งวาดเส้นผ่าน RPC
- แรงจูงใจที่ยังทำให้อยากใช้แอป TUI แทน CLI ล้วน ๆ หรือ GUI ก็คือ มันใช้ผ่าน SSH ได้
- อยากรู้ว่าที่บอกว่า TUI ดังเพราะทุกคน พยายามเลียนแบบ Claude Code หมายถึงอย่างนั้นจริง ๆ หรือหมายถึงว่า Claude Code ทำให้การพัฒนา TUI ง่ายขึ้น
เรื่องที่ยากจริง ๆ ของ vim มีแค่ว่าต้องเอื้อมนิ้วไปถึง Escape เพื่อ กลับสู่โหมดคำสั่ง ซึ่งเป็นหัวใจของตัวแก้ไขแบบโหมด
เวิร์กโฟลว์ในอุดมคติคือแก้ไขได้ไวแล้วกลับสู่โหมดคำสั่งทันที ดังนั้นการใช้ Escape จึงเป็นเศษซากทางประวัติศาสตร์ที่ควรถูกชี้ให้เห็น
เพราะงั้นก็รีแมป CapsLock เป็น Escape ทั้งระบบไปเลย Linux กับ macOS ทำได้จากการตั้งค่า GUI อย่างเดียว ส่วน Windows ก็แค่สร้างหรือแก้ registry key ใช้เวลาไม่ถึงนาที
นอกนั้นก็เรียนพื้นฐานจาก vim-tutor แล้วค่อยค้นตอนเจองานที่ใช้เวลานาน ผมเลยไม่ค่อยเข้าใจว่า learning curve มันอยู่ตรงไหน ปัญหาคือเราจะชินกับการแก้ไขแบบโหมดเร็วเกินไป จนสภาพแวดล้อมที่ไม่มีมันดูเหมือนยุคหิน
- ถ้าต้องสลับใช้งานโน้ตบุ๊กหลายเครื่องบ่อย ๆ การ รีแมป CapsLock เป็น Escape กลายเป็นแรงเสียดทานพอสมควรเลย muscle memory จะคอยขัดตลอด
- ผมไม่เคยเห็นใครที่เปลี่ยน CapsLock เป็น Escape แล้วเปลี่ยนกลับเลย ความรู้สึกมันต่างกันมากจริง ๆ
  ทุกวันนี้ผมยังคิดว่าเหตุผลที่ vim ต้องมี hjkl จริง ๆ แล้วเป็นเพราะเลย์เอาต์คีย์บอร์ดห่วยกับปุ่มลูกศร เครื่องพิมพ์ดีดไม่มีปุ่มลูกศร แต่คอมพิวเตอร์มี และมันสำคัญมาก
  spacebar ก็ไม่จำเป็นต้องใหญ่ขนาดนั้น และก็ไม่มีเหตุผลที่ต้องให้ใช้ได้ทั้งสองนิ้วโป้ง ถ้าย้ายกลุ่มปุ่มลูกศรเล็ก ๆ ไปไว้ตรงด้านซ้ายหรือขวาของ spacebar บางส่วน น่าจะดีกว่ามาก
  การแฮ็กด้วย hjkl ใช้ได้แค่ในเอดิเตอร์สำหรับแฮ็กเกอร์ แต่ซอฟต์แวร์ทั่วไปก็ต้องใช้ปุ่มลูกศรเยอะเหมือนกัน และเลย์เอาต์ปัจจุบันไม่ดีกับมือเอามาก ๆ ผมเริ่มมีอาการอักเสบเพราะพยายามกดลูกศรด้วยนิ้วโป้งโดยไม่ยกมือทั้งมือ
- แปลกดีที่การวาง Esc ไว้ไกล ๆ ไม่ได้แย่เรื่องประสิทธิภาพ กลับชอบในเชิง สรีรศาสตร์
  มันบังคับให้ยกมือออกจากโฮมโพสิชันแล้วกลับมาวางใหม่ ช่วยลดแต้มสะสม RSI ที่ไม่อย่างนั้นจะก่อตัวขึ้นเรื่อย ๆ
  ด้วยเหตุผลเดียวกัน อีกมือหนึ่งผมก็ใช้ปุ่มลูกศรบ่อยเหมือนกัน แน่นอนว่า hjkl ก็ใช้เยอะพอควร
- ถ้าใช้ Windows, PowerToys มีเครื่องมือรีแมปคีย์บอร์ดที่ค่อนข้างดีมาให้
  https://github.com/microsoft/PowerToys
- นิ้วก็อยู่ที่โฮมโพสิชันอยู่แล้ว แค่แมปเป็น jj ก็จบ
  อีกอย่าง Ctrl + [ ในเทอร์มินัล/ASCII มาตรฐานก็คือ Esc เลยอาจสะดวกกว่าการเอื้อมไปกด Esc ด้วยซ้ำ
กระแส TUI ที่เห็นกันอาจเป็นเพียงกองขี้เถ้าที่เหลือหลังผลประโยชน์ส่วนตัวของผู้ขายระบบปฏิบัติการพังทลายลง
ไม่มี UI อเนกประสงค์ที่ดีเลยสักตัว อย่างมากที่สุดเบราว์เซอร์ก็ยังดีที่สุดและถือว่าประสบความสำเร็จมาก แต่เพราะ sandbox มันจึงไม่เหมาะหรือมีแรงเสียดทานสูงกับงานที่ต้องเข้าถึงไฟล์โลคัลหรือเครือข่าย แถมโอเวอร์เฮดสำหรับการรันอะไรง่าย ๆ ก็เกินเหตุสุด ๆ
การเข้าถึงระยะไกลยิ่งเละกว่าเดิม เช่น แอปที่รันอยู่บนโฮสต์ Windows จะเข้าจาก Mac ได้ไหม จะฟอร์เวิร์ดผ่าน tunnel connection ได้ไหม อะไรแบบนี้
TUI คือ โปรโตคอลอเนกประสงค์ แบบง่าย ๆ ที่ทำสิ่งที่ต้องการได้ และถูกออกแบบให้รองรับการใช้งานระยะไกลตั้งแต่ต้น สิ่งที่ใช้ในเครื่องโลคัลก็ทำงานบนการเชื่อมต่อ SSH ได้อย่างเป็นธรรมชาติ
มันยังเป็นการชูนิ้วกลางครั้งใหญ่ให้บรรดาผู้ขายระบบปฏิบัติการที่คิดว่ากลยุทธ์การทำให้ทุกอย่างเข้ากันไม่ได้หรือผูกคนไว้กับ ecosystem จะเป็นฝ่ายชนะ
- TUI เข้าใจง่ายสำหรับผู้ใช้ มีประสิทธิภาพทั้งด้านทรัพยากรและการใช้งาน และบนเทอร์มินัลที่ดีมันก็ดูดีด้วย
  Notcurses และ Ratatui ช่วย ncurses ไว้มาก
- เพราะสภาพแวดล้อม GUI สมัยใหม่ที่เหลวไหลล้มเหลว คนเลยต้องกลับมาหา เดสก์ท็อปแบบมินิมัล อย่าง xfce4 อยู่เรื่อย ๆ
  Windows 11 เป็นตัวอย่างที่ดีมาก และความเวอร์วังพวกนั้นก็ไม่จำเป็นเลยจริง ๆ
ผมหวังว่า TUI จะไม่กลับมา ไม่ว่าวันไหนผมก็เลือก เว็บอินเทอร์เฟซ มากกว่า TUI
ไม่ต้องติดตั้งฟอนต์ฉลาดเกินเหตุ ไม่ต้องไปจูนเทอร์มินัลให้แสดงผลถูกต้อง ไม่ต้องเดาว่าคนสร้างคิดว่าช็อตคัตนำทางไหนเจ๋งที่สุด
ยังได้การแก้ไขข้อความจริงที่ใช้การนำทางข้อความมาตรฐานของระบบปฏิบัติการ การผสานกับตัวจัดการรหัสผ่านและ text expander ที่ดีกว่าด้วย
ผมใช้ชีวิตอยู่ใน CLI และเปิดเทอร์มินัลได้ด้วยคีย์ลัดเดียว แต่เทคโนโลยีพัฒนาไปไกลมากแล้วจากยุคที่เทอร์มินัลเป็นทางเลือกเดียว และตอนนี้ก็มีตัวเลือกที่ดีกว่าสำหรับสร้าง UI
- เว็บอินเทอร์เฟซก็ไม่ได้ดีกว่า มันถูกออกแบบเพื่อ ความสวยงาม มากกว่าฟังก์ชัน และแต่ละที่ก็มีสำนวน UI เฉพาะตัวที่ต้องเรียนรู้เหมือนกัน
- ผมใช้ vim กับ Emacs มาหลายสิบปี แต่พอย้ายไป GUI เมื่อไม่กี่ปีก่อน ก็ไม่คิดจะกลับไปอีก
  กระแส TUI ทั้งหมดนี้สำหรับผมดูเป็นแค่ เทรนด์แฟชั่น
เพราะไม่มีใครลงทุนกับการพัฒนา native UI เลย Electron คือหลักฐานว่าถ้ามี GUI stack ที่ใช้ง่าย บริษัทต่าง ๆ ก็พร้อมจะเอาไปใช้
- ในบทความบอกว่า Google เลิกก่อนปล่อยของจริง แต่ผมว่า Flutter ยังพัฒนาต่อและมีการใช้งานเพิ่มขึ้นอยู่
- เวลาจะสร้างยูทิลิตีเล็ก ๆ เช่นเครื่องมือค้นหาไฟล์ด้วย regex นี่แหละที่แย่ที่สุด
  ถ้าเป็นแอปใหญ่ เวลาที่เสียไปกับการแพ็กเกจและแจกจ่ายจะเป็นสัดส่วนเล็กของทั้งหมด และขนาดไฟล์ก็ไม่ใช่เรื่องใหญ่มาก แต่แอปเล็กไม่เป็นแบบนั้น
  แอปบน Windows นั้นง่าย ไบนารีเล็ก ๆ เปิดฟอร์ม รันด้วยดับเบิลคลิก และไม่ต้องติดตั้ง
  แต่ถ้าจะทำแบบเดียวกันบน Linux คุณรับประกันไม่ได้ว่า GTK หรือ Qt จะติดตั้งอยู่แล้ว เพราะงั้นถ้าจะทำแบบ standalone ก็แทบจะต้องส่งระบบปฏิบัติการทั้งก้อนไปด้วย ผลคือไฟล์ใหญ่ขึ้น
  Python ก็ลำบากเพราะผู้ใช้ Windows ต้องมี Python อยู่แล้ว ไม่งั้นก็ต้องส่ง interpreter ไปด้วย
  ทางเลือกที่พอเป็นไปได้มีแบบ Java ที่รันไฟล์ .jar เดียวได้บนทุกระบบ แต่ Oracle เปลี่ยนไลเซนส์ไปแล้ว และ JavaFX ก็ไม่ได้รวมมากับ Java อีกต่อไปแล้ว แม้ว่า Swing จะยังอยู่ก็ตาม
  ผมแค่อยากแสดงเมนูบาร์ที่มีคีย์ลัด ทำไมถึงไม่มีอะไรอย่างเมนูบาร์ VM ที่เปิดให้เข้าถึงเมนูบาร์ได้บนทุกระบบปฏิบัติการ
  การส่งทั้งเบราว์เซอร์ไปกับ Electron เป็นเรื่องโง่มาก มันควรเป็นแพลตฟอร์มแบบที่ผู้ใช้ติดตั้งไว้ เหมือน Flash เวอร์ชันเดสก์ท็อป แล้วทุกแอปก็ใช้สิ่งนั้นร่วมกัน
  บางทีการแจกจ่ายเกม DOS อาจง่ายกว่าการแจกจ่ายแอปเดสก์ท็อปเสียอีก เพราะคนที่อยากเล่นเกม DOS ก็มักติดตั้ง DOS emulator ไว้แล้ว
- ผมว่ามันใกล้เคียงกับการ ยังไม่ได้สร้างของที่ถูกต้อง มากกว่าจะเป็นแค่ขาดการลงทุน
  สิ่งที่ต้องการคือเฟรมเวิร์กที่ใช้ง่าย ข้ามแพลตฟอร์ม เป็นโอเพนซอร์ส และถ้าเป็นไปได้ก็ใช้ได้จากภาษาโปรแกรมที่เลือก
- Zed ทำแบบนั้นจริง แต่ถึงจะมีแฟนอยู่บ้าง เมื่อเทียบกับความพยายามมหาศาลที่ทุ่มลงไปเพื่อสร้างระบบ GUI ตั้งแต่ฐานราก การยอมรับก็ยังไม่ดูระเบิดขึ้นมาเลย
- ผมว่า wxWidgets กับ Qt ก็โอเคนะ GTK 2 และ 3 ก็โอเคเหมือนกัน ส่วน 4 ขึ้นไปเริ่มไม่ค่อยดี แอปที่ใช้พวกนี้ก็มีเยอะ และการใช้ผ่าน Python bindings ก็เป็นเรื่องปกติ
  ปัญหาใหญ่กว่าคือคนทำงาน คนที่รู้เว็บดีมีเยอะ บริษัทก็เลยอยากใช้คนกลุ่มนั้นกับเดสก์ท็อปด้วย และถ้าเดสก์ท็อปเป็น JavaScript บน Electron มันก็ยิ่งง่ายขึ้นมาก
ผมไม่ค่อยเข้าใจ terminal UI ที่พยายามสร้างฟังก์ชันแบบ GUI ขึ้นมาใหม่ อินเทอร์เฟซคอมพิวเตอร์มันควรจะดีขึ้นไม่ใช่หรือ
ตอนนี้เราไม่จำเป็นต้องถูกจำกัดอยู่กับกริดตัวอักษรเพื่อแกล้งทำเป็นวาดเส้นและรูปทรงอีกแล้ว ถ้าไม่มีเทอร์มินัลนอกมาตรฐานอย่าง Kitty หรือ iTerm ก็แสดงภาพไม่ได้ด้วยซ้ำ
น่าเสียดายที่ไม่มีระบบสตรีมมิง UI ข้ามแพลตฟอร์มที่ยอดเยี่ยม เว็บก็ยอดเยี่ยมในแบบของมัน แต่ชัดเจนว่าน่าจะมีอะไรที่ดีกว่าสำหรับจุดประสงค์นี้ Flutter ก็โอเค แต่ไม่เป็น on-demand พอ และผูกติดกับ Dart มากเกินไป
- นี่เป็นเพราะ ความล้มเหลวของสภาพแวดล้อม GUI สมัยใหม่
  ผู้คนต้องการ GUI แต่สุดท้ายต้องอ้อมไปใช้ของคล้าย GUI ใน TUI แทน
  พวกเขาต้องการบางอย่างที่พกพาได้ รันจากระยะไกลได้ ปลอดภัยกว่าโดยไม่ต้องเปิด socket และไม่ต้องยกเดสก์ท็อปทั้งชุดขึ้นมา
  หน้าต่างแบบไร้รูทนั้นแทบตายไปแล้ว สิ่งที่เหลือคือเว็บอินเทอร์เฟซพร้อมปัญหาทั้งหมดของมัน หรือไม่ก็ TUI ที่ใช้ได้ด้วยการเชื่อมต่อ SSH ที่ทุกคนมีอยู่แล้ว
  สมัยก่อนทำอะไรลวก ๆ ด้วย Tcl/Tk แล้วเปิดหน้าต่างผ่าน X Window ก็พอได้ แต่ทุกวันนี้มันไม่ง่าย และแทบไม่มีใครใช้ remote X แล้ว
  ตัวหารร่วมต่ำสุดคือ SSH และสิ่งที่อยู่รอดก็คือสิ่งที่เข้ากับมัน
- เรื่องแสดงภาพนั้น Sixel มีเทอร์มินัลหลายตัวรองรับอยู่แล้ว[0]
  เทอร์มินัลหลายตัวที่ถูกยกมาเป็นตัวอย่างว่าไม่รองรับก็ใช้ GNOME VTE เป็นฐาน ซึ่งฝั่งนั้นกำลังทำการรองรับอยู่ และดูจาก bug tracker ก็น่าจะใกล้เสร็จแล้ว
  รวมถึง xterm ซึ่งบน X11 ก็ใกล้เคียงกับเทอร์มินัลมาตรฐานที่สุดด้วย
  [0] https://www.arewesixelyet.com/
- TUI ทำให้งานเสร็จได้ง่ายกว่า เพราะถ้าจะทำ GUI ให้ดี โค้ดเบสจะซับซ้อนขึ้นแบบฉับพลันมาก
  แถมก็ไม่มี GUI toolkit ที่แข็งแรงน่าเชื่อถือจริง ๆ แต่ละตัวก็เต็มไปด้วยบั๊กและข้อควรระวังต่างกันไปหมด
  Flutter อาจพอใช้ได้ แต่ก็ต้องมองข้ามความจริงที่ว่ากระบวนการ build แอปด้วย Flutter เองนั้นเหมือนฝันร้าย ตัว Flutter เองก็ดูไม่ได้ออกแบบมาให้ใครก็ได้คอมไพล์ได้ง่าย ๆ และในทางปฏิบัติสิ่งที่ช่วยกลบปัญหานี้ก็คือดิสโทรต่าง ๆ
- ระบบสตรีมมิง UI ข้ามแพลตฟอร์มอาจเรียกได้ว่าเป็น เว็บ/Jupyter
  และ UI บนเว็บก็ไม่จำเป็นต้องหนักเสมอไป อย่าง HN เองก็ไม่หนัก
- บน SSH นั้น ข้อความเร็วกว่า การวาดกราฟิกใหม่แบบ RDP, VNC มักช้ากว่าและจุกจิกกว่าในระยะยาว
แม้ในฐานะคนที่เปิดเทอร์มินัลไว้ตลอดเวลา ใช้ Bash script ทำให้ชีวิตเป็นอัตโนมัติ และใช้ VIM/TMUX อยู่แล้ว TUI ส่วนใหญ่ก็ยังด้อยกว่า GUI ดี ๆ อยู่สองก้าว
ไม่ว่าจะเป็นการนำทางกับคีย์ลัดที่สะเปะสะปะ การคัดลอกและวางที่พัง หรือการผสานกับสภาพแวดล้อมที่ไม่ดี
ปัญหาแกนกลางคือไม่มี แพลตฟอร์ม GUI ข้ามแพลตฟอร์ม ที่ดี ซึ่งถูกรวมเข้ากับภาษาโปรแกรมอย่างเหมาะสมหรือเป็นส่วนหนึ่งของ standard library
Swing เข้าถึงองค์ประกอบเบราว์เซอร์แบบเนทีฟได้ไม่ดี Tk ขาด browser component กับ drag and drop ส่วน wxWidgets มีชุมชนเล็ก และดูเหมือน bindings ต้องถูกชุบชีวิตใหม่มากกว่าหนึ่งครั้ง
Qt เองก็เสี่ยงจะถูกทำให้พังได้ทุกเมื่อหากอยากทำเงินเพิ่ม ผมก็ไม่คิดว่า KDE สำคัญถึงขนาดนั้น และยังสงสัยด้วยว่าชุมชน KDE จะรับภาระ fork ระยะยาวไหวไหม
สิ่งที่เหลือก็คือ Electron หรือพวกกลายพันธุ์ที่เอา JavaScript/CSS ไปครอบ browser component แล้วมี local server callback ซึ่งนอกจากโอเวอร์เฮดด้านหน่วยความจำและรันไทม์สำหรับแอปเล็ก ๆ แล้ว โมเดลการเขียนโปรแกรมเองก็แย่ด้วย
การสร้าง GUI toolkit ข้ามแพลตฟอร์มที่ดีจริงต้องใช้เงินและคนจำนวนมาก ทั้งด้าน usability, accessibility, design, documentation และ testing ชุมชนโอเพนซอร์สทำตรงนี้ไม่สำเร็จ GTK ก็แทบจะกลายเป็น Linux-only ไปแล้ว และก็ยังไม่มีตัวเลือกสมัยใหม่ที่มาแทน Qt หรือ Swing ได้
TUI ไม่ใช่คำตอบของปัญหาแกนกลาง แต่เมื่อมองตัวเลือกอื่น ๆ ก็เข้าใจนักพัฒนาที่เลือก TUI สำหรับ UI ข้ามแพลตฟอร์มอยู่ดี 80% ของความต้องการ GUI น่าจะทำได้ด้วย GUI toolkit ที่มี TUI renderer ด้วยซ้ำ
- สิ่งนี้ควรให้มาเป็น C API ไม่ใช่ผูกกับภาษาโปรแกรมภาษาใดภาษาหนึ่ง
  แบบนั้นถึงจะให้ API และ ABI ที่เสถียรได้ และทำ bindings ให้หลายภาษาอื่นได้โดยไม่ต้องอ้อมเยอะ โดยเฉพาะกับภาษาที่คอมไพล์ยิ่งสำคัญ
  การ bind Qt ให้ Python อาจง่าย แต่ถ้าจะเอาไปใช้กับภาษาอย่าง Free Pascal จำเป็นต้องมีไลบรารี C++ ขั้นกลางที่เปิด C API ออกมา และแอปก็ต้องแจกจ่ายไลบรารีนั้นไปด้วย
  น่าเสียดายที่ GUI toolkit ส่วนใหญ่ไม่ได้เขียนด้วย C แต่เป็น C++ หรือภาษาอื่น ทำให้การใช้งานจากภาษาที่นักพัฒนาเลือกกลายเป็นเรื่องทรมาน ถ้านับตัวหลัก ๆ ที่เขียนด้วย C แทบมีแค่ GTK ซึ่ง GTK ก็แทบไม่สนใจ backward compatibility ที่เหมาะสมเลย
  คุณอาจคิดว่าไลบรารีจะเขียนด้วยภาษาอะไรก็ได้ถ้าสุดท้ายเปิดออกมาเป็น C API แต่ถ้ามันไม่ใช่ของที่มีติดตั้งแพร่หลาย คุณอาจอยากลิงก์แบบ static ซึ่งนอกโลก C/C++ แล้วมันกลายเป็นปัญหา
  เช่นผมเคยพยายามทำ FLTK backend ให้ Lazarus[0] FLTK เป็นไลบรารี C++ และแนะนำให้ลิงก์แบบ static จึงดูเหมือนจะทำไบนารี GUI แบบ standalone ได้
  แต่สุดท้ายต้องไปทำ C wrapper ก่อน และบน Linux การลิงก์ไลบรารี C++ แบบ static จากภาษาที่ไม่ใช่ C/C++ โดยไม่มี magic flags ที่ g++ ส่งให้ linker นั้นทรมานมาก ส่วนบน Windows หรืออย่างน้อยใน msys2 นั้นทำไม่ได้เลย สุดท้ายเลยยอมแพ้
  [0] https://i.imgur.com/W6XbLkr.png
- เห็นด้วยเกือบทั้งหมด โดยเฉพาะ wxWidgets นี่น่าเสียดายจริง ๆ
  บน macOS และ Windows มันดูใกล้เคียง native มาก และเขียนโปรแกรมง่ายกว่า Qt มาก ในฐานะผู้ใช้และบางครั้งก็เป็นโปรแกรมเมอร์ ผมชอบ wxWidgets ที่สุดสำหรับ GUI หลายแพลตฟอร์ม
  ในทางกลับกัน ผมเกลียด Electron หรือการเอา browser component มาคู่กับ JavaScript/CSS และ local server callback ในฐานะผู้ใช้มาก ต่อให้ต้องยอมลดฟังก์ชันแล้วกลับไปใช้ command line ผมก็ยังอยากหลีกเลี่ยงแอปแบบนั้น
  มันไม่รองรับคีย์ลัดมาตรฐาน หน้าตาก็แปลกแยก และกระตุกในจังหวะที่ไม่คาดคิด
  เฟรมเวิร์ก TUI บางตัวก็เกือบไปถึงจุดนั้นแล้ว ข้อดีคือใช้ผ่าน SSH หรืออะไรทำนองนั้นได้โดยแทบไม่ต้องออกแรงเพิ่ม แต่ก็ดูเหมือนกำลังแก้ปัญหาผิดจุด
  แทนที่จะทำให้ทุกอย่างดูหรือทำงานเหมือน IDE ผมอยากได้ CLI ที่โฟกัสและประกอบกันได้มากกว่า ควบคู่กับอะไรอย่าง tmux ที่จัดการหน้าต่างและ persistence ได้ดีขึ้นหน่อย
  ถ้าสร้าง REPL ง่าย ๆ ที่มี readline ติดมาด้วย ก็จะได้พฤติกรรมที่มาตรฐานและคาดเดาได้
  ถึงอย่างนั้น ผมก็ชอบที่กระแสนี้ช่วยผลักดัน การพัฒนา terminal emulator
TUI ที่ผมดู ๆ มาเหมือนจะ พึ่งพา NPM กันเยอะ
มันแปลกดี เหมือนพวกเอเจนต์ไม่มีเวลาแม้แต่จะเขียนตัวเองใหม่ให้ไม่ใช่กองยางไหม้ด้านความปลอดภัย
กระแสที่บอกว่าเอเจนต์พวกนี้จะเข้าครองทุกสิ่ง สุดท้ายเลยทำให้ผมคิดว่ามันเป็นของที่สร้างโดยคนสายสตาร์ตอัปประเภทขยะ-หมุน-ขยะ ที่ไม่ต้องกังวลอะไรนอกจากว่ามันยังเร็วไม่พอ
- 99% ของซอฟต์แวร์รอบ ๆ LLM ก็ยังเป็น เศษเว็บง่อนแง่น ที่พังอยู่เหมือนเดิม
  อย่างเช่น OpenCode ทุกวันนี้ยังทำเรื่องพื้นฐานอย่างเก็บ log ข้อความทั้งหมดแล้วส่ง log นั้นไปยัง SSE endpoint ตามลำดับเดิมเพื่อรับคำตอบถัดไปไม่ได้ดีพอ และต่อให้ปิด context pruning ก็ยังพลาด prompt cache อยู่บ่อย ๆ
- Go + Lipgloss + Bubbletea คือสแตกที่แข็งแรงและประสิทธิภาพดีที่สุดในการสร้างหรือเจน TUI ที่ทั้งสวยและใช้งานได้
  ประสบการณ์นักพัฒนาก็ดีมาก และไม่ต้องใช้ npm
- ยุคแห่งความปลอดภัยอันสงบสุขที่ทุกอย่างรันด้วย curl | bash ช่างน่าคิดถึง
- ใช่เลย คนที่ตื่นเต้นกับการใส่ AI ลงในทุกสิ่งส่วนใหญ่ก็คือนักพัฒนา JavaScript/TypeScript มักทำงานในสตาร์ตอัป และบ่อยครั้งก็อยู่ในสาย AI ด้วย
มันแปลกที่ปล่อยให้นักพัฒนาซอฟต์แวร์เป็นคนออกแบบส่วนติดต่อผู้ใช้
ดูเหมือนพวกเขาจะไม่สามารถสร้างอินเทอร์เฟซที่ไม่ใช่ข้อความได้เลย เหมือนให้ช่างประปาออกแบบบ้านแล้วทุกพื้นถูกทำให้ลาดลงเพื่อให้เดินท่อได้ง่าย
ถ้าต้องย้ายหลายหน้าต่างและปรับขนาด ก็สร้างหน้าต่างข้อความ ถ้าต้องเลือกตัวเลือกอย่างรวดเร็ว ก็สร้างกล่องข้อความ และถ้าต้องเขียนเอกสารที่มีสไตล์และการจัดรูปแบบอย่างรวดเร็ว ก็ให้เขียนข้อความเพิ่มเพื่อใช้เป็น formatting
แต่กลับไม่ทำแอปที่ให้ดูข้อความนั้นในสภาพจัดรูปแบบแล้วได้อย่างง่ายดาย
- จะบอกว่า “ปล่อยให้” ได้ยังไง โปรเจกต์ TUI โอเพนซอร์สพวกนี้ส่วนใหญ่ก็เริ่มจากคนคนเดียวหรือทีมเล็ก ๆ ที่แค่อยากแก้ปัญหาของตัวเอง
  มันทำได้อยู่แล้ว และถ้าไม่ชอบก็ไม่ต้องใช้
- ที่อีกสุดขั้วหนึ่งมี Material และในระดับหนึ่งก็มี Adwaita
  มันดูสวยดี แต่แทบไม่มีประโยชน์กับงานซับซ้อนที่เกินกว่าการพัฒนาสไตล์แอปหรืออะไรอย่าง file manager
- ผมไม่เข้าใจว่าคุณพูดถึงอะไร ถ้าให้ design system ที่ดีแก่นักพัฒนา พวกเขาก็ทำได้ดีพอแล้ว
TUI ดีสำหรับคนที่ใช้ชีวิตอยู่ในเทอร์มินัล
มันไม่มีสิ่งรบกวนจากคอนเทนต์เชิงภาพ ใช้คีย์บอร์ดได้อย่างมีประสิทธิภาพสุด ๆ และตอนนี้ AI ก็ช่วยสร้างให้ได้เร็วแล้ว เมื่อก่อนมันทรมานมาก
- จุดที่ AI สร้างให้ได้เร็วต่างหากที่เป็นเหตุผลใหญ่ที่สุด และแทบจะเป็นเหตุผลเดียวเลยด้วยซ้ำ
- ข้อสรุปจากเรื่องนี้คือมีคนที่คุ้นเคยกับการอยู่ในเทอร์มินัลมากขึ้น
  เพราะผู้ชมของ TUI เพิ่มขึ้น TUI เลยแพร่หลายขึ้นด้วย
- TUI ไม่มีที่ว่างสำหรับ padding ไม่รู้จบ เพื่อทำให้หน้าตาดูเรียบหรูทันสมัย
  และในข้อความกว้าง 80 คอลัมน์ ผู้จัดการผลิตภัณฑ์ก็แทบไม่มีอะไรให้มาลดทอนจนเสียของได้

savvykang 2026-05-04

มันไม่ใช่เรื่องผิดหรอกเหรอที่อยู่ในสถานการณ์ซึ่งไม่มีบิ๊กเทครายไหนยอมทิ้งเบราว์เซอร์

GN⁺ 2026-05-04

ความเห็นจาก Lobste.rs

อยากให้คนทำ แอปเนทีฟ กันไปเลยมากกว่า TUI ดูเหมือนเป็นการเอาข้อเสียของทั้ง command-line interface และ GUI จริง ๆ มารวมกัน
โปรแกรม TUI ทุกตัวต้องไปเขียนระบบเลื่อนเองใหม่หมด ดังนั้นถึงเทอร์มินัลจะรองรับการเลื่อนแบบระดับพิกเซล โปรแกรม TUI ก็ยังรองรับแค่การเลื่อนทีละบรรทัดและพฤติกรรมก็ไม่เหมือนกันเลย scrollback ของ senpai ก็ทำงานต่างจากโปรแกรมอื่นที่ฉันใช้จนหลงทางอยู่เรื่อย
แถมยังไม่มีวิธีบอกเทอร์มินัลด้วยว่าอินเทอร์เฟซนั้นมีอะไรมากกว่าแค่แผงข้อความเดียว ทำให้การเลือกข้อความพังบ่อย ๆ จะดักจับ mouse event ก็พอทำได้ แต่แบบนั้นก็แย่ไปอีก ใน TUI IRC client ตัวหนึ่ง ฉันต้องกดคีย์ลัดเพื่อซ่อนพาเนลจุกจิกด้านข้างก่อนถึงจะเลือกข้อความได้ ซึ่งเป็นขั้นตอนที่งี่เง่าพอสมควร
ข้อจำกัดที่ต้องยึดกับกริดยังจำกัดความเป็นไปได้ด้านเลย์เอาต์และดีไซน์อย่างมาก ทำให้นึกถึงสมัยที่พยายามจัดสไตล์ให้ดูเหมือนปุ่มที่กดได้ หรือพวก contextual menu อะไรแบบนั้น ฉันเคย บ่นเรื่องนี้ไว้ก่อนแล้ว
ผมมองว่าการที่ TUI เพิ่มขึ้นเป็นผลลัพธ์ที่น่าเสียดายจากสภาพของ เฟรมเวิร์ก GUI แบบดั้งเดิม ที่ไม่ค่อยดี เฟรมเวิร์ก TUI ค่อนข้างเสถียร และถึงจะใช้ของเก่ามากก็ยังไม่ค่อยน่ารำคาญ โปรแกรม ncurses ยังใช้งานกันอยู่บ่อย แต่แทบจินตนาการไม่ออกว่าจะมีใครใช้โปรแกรม Motif
ในทางกลับกัน เฟรมเวิร์ก GUI มีตัวเลือกไม่มากและต้องบำรุงรักษามากกว่ามาก เดสก์ท็อปเอนไวรอนเมนต์เปลี่ยนไป ความคาดหวังต่อ GUI ก็สูงขึ้น ผมคิดว่า TUI ด้าน accessibility แย่มาก แต่ก็ไม่ถึงกับมั่นใจเต็มร้อย แถมยังเปลี่ยนแปลงหนักอีก ทำด้วย GTK2 ก็จะเลิกใช้ พอย้ายไป GTK3 ก็โดนบอกให้ไป GTK4 วนแบบนี้
ถ้ามองแบบประชด ๆ สิ่งอย่าง Omarchy ก็มีปัจจัยอื่นด้วย xfce4-taskmanager แบบ GUI ธรรมดามันน่าเบื่อ แต่ btop ที่เป็น TUI ดูแฮกเกอร์สุด ๆ คนชอบสุนทรียะแบบเทอร์มินัล (ดู /r/unixporn) และดูพร้อมจะยอมเสียความใช้งานได้เพื่อ บรรยากาศ ด้วย เห็นได้จาก btop ที่ทำให้รายการโปรเซสค่อย ๆ fade out จริง ๆ
- ฉันทำเว็บมานานแล้วเลยอยากลองทำ แอปพลิเคชันเนทีฟ พอไปดูว่าจะทำแอป GNOME ยังไง กลับรู้สึกท้อมากเพราะมันเน้น C++
  ฉันหวังว่าเดี๋ยวนี้จุดเริ่มต้นน่าจะเข้าถึงง่ายขึ้นแล้ว ในเมื่อนักพัฒนาส่วนใหญ่ถูกฝึกมาด้วยภาษาระดับสูง มันเลยดูไม่ค่อยน่าโน้มน้าว และความซับซ้อนของ C++ ก็ดูจะทำให้ฉันกลัวด้วย
- นอกเรื่องนิด แต่ไม่เข้าใจว่าทำไมแชตไคลเอนต์หลายตัวถึงทำให้การคัดลอกประวัติแชตไปวางออกมาเละเทะขนาดนั้น ตัวอย่างเช่นใน Discord มันออกมาแบบนี้
  [
  20:41
  ]
  username1
  :
  message1
  [
  20:42
  ]
  username2
  :
  message2
  ส่วน Nheko ซึ่งเป็น Matrix client กลับไม่ให้เลือกเกินหนึ่งบรรทัดในครั้งเดียว
  แต่ฝั่ง IRC client จะให้มาแบบนี้เป็นค่าเริ่มต้น
  20:41 <username1> message1
  20:42 <username2> message2
- ฉันชอบ command-line interface แต่ก็ไม่ชอบ TUI เหมือนกัน มันมีที่ทางของมัน แต่โดยพื้นฐานแล้วมันใกล้เคียงกับ GUI ที่หยาบและหน้าตาน่าเกลียด และหลายครั้งก็เปลืองพื้นที่เทอร์มินัล
  บางครั้งมันก็สมเหตุสมผล แต่ในอุดมคติฉันคิดว่าควรใช้กับแอปเล็ก ๆ ใช้สั้น ๆ หรือข้อยกเว้นอย่างโปรแกรมแก้ไขข้อความเท่านั้น
- ผมรู้สึกว่า TUI มันอ่อนอยู่บ้าง แต่ถ้าเทียบกับพวกชุดเครื่องมือ UI อย่าง gtk มันก็ยังเป็นตัวเลือกที่แย่น้อยกว่า แอป TUI ที่ผมชอบมักขยายต่อได้ดี เร็ว และผสานกับ Linux command line ได้ดี
  อย่างเช่น lf, tig, kakoune เข้ากับ shell script ได้ดี เลยเอาสคริปต์ชุดเดียวกันมาใช้ซ้ำและขยายความสามารถได้ทั้งสามแอป และเพราะทั้งหมดรันใน alacritty จึงทำไฮเปอร์ลิงก์ที่ใช้ได้ทั้งสามแอปและทั้งเชลล์โดยรวมได้ด้วย
  ถ้าฝันได้ ผมอยากได้ ชุดเครื่องมือ GUI มินิมัลสีเดียว ที่เปิดทางให้มีการผสานแบบ Emacs หรือ acme
- โดยรวมเห็นด้วย แต่ก็อยากชี้ว่า Tk ยังเดินหน้าต่อแบบเงียบ ๆ และยังมีประโยชน์อยู่จนถึงตอนนี้ ตัวอย่างเช่น gitk
ผมไม่เข้าใจว่า TUI มัน “ทำให้อัตโนมัติได้ง่าย” ยังไง มันก็เหมือน GUI ที่แสดงอยู่บนคอนโซลไม่ใช่หรือ?
- TUI หลายตัวมี แฟล็กที่ทำงานเหมือนภาษาสคริปต์ ตอนเปิดโปรแกรม นอกจากนี้ LLM ก็โต้ตอบกับอินเทอร์เฟซแบบข้อความได้ง่ายและต้นทุนต่ำกว่าพวก native GUI จริง ๆ หรือแอป Electron ที่มีกลิ่นอาย JavaScript
บทความนี้พลาดเหตุผลหลักว่าทำไม TUI ถึง “กลับมา” ถึงตัวข้ออ้างนั้นเองก็น่าสงสัย แต่ดูเหมือนว่าความนิยมช่วงหลังเพิ่มขึ้นจริงเพราะ coding agent อย่าง Claude ทำให้เกิดการ vibe coding กันจำนวนมาก
นักพัฒนาชอบทางเลือกที่ง่าย เพราะการทำ TUI แบบข้ามแพลตฟอร์ม ง่ายกว่าการทำ GUI
เหตุผลเดียวกันนี้เองที่เว็บแอปได้รับความนิยม เพราะใช้เครื่องมือเบราว์เซอร์ทำแอปข้ามแพลตฟอร์มได้ง่าย และที่ Electron ดังขึ้นมาก็เพราะเป็นตรรกะเดียวกันโดยตัดภาระรองรับข้ามเบราว์เซอร์ออกไป งานอย่างการทำ responsive UI, การเรนเดอร์ UI แบบข้ามแพลตฟอร์ม, หรือการจัดการ input ของผู้ใช้โดยเฉพาะเมื่อคำนึงถึง accessibility ล้วนยากทั้งนั้น นักพัฒนาเลยรีบกระโดดไปหาอะไรก็ตามที่ทำให้เรื่องพวกนี้ง่ายขึ้น
ช่วงหลังยังมีการเปลี่ยนแปลงที่ทำให้สร้าง TUI ได้ง่ายขึ้นด้วย การรองรับข้ามแพลตฟอร์มของฟีเจอร์ขั้นสูงดีขึ้น มีไลบรารียอดนิยมที่ช่วย abstract รายละเอียดซับซ้อนออกไป และสิ่งเหล่านี้ก็ดูจะนำไปสู่ยุคฟื้นฟู TUI รอบล่าสุด
นอกนั้นประเด็นอื่น ๆ ในบทความก็ค่อนข้างน่าสงสัย เช่น ผู้เขียนยกความไม่สม่ำเสมอเป็นจุดอ่อนของแอป Electron แต่ TUI ยอดนิยมหลายตัวก็แทบไม่มีความสม่ำเสมอเช่นกันนอกจากธรรมเนียมร่วม ๆ กัน coding agent ใช้คีย์ลัดคล้ายกันก็เพราะส่วนใหญ่ลอกมาจากแหล่งเดียวกันคือ Claude และคีย์ลัดพวกนั้นก็ไม่ได้ขยายไปไกลนอกกลุ่ม coding agent เท่าไร TUI ส่วนใหญ่ที่ฉันใช้มีทั้งคีย์ลัดและภาษาภาพที่ค่อนข้างต่างกัน
- ฉันไม่ค่อยเข้าใจว่าคำว่า “การทำ responsive UI นั้นยาก” หมายถึงอะไร ฟังดูเหมือนพูดเรื่องเว็บ ซึ่งแม้บางแนวคิดจากเว็บจะเกี่ยวข้องได้บ้าง แต่ถ้าพูดถึง native GUI มันก็ดูหลุดประเด็น หรือจริง ๆ หมายถึงแค่ “การทำ UI ที่ดี” หรือ “การทำชุดเครื่องมือ UI” กันแน่?
  คำว่า “การเรนเดอร์ UI แบบข้ามแพลตฟอร์มนั้นยาก” ก็ชวนสงสัยเหมือนกัน มันต้องมี compatibility layer และต้องมี implementation ตามจำนวนแพลตฟอร์มก็จริง แต่ก็ดูไม่ได้ยากกว่าการรองรับแพลตฟอร์มเดียวมากนัก เว้นแต่แพลตฟอร์มเป้าหมายจะมีวิธีเรนเดอร์ต่างกันมากจนออกแบบ API ร่วมกันยาก แต่ถ้าในระดับวาดพิกเซลลงหน้าจอก็ไม่น่าจะเป็นแบบนั้น เรื่องอย่างสเกลก็ต้องจัดการอยู่แล้ว แต่เกินจากนั้นก็น่าจะค่อนข้างตรงไปตรงมา หรือไม่ก็มี SDL อยู่แล้ว
  อาจจะหมายถึงการทำให้ UI “ดูเป็นเนทีฟ” บนทุกแพลตฟอร์มมากกว่า ซึ่งกรณีนั้นอาจต้องใช้ชุดเครื่องมือ native GUI ที่แต่ละแพลตฟอร์มนิยมกัน และมันไม่เพียงต่างกันมาก แต่ยังอาจใหญ่กว่าและเสถียรน้อยกว่า low-level rendering API มากด้วย เรื่องแบบนั้นชีวิตสั้นเกินไป ฉันอาจเปิดช่องให้ปรับธีมสีหรือสไตล์กราฟิกบางส่วนได้ แต่จะให้เป็นการตั้งค่าระดับแอปพอ ไม่อยากเสียเวลาไปอ่านค่าการตั้งค่ากราฟิกของแต่ละระบบปฏิบัติการ
  ส่วนคำว่า “การจัดการ input ของผู้ใช้ โดยเฉพาะ accessibility นั้นยาก” ก็ดูแปลก การฟัง keyboard กับ mouse event เป็นเรื่อง เล็กน้อยมาก ในมุม accessibility ก็ต้องมีการนำทางด้วยคีย์บอร์ดที่ดี ซึ่งสำคัญต่อ usability โดยรวมด้วย และต้องรองรับคีย์ลัดทั้งมาตรฐานและแบบกำหนดเอง แต่โดยรวมแล้วมันยังดูง่ายกว่าส่วนอื่นมาก
  การรองรับ screen reader อาจยากได้ตาม API ของแพลตฟอร์มที่เกี่ยวข้องและความต่างระหว่างแพลตฟอร์ม แต่เรื่องนั้นใกล้เคียงกับปัญหาการเรนเดอร์มากกว่าจะเป็นปัญหาเรื่อง input
TUI ไม่ได้ “คัมแบ็ก” เท่าไร แต่ดูเหมือนเป็นอาการของการสูญเสีย ความรู้ด้านการเขียนโปรแกรม native GUI จนต้องพยายามทำให้ดีที่สุดด้วยเครื่องมือที่มีอยู่มากกว่า มันเป็นผลจากการขาดการพัฒนาและการลงทุนอย่างต่อเนื่อง
ถ้าไม่นับข้อยกเว้นสดใสไม่กี่อย่างอย่าง Qt อารยธรรมด้าน UI ก็พังทลายไปแล้ว และเรากำลังใช้ชีวิตอยู่ในโลกหลังหายนะ
มันให้ความรู้สึกคล้องจองกับปาฐกถา Preventing the Collapse of Civilization และตอนนี้ที่ AI เขียนโค้ดจำนวนมาก ฉันก็กลัวว่าการล่มสลายของความรู้นี้จะยิ่งแพร่กระจาย
- ทุกครั้งที่มีหัวข้อนี้บน lobste.rs ฉันก็มักจะโผล่มาแจม ดังนั้นครั้งนี้ก็คงต้องแจมอีกครั้ง จักรวรรดิ GUI ทุกแห่งกำลังพังทลายลงต่อหน้าต่อตา ไม่ว่าจะ Windows, macOS, GTK หรือผลิตภัณฑ์ของ Mozilla ก็เหมือนกันหมด
  มันชวนให้นึกว่าคงต้องมี After Virtue ฉบับวงการคอมพิวเตอร์ และบางทีตัวตนบนโลกออนไลน์ของ Blow อาจกำลังทำหน้าที่นั้นอยู่ก็ได้ ไม่ว่าอย่างไร ฉันคิดถึงยุคของอินเทอร์เฟซคอมพิวเตอร์ที่มีความสม่ำเสมอ เคารพผู้ใช้ และตอบแทนการเรียนรู้กับความใส่ใจ
บทความนี้แทบไม่มีเนื้อหาจริงจังเลย และเหมือนจะบอกแค่ว่าผู้เขียนคิดว่าสิ่งอื่น ๆ ทั้งหมดห่วย
แต่จะพูดอย่างหนึ่งคือ Emacs เป็นแพลตฟอร์มที่ยอดเยี่ยมสำหรับอินเทอร์เฟซแบบข้อความ คีย์บอร์ด ปุ่ม และ rich media
เป็นไปได้มากว่าเพราะคนเริ่มใช้ ไลบรารี TUI ที่ไม่ใช่ ncurses ใน Go, Rust และตอนนี้ก็ Zig กันแล้ว อย่างน้อยมันก็แก้ปัญหาเรื่อง portability สยอง ๆ ที่เมื่อก่อนต้องพึ่ง ncurses
จากนั้นผู้คนก็เริ่มสร้างเทอร์มินัลรุ่นใหม่และผลักเทคโนโลยีฝั่งนั้นต่อด้วย ส่วนหนึ่งก็เพราะตอนนี้ทำด้วย Go, Rust, Zig แทน C ได้แล้ว
พอให้ทางเลือกที่ดี สนุกกว่า และน่าหงุดหงิดน้อยกว่า C กับ C++ คนก็ย่อมเริ่มเขียนโค้ดที่ใหม่กว่าและมีประโยชน์กว่าเป็นธรรมดา
เหตุผลจริงที่ TUI กลับมาก็เพราะถ้าจะปล่อย GUI ที่ต้อง signed และ notarized ในปี 2026 คุณต้องจ่ายเงินให้ Apple และสำหรับ Windows ก็ต้องจ่ายให้หน่วยงานออกใบรับรองด้วย
- แต่ native TUI binary ก็เจอปัญหาเดียวกันไม่ใช่หรือ?
ขอแก้รายละเอียดนิดหนึ่ง: ไลบรารี UI ที่เร่งด้วย GPU ของ Zed คือ gpui ไม่ใช่ cross-platform API อย่าง wgpu
ไม่แน่ใจว่าบทความพิสูจน์ประเด็นของตัวเองได้ดีแค่ไหน แต่ในฐานะคนที่ผ่านยุค MS-DOS มาและชอบ TUI มาตลอด ขอร่วมวงด้วย ถ้าเคยใช้ afl-fuzz ก็น่าจะเข้าใจ
ตามทฤษฎีแล้ว TUI ควรประสบความสำเร็จบน Linux มากกว่านี้มาก มีกลุ่มผู้ใช้สายเทคนิคที่ชอบสุนทรียะแบบข้อความอยู่แล้ว และยังมี “ข้อได้เปรียบ” ของสภาพแวดล้อม GUI ที่หยาบและไม่สม่ำเสมอด้วย สมัยหนึ่งแค่ทำให้การ์ดจอทำงานกับ X server ได้ถูกต้องก็ยังเป็นปัญหา
แต่ในขณะเดียวกัน นักพัฒนาซอฟต์แวร์ *nix ตลอดหลายสิบปีก็รู้สึกว่าต้องมีพันธะรองรับเทอร์มินัลโบราณแปลก ๆ ด้วย ราวกับว่าถ้าแอปพลิเคชันเรนเดอร์บน DECwriter ไม่ถูกต้องจะเกิดเรื่องใหญ่ ซึ่งภายใต้ข้อจำกัดแบบนั้นก็ทำ TUI ดี ๆ ได้ยาก
ในยุค MS-DOS บริษัทอย่าง Microsoft, Borland และ Norton เคยทำอินเทอร์เฟซแบบข้อความที่ใช้งานได้จริงและตอบสนองไวสำเร็จมาแล้ว แต่บน Linux เป็นเวลานาน “จุดสูงสุด” ของการออกแบบ TUI กลับเป็นสัตว์ประหลาดอย่าง menuconfig และถ้าหรี่ตาหน่อยก็อาจนับ vim เป็น TUI ได้ด้วย TUI บน Linux ที่ดีจริง ๆ เท่าที่จำได้จากยุคที่คนยังใช้ text-mode console กันอยู่ ก็คงมีแค่ตัวจัดการไฟล์ Midnight Commander ที่ได้แรงบันดาลใจจาก Norton Commander