XMLUI

(blog.jonudell.net)

2 पॉइंट द्वारा GN⁺ 2025-07-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें

XMLUI Visual Basic के component development model को modern web पर लागू करता है, जिससे React और CSS की जानकारी के बिना भी web app आसानी से विकसित किए जा सकते हैं
XMLUI में अलग-अलग components को XML markup से आसानी से जोड़ा जा सकता है, और यह reactive data binding, theme management, schema extension आदि को support करता है
Model Context Protocol(MCP) के जरिए AI के साथ collaboration कर development efficiency बढ़ाई जा सकती है और code maintainability बेहतर होती है
XMLUI जटिल React ecosystem को सरल बनाकर non-specialists के लिए भी UI और app development आसान बनाता है
Deployment और extension आसान हैं, और React·CSS को अच्छी तरह न जानने वाले developers भी कई तरह के web projects और CMS implementation कर सकते हैं

परिचय और अवलोकन

XMLUI project, 1990s के Visual Basic में दिखने वाले सहज component composition तरीके को web environment में लाने की कोशिश है। उस समय Visual Basic के जरिए non-professional programmers भी अलग-अलग components को जोड़कर उपयोगी software आसानी से बना सकते थे। इसके विपरीत, web environment में इस स्तर की usability या ecosystem पूरी तरह विकसित नहीं हो सका। XMLUI React components और CSS को wrap करता है, और सिर्फ XML form के markup से web app विकसित करने देता है।

नीचे XMLUI code का एक छोटा उदाहरण है:

<App>
  <Select id="lines" initialValue="bakerloo">
    <Items data="https://api.tfl.gov.uk/line/mode/tube/status">;
    </Items>
  </Select>
  <DataSource
    id="tubeStations"
    url="https://api.tfl.gov.uk/Line/{lines.value}/Route/Sequence/inbound";
    resultSelector="stations"/>
  <Table data="{tubeStations}" height="280px">
    <Column bindTo="name" />
    <Column bindTo="modes" />
  </Table>
</App>

सिर्फ लगभग 12 lines के XML से भी नीचे के काम व्यक्त किए जा सकते हैं:

API call के जरिए Select options को अपने-आप भरना
Select की value का उपयोग करके दूसरे API से data लाना
API result से किसी खास field को निकालकर उसे table form में bind करना

XMLUI modern component-based और reactive प्रकृति रखता है, फिर भी user React या CSS की internal knowledge के बिना development और maintenance कर सकता है। यही मौजूदा JavaScript ecosystem की बाधाओं को कम करने वाला इसका अहम अंतर है।

component ecosystem

अतीत और वर्तमान

पुराने Visual Basic दौर में charts, network, data access, media playback जैसे कई building blocks (components) को app में आसानी से जोड़ा जा सकता था। लेकिन ऐसा productive component ecosystem web पर पूरी तरह नहीं आ सका। आज web पर React-based components मुख्य रूप से इस्तेमाल होते हैं, लेकिन अब भी specialist developers की क्षमता की ज़रूरत पड़ती है। XMLUI इन React components को wrap करके उन्हें सभी के लिए आसान बनाता है।

custom components

XMLUI में कई built-in components तो हैं ही, साथ ही खुद component define करके उन्हें ज़रूरत के मुताबिक combine और reuse भी किया जा सकता है। उदाहरण के लिए, London underground stations की जानकारी दिखाने वाला TubeStops component इस तरह define किया जा सकता है:

<Component name="TubeStops">
  <DataSource ... />
  <Text variant="strong">{...}</Text>
  <Table ... >
    <Column ... />
  </Table>
</Component>

TubeStops line नाम के हिसाब से API से data लाकर उसे table form में दिखाता है। असली markup देखने पर readability अच्छी रहती है, और जब code 100 lines से बड़ा हो जाए तो उसे component में refactor करके maintenance आसान किया जा सकता है। हाल के समय में LLM (large language model) की मदद से component refactoring और code maintenance और भी लचीले हो गए हैं।

reactive binding और declarative development

XMLUI में data और UI values में होने वाला बदलाव अपने-आप sync होता है (Reactive Data Binding)। उदाहरण के लिए, Select component की selection बदलते ही उसे reference करने वाला API address (DataSource का url) भी अपने-आप update हो जाता है और नया data फिर से fetch होता है। यह तरीका Excel के cell reference जैसा है।

पुराने imperative development की जगह declarative development paradigm की आदत डालनी होती है, लेकिन एक बार इसकी आदत हो जाए तो तेज़ और सहज development experience मिलता है। उदाहरण के तौर पर, search feature implement करते समय button के बिना सिर्फ input box की value change से data को real-time में sync करके table में reflect करना आसानी से बनाया जा सकता है।

