Rust क्रॉस-प्लैटफ़ॉर्म GPUI कंपोनेंट

 (github.com/longbridge)
18 पॉइंट द्वारा GN⁺ 2025-10-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust-आधारित GPUI framework का उपयोग करके cross-platform desktop applications बनाने के लिए UI component library
  • 60 से अधिक native-style UI components उपलब्ध कराती है, और macOS·Windows की design sensibility को shadcn/ui की आधुनिक aesthetics के साथ जोड़ती है
  • virtualized table, high-performance code editor, Markdown/HTML rendering, chart visualization जैसी समृद्ध सुविधाएँ अंतर्निहित हैं
  • theme system, multilingual support (i18n), docking layout आदि के साथ scalability और customization पर ज़ोर देने वाला डिज़ाइन
  • Rust ecosystem में Iced, egui, Qt आदि की तुलना में आधुनिक UI style और बड़े पैमाने के data processing performance में अलग पहचान

प्रोजेक्ट अवलोकन

  • gpui-component Rust में लिखा गया cross-platform desktop UI components का संग्रह है, जो GPUI render engine पर आधारित है
    • इसका लक्ष्य “fantastic desktop applications” को तेज़ और एकसमान तरीके से बनाना संभव करना है
    • आधिकारिक साइट: longbridge.github.io/gpui-component
  • Apache-2.0 license

प्रमुख सुविधाएँ

  • समृद्ध component composition: 60 से अधिक UI elements शामिल हैं, जिनमें button, list, table, chart, editor आदि जैसे विभिन्न building blocks उपलब्ध हैं
  • native-feel design: macOS और Windows के default controls से प्रेरित होकर shadcn/ui style के साथ आधुनिक interface लागू करता है
  • सरल usability: stateless RenderOnce component structure के कारण सरल और intuitive code लिखना संभव
  • theme और color system: Theme और ThemeColor के माध्यम से multi-theme और variable-based configuration का समर्थन
  • लचीला layout: Dock layout के जरिए panel placement, resizing और स्वतंत्र tiled composition संभव
  • high-performance rendering: Virtualized Table/List के माध्यम से बड़े data को भी smoothly प्रदर्शित करता है
  • content rendering: Markdown और सरल HTML के लिए native support
  • chart features: built-in charts के साथ data visualization संभव
  • code editor: अधिकतम 2 लाख lines तक समर्थित LSP-based high-performance code editor शामिल
    • diagnostics, autocomplete, hover जैसी सुविधाओं का समर्थन
  • syntax highlighting: Tree Sitter का उपयोग करके editor और Markdown दोनों में syntax highlighting प्रदान करता है

tech stack और आँकड़े

  • language composition: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
  • repository metrics: 5.4k stars, 223 forks, 45 से अधिक contributors
  • latest release: v0.3.1 (27 अक्टूबर 2025)

संक्षिप्त महत्व

  • gpui-component को Rust ecosystem में आधुनिक UI/UX और high-performance rendering को जोड़ने वाले नए desktop UI framework के रूप में देखा जा रहा है
  • यह मौजूदा Rust GUI frameworks की सीमाओं को पूरक करता है और large-scale data processing·theming·Markdown integration जैसी practical सुविधाएँ प्रदान करता है
  • आगे चलकर Rust-आधारित cross-platform app development के लिए standardized UI layer के संभावित उम्मीदवार के रूप में ध्यान आकर्षित कर रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-28
