คอมโพเนนต์ GPUI แบบข้ามแพลตฟอร์มสำหรับ Rust

 (github.com/longbridge)
18 คะแนน โดย GN⁺ 2025-10-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไลบรารีคอมโพเนนต์ UI ที่ช่วยสร้าง แอปพลิเคชันเดสก์ท็อปแบบข้ามแพลตฟอร์ม โดยใช้ เฟรมเวิร์ก GPUI ที่พัฒนาด้วย Rust
  • มี คอมโพเนนต์ UI สไตล์เนทีฟมากกว่า 60 รายการ โดยผสานอารมณ์การออกแบบของ macOS·Windows เข้ากับความงามสมัยใหม่ของ shadcn/ui
  • มาพร้อมฟังก์ชันครบครัน เช่น ตารางแบบ virtualized, โค้ดเอดิเตอร์ประสิทธิภาพสูง, การเรนเดอร์ Markdown/HTML, การแสดงผลกราฟ
  • ออกแบบโดยให้ความสำคัญกับการขยายต่อและการปรับแต่ง เช่น ระบบธีม, หลายภาษา (i18n), เลย์เอาต์แบบ docking
  • ในอีโคซิสเต็ม Rust มีความโดดเด่นเมื่อเทียบกับ Iced, egui, Qt ในด้านสไตล์ UI ที่ทันสมัยและประสิทธิภาพการจัดการข้อมูลขนาดใหญ่

ภาพรวมโปรเจกต์

  • gpui-component คือ ชุดคอมโพเนนต์ UI เดสก์ท็อปแบบข้ามแพลตฟอร์ม ที่เขียนด้วย Rust และทำงานบนเอนจินเรนเดอร์ GPUI
    • เป้าหมายคือทำให้สามารถสร้าง “fantastic desktop applications” ได้อย่างรวดเร็วและสม่ำเสมอ
    • เว็บไซต์ทางการคือ longbridge.github.io/gpui-component
  • ไลเซนส์ Apache-2.0

ฟีเจอร์หลัก

  • ชุดคอมโพเนนต์ที่หลากหลาย: มีองค์ประกอบ UI มากกว่า 60 รายการ ครอบคลุมปุ่ม·ลิสต์·ตาราง·กราฟ·เอดิเตอร์ และส่วนประกอบอื่น ๆ
  • ดีไซน์ที่ให้ความรู้สึกเนทีฟ: ได้แรงบันดาลใจจากคอนโทรลพื้นฐานของ macOS และ Windows พร้อมผสานสไตล์ shadcn/ui เพื่อสร้างอินเทอร์เฟซที่ทันสมัย
  • การใช้งานที่กระชับ: โครงสร้างคอมโพเนนต์ RenderOnce แบบไร้สถานะ ช่วยให้เขียนโค้ดได้ง่ายและเข้าใจตรงไปตรงมา
  • ระบบธีมและสี: รองรับหลายธีมและการตั้งค่าแบบอิงตัวแปรผ่าน Theme และ ThemeColor
  • เลย์เอาต์ที่ยืดหยุ่น: ใช้ Dock layout สำหรับจัดวางพาเนล ปรับขนาด และจัดองค์ประกอบแบบไทล์ได้อย่างอิสระ
  • การเรนเดอร์ประสิทธิภาพสูง: ใช้ Virtualized Table/List เพื่อแสดงข้อมูลขนาดใหญ่ได้อย่างลื่นไหล
  • การเรนเดอร์คอนเทนต์: รองรับ Markdown และ HTML แบบง่ายในระดับเนทีฟ
  • ความสามารถด้านกราฟ: มีกราฟในตัวสำหรับการแสดงผลข้อมูล
  • โค้ดเอดิเตอร์: มี โค้ดเอดิเตอร์ประสิทธิภาพสูงที่อิง LSP รองรับได้สูงสุด 200,000 บรรทัด
    • รองรับฟังก์ชันอย่างการวินิจฉัย, การเติมคำอัตโนมัติ, hover เป็นต้น
  • การไฮไลต์ไวยากรณ์: ใช้ Tree Sitter เพื่อให้การเน้นไวยากรณ์ทั้งในเอดิเตอร์และ Markdown

เทคโนโลยีสแตกและสถิติ

  • สัดส่วนภาษา: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
  • ตัวชี้วัดคลังเก็บโค้ด: 5.4k stars, 223 forks, ผู้มีส่วนร่วมมากกว่า 45 คน
  • รีลีสล่าสุด: v0.3.1 (27 ตุลาคม 2025)