theme system

शुरुआत में theme system पर ज़्यादा ध्यान नहीं था, लेकिन XMLUI की theme management capability बहुत शक्तिशाली है। CSS लिखे बिना भी हर component का color, background, spacing, font आदि variable-based तरीके से एकसमान manage किया जा सकता है। उदाहरण के लिए, button का color context और state (hover आदि) के अनुसार अलग-अलग तय किया जा सकता है।

Theme में color-primary, backgroundColor-Button जैसे रूपों में बारीक control संभव है, और पूरी UI color palette को आसानी से define करके global या granular रूप से लागू किया जा सकता है।

scripting का उपयोग

XMLUI पूरी तरह declarative नहीं है। Visual Basic की तरह simple scripts (मुख्य रूप से JavaScript) का आंशिक उपयोग संभव है, जैसे API response processing (transformResult) या conditional rendering में। यह इतना कठिन नहीं कि केवल experts ही इस्तेमाल कर सकें; सामान्य developers भी इसे पर्याप्त रूप से उपयोग कर सकते हैं।

Model Context Protocol(MCP) और AI collaboration

"अब जब LLM सीधे React app बना सकता है, तो XMLUI का मतलब क्या है?" इस सवाल पर लेखक code accessibility, maintainability, और collaboration के नज़रिए से XMLUI की अहमियत पर ज़ोर देता है।

MCP(Model Context Protocol) ऐसा server उपलब्ध कराता है जिससे LLM जैसे agents XMLUI code/documents/examples को खोज, समझ और cite कर सकें। इससे AI और developer एक ही semantic context में संवाद कर सकते हैं, और code की incremental auto-generation तथा modification को मिलकर coordinate कर सकते हैं।

उदाहरण: किसी specific feature के usage, examples, documents, और use cases पर LLM के साथ तुरंत प्रश्न-उत्तर करते हुए development आगे बढ़ाया जा सकता है

LLM के साथ सही collaboration के लिए guidelines भी दी गई हैं। उदाहरण के लिए, code suggestion से पहले चर्चा करना, सिर्फ documented examples का उपयोग करना, और अनावश्यक styling को सीमित रखना। साथ ही documentation site में "How To" section और MCP integration के जरिए AI के लिए भी आसानी से accessible structure बनाया गया है।

content management और CMS में उपयोग

XMLUI का उपयोग करके website और CMS बनाना भी आसान है, और React या Next.js की जानकारी के बिना भी रोज़मर्रा के page edits और maintenance सरल हो जाते हैं। वास्तव में XMLUI की official site, demo, documentation सब XMLUI से ही बनाए और maintain किए जा रहे हैं।

एक ही document में code, explanation, और live demo सब कुछ दिया जा सकता है, इसलिए यह व्यावहारिक है।

extensibility

मूल रूप से XMLUI कई React components को wrap करता है, लेकिन नए external components को wrap करना भी आसान है। उदाहरण के लिए, advanced document editor Tiptap को XMLUI TableEditor के रूप में आसानी से wrap किया गया। वास्तव में Markdown editing के मुश्किल हिस्से (जैसे tables बनाना) को visual editor से आसानी से हल किया जा सकता है।

इस तरह, पहले जहाँ component और solution developer की भूमिकाएँ साफ़-साफ़ अलग थीं, XMLUI के जरिए सामान्य developers भी उपयोगी UI components को सीधे extend और combine कर सकते हैं।

deployment

XMLUI app का deployment बहुत सरल है।

minimum setup: सिर्फ Main.xmlui, index.html, और XMLUI JS file चाहिए
कोई भी static web server इस्तेमाल किया जा सकता है, और AWS S3 bucket से सीधे चलाया जा सकता है
जटिल server environment ज़रूरी नहीं है, और ज़रूरत पड़ने पर अतिरिक्त local server, CORS proxy आदि भी configure किए जा सकते हैं

सभी के लिए web development

XMLUI के creator Gent Hito ने /n software, CData आदि में development environment की entry barrier कम करने पर लगातार काम किया है।

/n software: network components का आसान उपयोग
CData: data access को सरल बनाना
XMLUI: UI development को सरल बनाना

पिछले लगभग 20 वर्षों में web UI development लगातार अधिक specialized और complex होता गया है, लेकिन XMULI इस तरह design किया गया है कि non-expert solution developers भी अपना UI और app आसानी से बना सकें। वास्तव में इसे CoreSSH से जुड़े dashboard UI जैसे कई उदाहरणों में तुरंत लागू किया जा सकता है।

