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

 (wiki.alcidesfonseca.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง 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

ข้อจำกัดของแอป 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 หรือคลิกขวา → คัดลอก ถือว่าไม่สะดวก
  • นักพัฒนาทุกคนควรเรียนรู้ทฤษฎีที่ทำให้ไม่ใช่แค่ซอฟต์แวร์ แต่รวมถึงส่วนติดต่อผู้ใช้โดยทั่วไปดีขึ้น
  • ต้องเลิกมองการออกแบบสำหรับผู้ใช้เหมือนเป็น soft skill ที่ไม่สำคัญในหลักสูตรวิศวกรรมซอฟต์แวร์
  • ไม่ว่าในกระบวนการใด หาก UI ยังไม่เป็นที่เข้าใจ โครงการนั้นก็ควรถูกมองว่าล้มเหลว และในรายวิชา HCI ก็ควรมุ่งเป้าไปที่ UI ที่สมบูรณ์แบบ
  • งานสร้าง UI ที่ดีนั้นใช้แรงส่วนใหญ่ไปกับการทำความเข้าใจความต้องการ ขณะที่ตัวการเขียนโปรแกรมเองกำลังถูกทำให้เป็นอัตโนมัติอยู่แล้ว
  • ผู้สร้างระบบปฏิบัติการและทูลคิตควรผลักดันการลงทุนเพื่อสร้างทูลคิตที่เข้าถึงง่าย ซึ่งนักพัฒนาอยากใช้ และลดอุปสรรคในการเริ่มต้น
  • ไม่ได้ยืนกรานว่าต้องรองรับข้ามแพลตฟอร์มเสมอไป แต่หากมีทางออกแบบนั้นอย่างน้อยสักหนึ่งอย่าง ก็อาจช่วยลดการพึ่งพา Electron และ TUI ได้

บทความที่เกี่ยวข้อง

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

 
GN⁺ 1 시간 전
ความเห็นจาก 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