ความหมายโดยสรุป

  • gpui-component ถูกมองว่าเป็น เฟรมเวิร์ก UI เดสก์ท็อปแบบใหม่ที่ผสาน UI/UX ทันสมัยเข้ากับการเรนเดอร์ประสิทธิภาพสูงในอีโคซิสเต็ม Rust
  • ช่วยเติมเต็มข้อจำกัดของเฟรมเวิร์ก GUI เดิมใน Rust และมอบความสามารถที่เป็นมิตรต่อการใช้งานจริง เช่น การจัดการข้อมูลขนาดใหญ่·การทำธีม·การผสาน Markdown
  • เป็นโปรเจกต์ที่น่าจับตาในฐานะ ผู้ท้าชิงเลเยอร์ UI มาตรฐาน สำหรับการพัฒนาแอปแบบข้ามแพลตฟอร์มด้วย Rust ในอนาคต

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

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

 
GN⁺ 2025-10-28
ความคิดเห็นจาก Hacker News

  • ใน ecosystem ของ Rust UI นี่ดูเหมือนเป็น ชุดคอมโพเนนต์ที่สมบูรณ์ที่สุด เท่าที่เคยเห็นมา
    แม้ตอนนี้แทบยังไม่มีเคสการใช้งานจริง แต่เอกสารก็กำลังถูกจัดระเบียบได้ดีขึ้นเรื่อย ๆ
    อีกตัวอย่างหนึ่งที่มีความสมบูรณ์ใกล้เคียงกันคือ fyrox-ui แต่แทบไม่ได้ถูกใช้นอกเอนจิน fyrox
    Rust UI กำลังค่อย ๆ เติบโตเต็มที่ขึ้น แต่เฟรมเวิร์กยอดนิยมอย่าง iced, egui, dioxus และ slint ก็ดูยังขาดความสมบูรณ์ในแง่ของคอมโพเนนต์
    ถ้าจะอัปเดตความเห็นนี้ โปรเจกต์นี้แสดงให้เห็นถึง ความก้าวหน้าครั้งใหญ่ ของ ecosystem Rust UI
    สามารถ รันได้จากที่นี่ แอป widget gallery ที่รวมคอมโพเนนต์ทั้งหมดไว้ดูได้ — ใช้ cargo run --release ได้เลย

    • gpui เป็นโปรเจกต์ที่แยกออกมาจาก Zed Editor ดังนั้นปริมาณการใช้งานจริงน่าจะมากกว่า Rust UI crate อื่น ๆ มาก
    • Fyrox ทำให้รู้สึก ไม่ค่อยมั่นใจ กับการพัฒนาเกมด้วย Rust มันเป็นเอนจินที่โตเต็มที่ที่สุดแล้วแต่ก็แทบไม่มีใครใช้ ขณะที่คนกลับตื่นเต้นกันแค่กับ ECS ของ Bevy สุดท้ายเหมือนจะสนใจแต่ตัวระบบ ไม่ได้อยากสร้างเกมจริง ๆ
    • เฟรมเวิร์ก Rust UI ยัง เปลี่ยนแปลงเร็วมาก เลยอาจทำให้ดูยังไม่สมบูรณ์ แต่โมเมนตัมมีชัดเจน อย่างน้อยจากประสบการณ์ส่วนตัว ตอนนี้ก็สร้าง UI ระดับ enterprise ด้วย Rust ได้แล้ว
    • ลองติดตั้งแอป Longbridge ด้วยตัวเองแล้ว มัน ทำงานลื่นและเป็นธรรมชาติเหมือนแอป Mac แบบเนทีฟ จริง ๆ รันได้นุ่มนวลกว่า Electron มาก
    • แอป widget gallery น่าประทับใจ แต่การมี dependency มากกว่า 900 รายการ ก็ทำให้กังวลนิดหน่อย ไม่แน่ใจว่านี่เป็นเรื่องปกติของแอป GUI หรือเปล่า

  • แม้แต่ตัวอย่างที่ง่ายที่สุดก็ยังมี dependency เกิน 1000 รายการ มันพึ่งพา toolkit อย่าง GTK, GDK, pango และยังมีโครงสร้างที่ toolkit หนึ่งไปพึ่ง toolkit อื่นอีกที ซึ่งรู้สึกแปลกอยู่บ้าง

    • เพราะ GNOME ไม่ได้ implement server-side decoration จึงต้องพึ่ง libadwaita และนั่นน่าจะเป็นสาเหตุที่ดึง dependency ฝั่ง GTK เข้ามาทั้งหมด
    • บน Linux โครงสร้างแบบนี้พบได้ทั่วไป การใช้ GTK หรือ Qt เพื่อวาดหน้าต่างระดับบนสุดหรือเมนูเป็นเรื่องปกติ
    • ผมคิดว่า dependency 1000 ตัวที่เล็กและประกอบกันได้ ยังดีกว่า codebase ก้อนยักษ์ก้อนเดียว เพราะ audit ได้ง่ายกว่ามาก
    • น่าเสียดายที่เดี๋ยวนี้โปรเจกต์ Rust จำนวนมากเริ่มใหญ่ขึ้นในลักษณะนี้

  • รู้สึกขมขื่นอยู่บ้างที่เทคโนโลยีพื้นฐานของโอเพนซอร์สจำนวนมากถูกสร้างโดย บริษัทสายเทรดดิ้ง·คริปโต แต่ในอีกมุมหนึ่ง การที่พวกเขายังสร้างสิ่งที่เป็นประโยชน์ต่อสังคมก็ถือว่าเป็นเรื่องดี

    • gpui ดูแลโดยทีม Zed.dev ส่วน Longbridge ก็ดูเหมือนเป็นบริษัทโบรกเกอร์ทั่วไปที่ทำ แอป Longbridge Pro จึงไม่น่ามีอะไรเป็นปัญหาเป็นพิเศษ
    • ผมคิดว่า จิตวิญญาณแบบบิตคอยน์ คล้ายกับวัฒนธรรมแฮ็กเกอร์ ในแง่ของทัศนคติแบบ “ซ่อมสิ่งที่พังอยู่” ความเจ็บปวดระยะสั้นอาจนำไปสู่ผลประโยชน์ระยะยาวได้
    • ในบาง ecosystem อย่าง Rust หรือ OCaml (Jane Street) อาจมีแนวโน้มแบบนั้น แต่ถ้ามองภาพรวมแล้วก็เหมือนเป็นคำกล่าวที่เกินจริง
    • Facebook ที่สร้าง React ก็มีส่วนพัวพันกับเรื่องอย่าง คดี Cambridge Analytica หรือ การสังหารชาวโรฮิงญา ถ้ามองในแง่นั้น การที่บริษัทเทรดดิ้ง/คริปโตมาช่วยทำโอเพนซอร์สอาจถือว่าดีกว่าในเชิงศีลธรรมด้วยซ้ำ

  • ช่วงนี้สงสัยว่า toolkit UI ที่ถูกเรียกว่า “modern” ยังมี ตัวแก้ไข UI แบบภาพ อยู่ไหม
    Qt เคยมีเครื่องมืออย่าง QtCreator หรือ QtDesigner ที่ให้สร้าง UI ได้ด้วยการลากแล้ววาง
    และอีกอย่าง รายการเปรียบเทียบ Qt บางข้อก็ผิด เช่น ขนาดไบนารีขั้นต่ำ หรือคำอธิบายของ QSyntaxHighlighter

    • เฟรมเวิร์กอย่าง Slint รองรับการผสานกับ Figma จึงใช้งานได้คล้าย Qt Design Studio ดูเหมือนเดี๋ยวนี้หลายคนไม่ค่อยรู้แล้วว่า GUI designer แบบเนทีฟสมัยก่อนทรงพลังแค่ไหน
    • ถ้ามี component library ที่สมบูรณ์พอ ก็สามารถสร้าง visual editor แบบนี้บน Rust ได้เช่นกัน โดยเชื่อมโครงสร้างแบบ XML/markup ผ่าน macro และทำแอป preview แบบเรียลไทม์ให้ทำงานคล้าย Glade หรือ XAML
    • ขนาดขั้นต่ำของ Qt จริง ๆ ต่ำกว่า 20MB แต่โดยทั่วไปจะอยู่ราว 30~40MB เพราะโมดูล Core, Gui, QML, Widget แต่ละตัวกินประมาณ 8MB ดังนั้นแม้แต่ Hello World ก็ต้องใช้สัก 2~3 โมดูล
    • Qt Designer ใช้ได้ดีกับ UI ง่าย ๆ แต่พอใส่ custom styling เข้าไปก็พังง่ายมาก สุดท้ายเลยลงเอยด้วยการเขียนไฟล์ UI เอง ซึ่งสะอาดกว่าและเล็กกว่ามาก
    • ที่บอกว่า Qt6 ไม่รองรับธีมนั้นเป็นคำกล่าวที่ผิดอย่างสิ้นเชิง

  • น่าเสียดายที่นี่เป็น เฟรมเวิร์ก หมายความว่ามันต้องมี event loop ของตัวเอง
    ถ้าอยู่ในสภาพแวดล้อมที่มี loop อื่นอยู่แล้ว การรวมเข้าด้วยกันจะยาก ขณะที่ egui เป็นโครงสร้างแบบ ไลบรารี ที่แค่ถูกเรียกทุกเฟรม

  • สงสัยว่าระบบ screen reader accessibility สำหรับผู้พิการทางสายตาทำงานได้ดีหรือไม่

    • ยังไม่ได้ลองรันเอง แต่ตาม เอกสารทางการ บอกว่ารองรับมาตรฐาน ARIA เพียงเพิ่ม label และ description ที่จำเป็นก็พอ
    • แต่ Zed Editor นั้น ทึบสนิท สำหรับ screen reader จึงไม่ได้คาดหวังมากนัก
    • ทุกครั้งที่เห็น UI framework ใหม่ สิ่งแรกที่ผมถามเสมอก็คือเรื่อง accessibility นี่แหละ

  • คำว่า “native” ในที่นี้หมายถึงไม่ใช่เว็บ หรือหมายถึง ใช้ widget พื้นฐานของ OS กันแน่ ฝั่ง Java ก็เคยเจอความต่างนี้อย่างมาก

    • มีเพียง macOS เท่านั้นที่เป็นแพลตฟอร์มที่สร้างแอป native แบบแท้จริงได้ ส่วน Linux แยกระหว่าง GTK/Qt และ Windows ก็มีเฟรมเวิร์กปะปนกันมากจนแม้แต่ WebView ก็ยังดูเหมือน native ได้
    • คำว่า native ที่นี่หมายถึง “ไม่ใช่เว็บ” มันเป็นโครงสร้างที่วาดตรงผ่าน GPU API
    • กล่าวคือเป็น native executable ไม่ใช่การใช้ widget ของ OS
    • ไม่มีการผสานกับ OS และใช้การเรนเดอร์ของตัวเองทั้งหมด

  • สงสัยว่าเฟรมเวิร์กนี้ implement accessibility (a11y) แล้วหรือยัง เพราะ Rust UI มักสวยก็จริง แต่พอมีข้อกำหนดด้าน accessibility เข้ามาก็มักต้องเขียนใหม่ทั้งชุด

    • ถ้าให้ความสำคัญกับ accessibility อาจพิจารณา Dioxus ได้ แม้จะยังไม่มี component library ที่สมบูรณ์ระดับนี้
    • GPUI สร้างอยู่บนพื้นฐานที่ทีม Zed ทำไว้ แต่ก็ยังทึบสำหรับ screen reader หาก accessibility สำคัญ Slint หรือ Qt (cxx-qt) น่าจะดีกว่า และเมื่อ System76 เลือกใช้ Iced ก็คาดว่าฝั่งนั้นก็น่าจะดีขึ้น
    • มีการ implement accessibility แล้ว

  • ฟีเจอร์ virtualized list และ table ยอดเยี่ยมมาก หลาย UI framework ทำให้ต้องไปลงมือทำเองจึงค่อนข้างลำบาก

  • Rust มี GUI toolkit เยอะก็จริง แต่ยังขาด ชุดคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้
    คอลเลกชันนี้ดูมีประโยชน์ แต่รายการคอมโพเนนต์ส่วนใหญ่ก็คล้ายกับของเว็บเฟรมเวิร์ก โดยส่วนที่เฉพาะทาง native มีแค่ webview เท่านั้น เรื่องอย่างกล่องโต้ตอบเปิดไฟล์ก็ยังต้องใช้ไลบรารีภายนอกอย่าง rfd ทำให้ความสอดคล้องของสไตล์เสียไป

    • การที่สไตล์ไม่เหมือนกันกลับเป็น เรื่องดี ผู้ใช้ต้องการความสอดคล้องระหว่างแอป กล่าวคือกล่องโต้ตอบแบบ native ของ OS คุ้นเคยกว่ามาก ซอฟต์แวร์เฉพาะทางอย่าง Blender หรือ Photoshop อาจเป็นข้อยกเว้น แต่สำหรับแอปทั่วไป ผมมองว่า native ดีกว่า
    • ไลบรารี UI ส่วนใหญ่ก็ควรมีอย่างน้อย การผสานกับ native ขั้นพื้นฐาน เช่นคีย์ลัด เมนูระบบ กล่องโต้ตอบไฟล์ หรือเมนูคลิกขวา สิ่งเหล่านี้ช่วยให้ผู้ใช้รู้สึกคุ้นเคยมากขึ้น
    • ตัวเลือกไฟล์ควรใช้ กล่องโต้ตอบพื้นฐานของ OS เท่านั้น ไม่ควรทำขึ้นเอง