ऐसे सभी developers के लिए, जो और आसान web app creation environment चाहते हैं—खासकर non-specialist solution builders, junior developers, और backend-focused developers—इसे सक्रिय रूप से recommend किया जाता है।

1 टिप्पणियां

GN⁺ 2025-07-21

Hacker News राय

Jon लंबे समय से इस इंडस्ट्री में हैं, और मैं उनका प्रशंसक हूँ। वे बहुत अनुभव वाले वरिष्ठ व्यक्ति हैं, और उनकी बात सुनना मूल्यवान है। मैं web components का प्रशंसक हूँ, लेकिन मेरा मानना है कि React के प्रमुख होने का कारण यह है कि जो डेवलपर पहले Visual Basic components का अच्छा उपयोग करते थे, उनके लिए यह माहौल आसान नहीं था। यही इस लेख का सबसे महत्वपूर्ण हिस्सा है। तकनीकी व्याख्या भी महत्वपूर्ण है, लेकिन इसने इस बात के मूल कारण को पकड़ा है कि ऐसी कोशिश की ज़रूरत क्यों है। XMLUI ऐसे डेवलपर्स के लिए सही abstraction दे पाएगा या नहीं, यह देखना बाकी है। फिर भी, ऐसी चुनौती को देखना भर ही आनंददायक है
- अभी का कोड केवल JS evergreen browsers में काम करता है। यह कुछ वैसा ही लगता है जैसे पुराना VB केवल Windows और खास DLL installation environment में ही ठीक से चलता था
लगभग 2014 के आसपास Polymer में भी ऐसा ही एक प्रयास था। उदाहरण के लिए, <iron-ajax> जैसे component के जरिए network requests लागू की जाती थीं iron-ajax link। और एक समय Adobe Flex भी बहुत लोकप्रिय था, जो अब Apache Royale के रूप में बचा है Apache Royale link। Microsoft के पास XAML, NetUI, FlexUI भी थे, और Office 2007 UI भी उसी तरह बनाया गया था। सिद्धांत रूप में ये सब शानदार थे, लेकिन व्यवहार में मुझे लगा कि ऐसी markup-based abstractions, शुरुआती लोगों के लिए भी, JSX जैसे code-first approach से कम प्रभावी थीं
- Coldfusion भी था (याद करके सिहरन होती है)
मेरे मन में एक साथ यह विचार आता है कि "हम फिर से HTML का पुनर्निर्माण कर रहे हैं" और यह एहसास भी कि "यह मेरे लिए अभी काम की चीज़ लगती है"। इंसान स्वभाव से बहुआयामी होता है
- Walt Whitman नाम के कवि और उनके काम से परिचय कराने के लिए धन्यवाद। "क्या मैं स्वयं का विरोध करता हूँ? तो ठीक है, मैं स्वयं का विरोध करता हूँ"
- यह सच में बहुत relatable बात है। आखिरकार महत्वपूर्ण यह है कि क्या यह उन लोगों के लिए तुरंत उपयोगी है, जिनके बारे में तुम सोचते हो कि उन्हें इसकी ज़रूरत है
मैंने 7 साल तक Qt C++ के साथ KDE में open source योगदान दिया था। यह तरीका मुझे QtWidgets की .ui files की याद दिलाता है, यानी ऐसे custom UI files जो एक विशेष XML schema का पालन करती हैं। बाद में QML आया, लेकिन मुझे वह सहज नहीं लगा और मेरी रुचि कम हो गई। फिर भी, मुझे अब भी लगता है कि UI definition के लिए XML का इस्तेमाल समझ में आता है, और बड़े पैमाने के environments में इसका अब भी इस्तेमाल होना समझा जा सकता है
- अभी भी लोग केवल C++ और .ui files के साथ Qt का उपयोग करते हैं। उन्हें QML पर जाने का पर्याप्त कारण नहीं लगा
- मैंने सुना है कि Blizzard game launcher भी QT का उपयोग करता है, और मुझे हमेशा लगा है कि Blizzard software का UI polish सर्वोत्तम होता है। अगर कोई और सुझाने लायक Qt projects हों तो जानना चाहूँगा
- wxWidgets या glade files भी उसी संदर्भ में आते हैं
मेरे विचार में सबसे बेहतरीन GUI approach JUCE है। हर UI element एक C++ class होता है, और drawing function अलग होता है। नए UI elements, दूसरे elements को compose करके एक नई class के रूप में बनाए जा सकते हैं, और editor source code अपने आप generate करता है। Buttons आदि में state के अनुसार (hover, pressed, active, disabled आदि) drawing handling के लिए बड़े if…else sections होते हैं। अंदर से यह Metal/OpenGL/DirectX जैसी thin drawing libraries का उपयोग करता है। इस तरह का पूरी तरह imperative approach ताज़गीभरा लगता है। आप कहीं भी breakpoint लगा सकते हैं, और तुरंत देख सकते हैं कि किस parameter के साथ क्या call हो रहा है। Rendering के बीच के results को imdraw में export करना भी आसान है। Font anti-aliasing को छोड़ दें तो लगभग हर platform पर pixel-perfect rendering मिलती है। लेकिन यहाँ जो XML तरीका पेश किया जा रहा है, वह मेरे लिए वही framework-dependent magic है जिससे मैं हमेशा बचना चाहता हूँ। मुझे पूरा भरोसा है कि बस 3 updates के बाद ही layout थोड़ा-थोड़ा बिगड़ने लगेगा। यहाँ user खुद layout नियंत्रित नहीं करता, बल्कि framework की दया पर रहता है। Electron पुरानी technologies (जैसे CSS) के ऊपर बना है, इसलिए ऐसी दिक्कतें कुछ कम होती हैं, वरना layout control में हमेशा परेशानी आती है
- मैंने JUCE इस्तेमाल नहीं किया, लेकिन पुराने Qt के वे दिन याद आते हैं जब सब कुछ C++ classes में होता था। Template languages प्रचलन में हैं, लेकिन class और object composition वाला तरीका मुझे कहीं अधिक readable लगता है। Templates का सबसे बड़ा फायदा शायद बस इतना है: "क्या यह module parent के नीचे सही जगह गया है?"
- काश कोई JUICE और accessibility पर अपना अनुभव साझा करे
- मैं JUCE को गहराई से नहीं जानता, लेकिन JUCE::Component DOM/canvas elements जैसा लगता है, इसलिए इसकी तुलना web platform से की जा सकती है। XMLUI की तुलना शायद JUCE के ऊपर बने declarative UI systems (GUI Magic, JIVE, VITRO) से अधिक उचित होगी। Declarative और imperative UI एक-दूसरे के विरोधी नहीं हैं। SwiftUI, UIKit की तरह दोनों साथ इस्तेमाल होने वाले environments आम हैं
- मैंने JUCE इस्तेमाल नहीं किया, लेकिन imperative approach में, चाहे implementation बड़ी हो जाए, आपको साफ़-साफ़ पता रहता है कि क्या हो रहा है, इसलिए control आसान रहता है। Declarative approach में हमेशा एक escape hatch चाहिए, और यह escape hatch या तो खुद बनानी पड़ती है या उसके आर-पार जाना मुश्किल होता है
- मैंने इसे audio development में 7 साल इस्तेमाल किया, और आजकल cross-platform high-performance GUI/सामान्य apps के लिए बस JUCE का उपयोग करता हूँ। एक बार अगर उपयोगी JUCE -> CI pipeline सेट हो जाए, तो सच में अनंत संभावनाएँ खुल जाती हैं। हालांकि, कभी-कभी मैं सोचता हूँ कि JUCE के सारे GUI code को किसी Lazarus-जैसे frontend में, जैसे LUA में लिखकर, C++ के साथ मिलाकर कोई lua-C++ Frankenstein बना देना भी मज़ेदार होगा
अफ़सोस है कि XSLT का ज़िक्र नहीं किया गया। मुझे लगता है कि जिन लोगों ने पहले XML को style/transform करने पर काम किया है, उन्हें यह समझाने के लिए कि आज की प्रगति कितनी बड़ी छलांग है, यह एक महत्वपूर्ण तत्व है। Jon Udell ने XSLT पर लिखा भी था संदर्भ लिंक, इसलिए लगता है कि शायद इस बार इसे जानबूझकर छोड़ा गया, लेकिन क्यों, यह स्पष्ट नहीं है
- जिन जगहों पर XSLT का उपयोग हुआ, वे ज़्यादातर "ऐसा उलझा हुआ बालों का गुच्छा जिसे मूल लेखक के अलावा कोई छूने से डरता है" जैसी थीं। किसी कारण यह तकनीक complexity trap में फँस जाती है या complexity fetishists को आकर्षित करती है। वैसे भी, मुझे नहीं लगता कि OP जिस लक्ष्य की ओर बढ़ रहा है, उसके लिए यह सही विकल्प है
- ऐतिहासिक संदर्भ की ज़रूरत तो है, लेकिन इस लेख का उद्देश्य अतीत पर ठहरना नहीं, आगे बढ़ना है। मकसद यह है कि इस tool को सीधे इस्तेमाल करके देखा जाए कि UI बनाने में यह productive है या नहीं
- इस लेख में XSLT इतना महत्वपूर्ण नहीं है। असली बात यह समझाना है कि आधुनिक पाठकों के लिए ऐसा tool क्यों उपयोगी हो सकता है। XSLT ऐतिहासिक रूप से संबंधित है, लेकिन यहाँ उसका ज़िक्र विचार को बेहतर ढंग से पहुँचाने में शायद मददगार नहीं होगा
- oleh kiselyov का SXML/SSAX जानने के बाद मैंने XSLT पूरी तरह छोड़ दिया। SSAX मेरे द्वारा इस्तेमाल किए गए XML parsers में सबसे बेहतरीन है
- मेरा पहला XSLT अनुभव sketchers.com था Sketchy Skechers.com। अफ़सोस, लगता है अब उसका उपयोग नहीं होता
मैं हाल में HTML, web components, और signals के आधार पर कुछ ऐसा ही बना रहा हूँ। यह Heximal नाम का प्रोजेक्ट है Heximal link। मुझे लगता है कि अगर HTML के ऊपर expressions, templates, reactivity, और component structure जोड़ा जाए, तो यह बहुत modular और declarative apps या pages बनाने के लिए बेहतरीन आधार बन सकता है। HTML में जोड़ी जाने वाली कई सुविधाएँ standardize भी की जा सकती हैं
- विचार दिलचस्प है, लेकिन mobile (Android+Firefox) पर साइट ठीक से दिखाई नहीं देती
- साइट पढ़ना मुश्किल है। HN app में भी दूसरे comments ठीक से नहीं दिख रहे, इसलिए पता नहीं दूसरे लोग भी यही समस्या झेल रहे हैं या नहीं। mobile Firefox के आधार पर कह रहा हूँ
- mobile पर कुछ text कटा हुआ दिखता है, और zoom करने पर भी ठीक नहीं होता। संदर्भ के लिए बता रहा हूँ
- मुझे लगता है कि यह approach मुख्यधारा बन सकती है। जैसे C++ मुख्यधारा बना, वैसे backward compatibility की ताकत यहाँ बहुत बड़ा लाभ है
मुझे लगता है कि RJSF का uiSchema, jsonSchema model definitions को complement करने वाली presentation layer के रूप में अच्छी दिशा दिखाता है uiSchema Reference link। यह प्रभावशाली ढंग से डिज़ाइन किया गया था, लेकिन इसका व्यापक रूप से न फैलना मुझे उस समय आश्चर्यजनक लगा था
मैं खास तौर पर उन हिस्सों को लेकर उत्साहित हूँ जो अभी दिखाई नहीं दे रहे। मजबूत engineering के अलावा, ऐसा लगता है कि WYSIWYG programmers (जो सहज रूप से UI बनाते हैं) के लिए इसमें सचमुच सोच-विचार किया गया है। मुझे लगता है कि बचपन में Visual Basic की वजह से मैं programming तक पहुँच पाया। C++ के जटिल pointers के बिना भी बहुत कुछ आसान और जादुई तरीके से किया जा सकता था, और मैं चाहता हूँ कि यही प्रवाह web programming में भी beginner-first approach के रूप में आए, जहाँ responsiveness और smoothness से समझौता किए बिना उचित व्यावहारिक संतुलन बने। और भी दिलचस्प है https://docs.xmlui.com/mcp। Claude जैसे tools जब UX/dashboard code generate करते हैं, तो यह ज़रूरी tokens की संख्या घटाकर अधिक concise code बना सकता है। मैं आज से ही इसे आज़माने वाला हूँ
- इस्तेमाल का अनुभव ज़रूर बताना
XAML (खासकर उसका सीमित दायरे वाला Silverlight version), अगर अच्छे से इस्तेमाल किया जाए, तो सचमुच बहुत आनंददायक tool था। लेकिन अगर उसे सबसे आसान और सबसे स्पष्ट (और साथ ही अक्षम) तरीके से इस्तेमाल किया जाए, तो वह भयानक भी हो सकता था। शायद HTML5 या tooling की कमी की वजह से उसे भुला दिया गया। अच्छे tools को beginners को भी सफलता तक पहुँचाना चाहिए, और XAML इस मामले में कमजोर था