Hacker News की राय

  • Rust UI ecosystem में यह अब तक देखे गए सबसे polished component collections में से एक लगता है
    अभी इसके use cases लगभग नहीं के बराबर हैं, लेकिन documentation धीरे-धीरे बेहतर तरीके से व्यवस्थित हो रही है
    इसी तरह अच्छी तरह तैयार दूसरे उदाहरण के रूप में fyrox-ui है। हालांकि fyrox engine के बाहर इसका लगभग इस्तेमाल नहीं होता
    Rust UI अब धीरे-धीरे mature हो रहा है, लेकिन iced, egui, dioxus, slint जैसे लोकप्रिय frameworks component completeness के मामले में अभी भी कमज़ोर लगते हैं
    अपडेट के तौर पर, यह project Rust UI ecosystem में बड़ी प्रगति दिखाता है।
    सभी components देखने के लिए widget gallery app को यहाँ चलाया जा सकता है — cargo run --release से सीधे चल जाता है

    • gpui, Zed Editor से अलग किया गया project है, इसलिए इसका वास्तविक उपयोग शायद दूसरे Rust UI crates की तुलना में काफ़ी ज़्यादा होगा
    • Fyrox, Rust game development को लेकर संदेह पैदा करता है। सबसे mature engine होने के बावजूद कोई इसका इस्तेमाल नहीं करता। दूसरी ओर लोग सिर्फ़ Bevy के ECS को लेकर उत्साहित हैं। आखिरकार लगता है कि लोगों की दिलचस्पी सिर्फ़ system में थी, असली games बनाने में नहीं
    • Rust UI frameworks अभी भी तेज़ी से बदल रहे हैं, इसलिए शायद उनकी completeness कम लगती है। फिर भी momentum साफ़ दिखता है। यह सिर्फ़ मेरा अनुभव है, लेकिन मैं पहले ही Rust से enterprise-grade UI बना चुका हूँ
    • मैंने Longbridge app ख़ुद install करके देखा, और यह सच में Mac native app की तरह स्वाभाविक रूप से चलता है। Electron की तुलना में काफ़ी ज़्यादा smooth है
    • Widget gallery app प्रभावशाली है, लेकिन इसमें 900 से ज़्यादा dependencies होना थोड़ा चिंता की बात है। GUI apps में यह सामान्य है या नहीं, यह पक्का नहीं कह सकता

  • सबसे simple example में भी 1000 से ज़्यादा dependencies हैं। यह GTK, GDK, pango जैसे toolkits पर निर्भर है। दूसरे toolkits पर फिर से निर्भर होने वाली यह संरचना कुछ अजीब लगती है

    • GNOME ने server-side decoration implement नहीं किया है, इसलिए libadwaita पर निर्भर होना पड़ता है। शायद यही GTK से जुड़ी सारी dependencies को खींच लाता है
    • Linux में ऐसी संरचना आम है। ऊपरी window या menu draw करने के लिए GTK या Qt का इस्तेमाल करना सामान्य बात है
    • मेरे हिसाब से छोटी और composable 1000 dependencies बेहतर हैं। एक विशाल single codebase की तुलना में उनका audit करना कहीं आसान है
    • अफ़सोस है कि आजकल Rust projects धीरे-धीरे इसी तरह बड़े होते जा रहे हैं

  • यह थोड़ा कड़वा लगता है कि open source की कई बुनियादी technologies trading और crypto कंपनियों से आ रही हैं। फिर भी समाज को कुछ वापस देने के लिहाज़ से यह सकारात्मक है

    • gpui को Zed.dev टीम maintain करती है, और Longbridge एक सामान्य brokerage company लगती है जो Longbridge Pro app बनाती है। इसमें विशेष रूप से कुछ ग़लत नहीं दिखता
    • मुझे लगता है Bitcoin की भावना hacker culture से मिलती-जुलती है। यानी “जो टूटा है उसे ठीक करो” वाला रवैया। अल्पकालिक दर्द लंबे समय के फ़ायदे में बदल सकता है
    • Rust या OCaml(Jane Street) जैसे कुछ ecosystems में यह रुझान दिखता है, लेकिन कुल मिलाकर यह दावा बढ़ा-चढ़ाकर कहा गया लगता है
    • React बनाने वाली Facebook का नाम Cambridge Analytica scandal और Rohingya genocide जैसी घटनाओं से जुड़ा रहा है। उस नज़रिए से देखें तो trading/crypto कंपनियों का open source में योगदान करना शायद नैतिक रूप से बेहतर माना जा सकता है

  • जिज्ञासा है कि आजकल के “modern” UI toolkits में visual UI editor नहीं होते क्या
    Qt में QtCreator या QtDesigner जैसे tools के ज़रिए सिर्फ़ drag-and-drop से UI बनाया जा सकता था
    और Qt से जुड़े comparison table के कुछ बिंदु ग़लत हैं — जैसे minimum binary size या QSyntaxHighlighter के बारे में विवरण

    • Slint जैसे frameworks Figma integration देते हैं, इसलिए उन्हें Qt Design Studio की तरह इस्तेमाल किया जा सकता है। लगता है कि आजकल लोगों को यह अंदाज़ा नहीं कि पुराने native GUI designers कितने शक्तिशाली थे
    • अगर अच्छी तरह तैयार component library हो, तो Rust में ऐसे visual editor भी बनाए जा सकते हैं। XML/markup आधारित संरचना को macros से जोड़कर और real-time preview app बनाकर उसे Glade या XAML की तरह चलाया जा सकता है
    • Qt का minimum size वास्तव में 20MB से कम हो सकता है, लेकिन आम तौर पर यह 30~40MB के आसपास होता है। Core, Gui, QML, Widget modules हर एक लगभग 8MB के होते हैं, इसलिए Hello World के लिए भी 2~3 modules चाहिए होते हैं
    • Qt Designer साधारण UI के लिए ठीक है, लेकिन custom styling लागू करते ही जल्दी टूटने लगता है। इसलिए अंत में मैंने UI files manually लिखीं। वे कहीं ज़्यादा साफ़ और छोटी निकलीं
    • यह दावा कि Qt6 theme support नहीं देता, पूरी तरह ग़लत है

  • दुर्भाग्य से यह एक framework है। यानी इसका अपना event loop होना ज़रूरी है
    जहाँ पहले से कोई दूसरा loop हो, वहाँ integration मुश्किल हो जाता है। इसके विपरीत egui सिर्फ़ हर frame पर call होने वाली library-style structure है

  • जानना चाहता हूँ कि दृष्टिबाधित उपयोगकर्ताओं के लिए screen reader accessibility ठीक से काम करती है या नहीं

    • मैंने ख़ुद इसे चलाकर नहीं देखा, लेकिन official docs के अनुसार यह ARIA spec को support करता है। बस ज़रूरी labels और descriptions जोड़ने होते हैं
    • लेकिन Zed Editor, screen reader के लिए पूरी तरह अपारदर्शी है। इसलिए ज़्यादा उम्मीद नहीं है
    • जब भी मैं कोई नया UI framework देखता हूँ, मेरा पहला सवाल accessibility को लेकर ही होता है

  • यहाँ “native” का मतलब web नहीं है, या फिर OS के default widgets का इस्तेमाल है, यह जानने की जिज्ञासा है। Java ecosystem ने भी इस फ़र्क़ को काफ़ी झेला था

    • macOS ही शायद सचमुच native apps बनाने वाला platform है। Linux, GTK/Qt में बँटा हुआ है, और Windows में इतने frameworks मिले-जुले हैं कि WebView भी native जैसा लग सकता है
    • यहाँ native का मतलब “web नहीं” है। यानी यह GPU API से सीधे drawing करने वाली संरचना है
    • यानी यह native executable है, OS widgets का उपयोग नहीं करता
    • इसमें OS integration नहीं है, पूरी तरह self-rendering approach है

  • जिज्ञासा है कि क्या इस framework ने accessibility(a11y) implement की है। Rust UI अक्सर देखने में सुंदर होते हैं, लेकिन accessibility की ज़रूरत आते ही उन्हें पूरी तरह फिर से लिखना पड़ता है

    • अगर accessibility महत्वपूर्ण है, तो Dioxus पर विचार किया जा सकता है। हालाँकि इस स्तर की polished component library अभी वहाँ भी नहीं है
    • GPUI, Zed टीम द्वारा बनाए गए आधार पर है, लेकिन screen reader के लिए अब भी opaque है। अगर accessibility ज़रूरी है, तो Slint या Qt(cxx-qt) बेहतर विकल्प हैं, और System76 ने Iced को अपनाया है, इसलिए उस दिशा में भी सुधार हो सकता है
    • accessibility implement की गई है

  • Virtualized lists और tables की सुविधा वास्तव में शानदार है। कई UI frameworks में इसे ख़ुद implement करना पड़ता है, जो असुविधाजनक है

  • Rust में GUI toolkits तो बहुत हैं, लेकिन reusable component collections की कमी है
    यह collection उपयोगी लगता है, लेकिन इसके अधिकांश components web frameworks की component lists जैसे ही हैं। native के लिए ख़ास चीज़ों में सिर्फ़ webview जैसा कुछ दिखता है। open file dialog जैसी चीज़ों के लिए rfd जैसी external libraries का इस्तेमाल करना पड़ता है, जिससे style consistency टूट जाती है

    • style consistency टूटना उल्टा अच्छी बात है। उपयोगकर्ता apps के बीच consistency चाहते हैं। यानी OS native dialogs ज़्यादा परिचित लगते हैं। Blender या Photoshop जैसे professional software अपवाद हो सकते हैं, लेकिन सामान्य apps के लिए native बेहतर है
    • ज़्यादातर UI libraries को कम-से-कम कुछ native integration तो चाहिए ही। जैसे shortcuts, system menu, file dialogs, context menus वगैरह। यही चीज़ें apps को उपयोगकर्ता के लिए ज़्यादा परिचित बनाती हैं
    • file picker के लिए हमेशा OS का default dialog इस्तेमाल करना चाहिए। उसे ख़ुद implement करना अच्छी बात नहीं है