XSLT - वेब के लिए Native, Zero-Config बिल्ड सिस्टम

 (github.com/pacocoursey)
2 पॉइंट द्वारा GN⁺ 2025-06-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • XSLT एक बिल्ट-इन बिल्ड टूल है जिसे वेब के लिए बिना किसी जटिल बिल्ड सिस्टम के तुरंत इस्तेमाल किया जा सकता है
  • ज़्यादातर static site build systems में जटिलता, समझने में कठिनाई और framework dependency जैसी समस्याएँ होती हैं
  • XML और XSLT का उपयोग करके ब्राउज़र में सीधे HTML बनाया जा सकता है, जिससे dynamic data processing और markup generation आसान हो जाती है
  • सभी प्रमुख ब्राउज़र XSLT-आधारित transformations को सपोर्ट करते हैं, इसलिए अतिरिक्त JavaScript या अलग टूल के बिना इसका उपयोग संभव है
  • यह कोई परफेक्ट समाधान नहीं है, लेकिन web standards पर आधारित एक simple और flexible alternative के रूप में इसकी उपयोगिता काफ़ी अधिक है

परिचय और समस्या की समझ

  • अधिकांश static websites के development की प्रक्रिया data files(.json, .md, .txt), एक अलग build system(Hugo, Next.js, Astro आदि) और HTML output structure से मिलकर बनती है
  • build systems में जटिलता बढ़ती जाती है, और छोटा-सा ब्लॉग भी समय के साथ समझने और चलाने में कठिन होता जाता है
  • जब frameworks को हटाकर सिर्फ़ साधारण HTML, CSS और standard specs(HTTP, URI, HTML) के साथ काम करने की कोशिश की जाती है, तो header या footer की पुनरावृत्ति जैसी maintenance सीमाएँ सामने आती हैं
  • HTML import, web component जैसी चीज़ें भी आज़माई गईं, लेकिन पहले वाले को support नहीं मिला और दूसरे वाले में JavaScript engine dependency की समस्या होने से वे उचित विकल्प नहीं बन सके

वेब ब्राउज़र को बिल्ड सिस्टम के रूप में

  • ध्यान इस बात पर गया कि वेब ब्राउज़र स्वयं कई तरह के data transformations (text/html, text/markdown, application/xml आदि) को सपोर्ट करता है
  • web specs को गहराई से देखकर, अनावश्यक external tools और frameworks के बिना समस्या का समाधान खोजने पर विचार किया गया

XSLT का उपयोग

  • RSS feed को सुंदर ढंग से दिखाना चाहा, और इसी दौरान XSLT spec पर नज़र पड़ी
  • XSLT एक आधिकारिक standard technology है जो XML data और HTML output structure दोनों को express कर सकती है
  • इसे इस्तेमाल करने का तरीका सरल है
    • उदाहरण के लिए blog.xml में data व्यवस्थित करें
    • फिर इस तरह XSLT stylesheet जोड़ें
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • blog.xsl में HTML templates और data mapping rules लिखें
  • templates, loops, variables, external file import जैसी अधिकांश build system features इसमें उपलब्ध हैं

उपयोग का तरीका और फायदे

  • अलग टूल के बिना XML file को सिर्फ़ वेब ब्राउज़र में खोलने भर से transformation result तुरंत render हो जाता है
  • XML format, HTML जैसा होने के कारण मानव-पठनीय और maintain करने में आसान है, और JSON की जगह इस्तेमाल करने पर भी ज़्यादा असुविधा नहीं होती
  • सभी प्रमुख वेब ब्राउज़र XSLT-आधारित transformations को native रूप से support करते हैं, इसलिए client स्वयं transformation result देख सकता है
  • JavaScript, अलग build tools या bundler की ज़रूरत नहीं होना इसकी बहुत बड़ी विशेषता है
  • XSLT कोई अंतिम सर्व-समाधान नहीं है, लेकिन simple और scalable web build alternative के रूप में यह काफ़ी उपयोगी है

निष्कर्ष

  • पुरानी तकनीक (XSLT) और स्पष्ट standards के मूल्य को फिर से खोजने की बात सामने आती है
  • वेब ब्राउज़र को build system की तरह इस्तेमाल करने का तरीका वेब development toolbox में जोड़े जाने लायक एक उपयोगी विकल्प है

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

1 टिप्पणियां

 
GN⁺ 2025-06-28
Hacker News राय

  • जिस कंपनी में मैं काम करता था, वहाँ XML templates में XSLT का बहुत ज़्यादा इस्तेमाल होता था, और शायद आज भी होता हो। ईमानदारी से कहूँ तो यह अच्छा विकल्प नहीं था, और मौका मिलता तो वे शायद किसी और चीज़ पर migrate करना चाहते

    1. XSLT का नया standard मौजूद है, फिर भी अब भी 1.0 version ही सबसे ज़्यादा इस्तेमाल होता है, और यह version नए standards की तुलना में सीमित और कई जगह अजीब है
    2. XSLT templates की performance समस्याएँ हल करना बेहद मुश्किल होता है। XSLT एक Turing-complete functional-style language है, इसलिए performance का अंदाज़ा लगाना आसान नहीं। ज़्यादातर documents पर सब ठीक रहता है, लेकिन जैसे ही 100 rows आ जाएँ, सब टूट सकता है। Table process करने वाला code O(N^2) performance रखता हो सकता है, और optimization भी लगभग नामुमकिन हो जाता है। उदाहरण के लिए, हर row में O(N) वाला XPath हो सकता है। जहाँ तक मुझे याद है, उस template को एक document process करने में 7 मिनट से ज़्यादा लगते थे।
      JS में भी समस्याएँ हैं, लेकिन कम से कम ऐसी algorithmic complexity वाली स्थिति तो नहीं होती जिसे आप ठीक ही न कर सकें

    • XSLT/XPath ने 1.0 के बाद काफ़ी प्रगति की है। key(index) जैसी कई सुविधाएँ आईं, जिससे processing speed बहुत बढ़ी। अगर Saxon जैसे अच्छी quality वाले XSLT implementation का उपयोग करें तो performance issues भी काफ़ी कम हो जाते हैं। XML को किसी और format में बदलने के लिए XSLT जितना logically structured tool बहुत कम मिलता है

    • XSLT सीखना काफ़ी मुश्किल है। यह किसी स्वप्निल Prolog जैसा लगता है, और अगर आप इसमें बहुत निपुण हो जाएँ तो Sudoku हल करने जैसा रोमांच मिलता है। लेकिन ज़्यादातर मामलों में इतनी जटिल templates की ज़रूरत नहीं होती, इसलिए यह standard choice बनना मुश्किल है। और XML खुद भी ऐसा format नहीं है जिसे हर कोई पसंद करता हो

    • यह बात समझ नहीं आती कि XSLT 1.0 अब भी इतना इस्तेमाल क्यों होता है। 2013 में भी 1.0 को लगभग पुराना माना जाता था, और XSLT 2 चलाने वाला Saxon मुफ़्त था और उसकी performance भी बहुत अच्छी थी। बड़े या छोटे documents transform करते समय मुझे कभी performance issue नहीं मिला

    • XSLT जिस दौर में आया था, उस समय बहुत लंबे XML documents को process करना सामान्य बात थी। लेकिन जब ऐसे nested loops हो जाएँ तो चीज़ें टूटना स्वाभाविक ही है

    • क्या आप commercial version of Saxon इस्तेमाल कर रहे हैं? इसकी कीमत भी बहुत ज़्यादा नहीं है, और नए standards support, performance और features की वजह से IMHO यह पूरी तरह पैसे वसूल choice है। जब मैंने इसे पहले इस्तेमाल किया था, तब मुझे याद है कि इसमें काफ़ी smart optimizations थे

  • 90-00 के दशक में browsers एक-दूसरे से बहुत अलग थे, इसलिए JS लाकर उनके behavior को मिलाना शुरू किया गया
    असल में हम जो चाहते थे वह अच्छे CSS styles थे, लेकिन उस समय उन्हें ठीक से इस्तेमाल नहीं कर सकते थे
    समय के साथ एक browser ने बढ़त बना ली और बाकी browsers भी काफी हद तक उससे मिलते-जुलते हो गए (Highlander नियम, हालाँकि Firefox भी अच्छा टिके हुए है)
    Frameworks पहले से ही सामान्य हो चुके थे, इसलिए वे सभी browsers में एक जैसा UI देने के साधन के रूप में स्थापित हो गए। और paradigm खुद JSON data rendering की ओर चला गया
    अब ऐसा दौर है कि server पर traditional webpages generate करना तेज़ भी है और कम memory भी लेता है
    मैं यह इसलिए कह रहा हूँ क्योंकि हाल ही में legacy system से migration करते हुए मुझे फिर से page-by-page HTTP request वाले sites देखने पड़े, जो 2000s standard थे। हर action पर refresh चाहिए था, लेकिन फिर भी वे React वाले systems से कहीं तेज़ थे
    इसकी वजहें थीं

    1. इंटरनेट बहुत तेज़ हो चुका है
    2. फ़ोन में memory बहुत है, लेकिन JS frameworks उसे बर्बाद करते हैं
    3. Backend पहले भी CRUD, CRUD, CRUD(+pagination, +transactions) था और अब भी वही है

    • AJAX और DOM updates सिर्फ़ चीज़ों को तेज़ बनाने के लिए नहीं आए थे। वे web के paradigm, यानी 'website/web document' से आगे जाने के लिए थे। Full page reload document-centric paradigm में अर्थपूर्ण तरीका है। HN जैसे सरल उदाहरणों में यह structure बहुत अच्छी तरह काम करता है। बहुत सी sites JS frameworks के बिना भी इसी structure पर ठीक चल सकती हैं।
      लेकिन "सब लोग फिर से full page reload पर लौट सकते हैं" कहना वास्तविकता से दूर है। वास्तव में जिन 'web applications' में जटिल interactions चाहिए, उनमें full page reload बहुत खराब UX है।
      संक्षेप में,
      'websites', 'web documents', 'simple forms' जैसी चीज़ों के लिए full page reload काफ़ी हो सकता है, लेकिन
      'web applications' की तरह जहाँ जटिल data views और manipulations चाहिए, वहाँ यह पर्याप्त नहीं है

    • उस समय की timeline मुझे कुछ अलग याद है। JS का उपयोग browsers को एक जैसा बनाने से ज़्यादा interactive elements के लिए शुरू से किया गया था (DHTML, AJAX आदि)। सच में layout बनाना browser-specific hacks और user-agent detection पर बहुत निर्भर था। CSS अधिक शक्तिशाली होने के बाद भी consistency की समस्या जल्दी हल नहीं हुई। CSS garden, semantic markup, tables का अत्यधिक उपयोग—वही उस दौर का माहौल था, और पहला ACID test pass होने में भी बहुत समय लगा। मुझे शक है कि frameworks ने UI consistency पर कितना असर डाला—jQuery के बाद से तो CSS खुद visual consistency का मुख्य कारण था।
      हालाँकि, यह मेरी व्यक्तिगत याद भी हो सकती है

    • आधुनिक tech stack में server-rendered traditional webpages तेज़ और lightweight होते हैं, इससे मैं सहमत हूँ
      मेरे .NET/Kestrel/SQLite stack में SSR response को 4ms से ऊपर ले जाना मुश्किल है। ज़्यादातर responses 100 microseconds के दायरे में होते हैं। हर page पर कई queries और complex joins के साथ view के अनुसार data shape बनाया जाता है
      100,000 rows वाली table जैसे extreme case में भी, अगर HTML string जोड़ने से पहले data processing अच्छी तरह कर ली जाए तो performance काफ़ी बढ़ जाती है। LINQ की performance भी शानदार है, लेकिन अगर हर row पर collection बनाए जाएँ तो data बढ़ने के साथ यह बहुत अक्षम हो जाता है
      मेरे अनुभव में HTML template engine और database को जितना संभव हो उतना पास रखना performance optimization के लिए सबसे अच्छा रहा है। आखिर में DOM सिर्फ़ एक byte stream है। बेवजह complex AST/parser बनाने से बेहतर है StringBuilder और SQL queries का उपयोग।
      इस तरह की सादगी के ख़िलाफ़ हमेशा वही तर्क आता था: "developers पर HTML escaping के लिए भरोसा नहीं किया जा सकता", यानी security टीम की बहस

    • "आधुनिक तकनीक के साथ server पर पुराने ढंग की classic webpages काफ़ी हैं"—यह बात high network latency होने पर बिल्कुल अलग हो सकती है
      संदर्भ लिंक

  • 2000s में enterprise XML इतना bloated हो गया था कि तकनीक outdated लगने लगी, और फिर सब लोग JSON की 'cleanliness' पर मोहित हो गए। सच यह है कि XSLT और XPath जैसी technologies पहले से काफ़ी mature थीं और आज भी जिन समस्याओं पर हम सोचते हैं, उनमें से बहुत-सी वे पहले ही हल कर चुकी थीं
    मैंने भी पहले XSLT include का बहुत दुरुपयोग किया है; PHP stream wrapper के साथ <xsl:include href="mycorp://invoice/1234"> जैसी चीज़ें इस्तेमाल करता था
    सच कहूँ तो अब यह थोड़ा पुराना एहसास देता है, लेकिन browser पर local XSLT processing कराना अब भी असहज लगता है। पहले यह compatibility minefield हुआ करता था

    • XML की "basic" खूबियाँ आज भी JSON में याद आती हैं। जैसे सचमुच standardized spec या schema definition—इन मामलों में XML बहुत आगे था, और JSON को वहाँ तक पहुँचने में लगभग 10 साल लग गए
      आख़िरी बार मैंने XML को EXI नाम की transport technology में ठीक से इस्तेमाल किया था। यह XML documents को compressed binary stream में बदल देती थी, लेकिन structure ↔ ASCII conversion ↔ compression/transmission ↔ reverse conversion, यह सब काफ़ी झंझट भरा था। आज protobuf और gRPC मुख्यधारा में हैं, लेकिन अगर XML चलता रहता तो शायद एक ऐसा संसार बनता जहाँ सब कुछ compatible, standards-based होता—कम से कम मेरी आदर्श कल्पना में। हालाँकि वास्तविकता यह है कि protobuf/gRPC और JSON API के बीच भारी दीवारें बन गईं, और शायद वही बेहतर निकला

    • मुझे XML एक ठीक-ठाक format लगता है। यह लंबा और verbose है, लेकिन YAML की तुलना में precision और expressiveness में बहुत बेहतर है
      XPath की आदत डालना मुश्किल है, लेकिन प्रयोग करें तो अंततः आप जो चाहते हैं वह कर सकते हैं
      XSLT पूरी तरह पागलपन भरा विचार लगता है। इसे हटा देना चाहिए

    • Rimworld नाम का game अपनी सारी settings data XML में store करता है, और XPath से modding संभव बनाता है। यह combination सचमुच बहुत शक्तिशाली है। Local data customization के लिए इससे बेहतर कुछ नहीं। लेकिन ज़्यादातर games शायद XML के "पुराने" टैग के कारण ऐसा करना नहीं चाहते
      Rimworld का आधिकारिक XPath modding दस्तावेज़

    • 2000s की शुरुआत का enterprise XML bloated था—यह बात सच है। XML मूलतः SGML का सरल रूप था ताकि web पर markup transport और vocabulary extension हो सके। आखिरकार सिर्फ़ SVG और MathML ही बचे। Web boom के दौरान W3C/MS ने SOAP, WS-* specs जैसी चीज़ें बहुत ज़्यादा मात्रा में निकालीं। एक समय ऐसा भी था जब Scheme की हड्डियों वाली languages जैसे XSLT को भी XML में ज़बरदस्ती ढाला गया। यहाँ तक कि JavaScript का नाम भी Java की तर्ज़ पर रखा गया था—वह भी वैसा ही दौर था

    • Xpath में namespaces की वजह से इतना लंबा query लिखना पड़ता है कि थकान होने लगती है

  • मैं आज भी XSLT से अपने feeds को style करता हूँ।
    RSS feed sample
    XSLT sample

    • यह देखकर लगता है कि क्या blog असल में सिर्फ़ RSS feeds ही होने चाहिए थे

    • मैं हमेशा भूल जाता हूँ कि XML मूल रूप से ऐसा कर सकता है। किसी वजह से यह सहज नहीं लगता

    • यह सचमुच बहुत शानदार बनाया गया है। अच्छा होगा अगर और लोग भी ऐसे examples को रचनात्मक तरीके से अपनाएँ

  • अपनी पहली नौकरी में (19 साल की उम्र में) मुझे Google Search Appliance customize करने का काम मिला था। हम उन पीले Dell servers पर, जिनकी कीमत लाखों में थी, CentOS डालते थे और Google-जैसी Python, CIFS document full-text search जैसी चीज़ें लागू करते थे।
    2011 के आसपास XHTML का दौर था, और Google Search Appliance backend XML data को XSLT से XHTML में transform करता था। मैंने sample templates तोड़-मरोड़कर intranet के लिए अजीब UI बनाए, और Coldfusion, StackOverflow, W3Schools जैसी मौजूदा चीज़ों को जोड़-तोड़कर ठूँस दिया
    यह अनुभव मैंने जल्दी ही अपने résumé से हटा दिया। बाद में DoD contractors मुझे बार-बार "XML expert" समझकर document system modernization projects के लिए बुलाने लगे, और वह काफ़ी थकाऊ था
    अगली बार जब आप JSX के साथ JSON से TypeScript interfaces बनाते हुए arrays पर loop चलाकर आहें भरें, तो मेरी कहानी याद करना। कम से कम वह XSLT में वही काम करने से बेहतर है

  • मैं सचमुच simplicity पसंद करने वाला इंसान हूँ। मुझे आदिम readme जैसी आसान documentation पसंद है। कभी-कभी खुद को आदिमानव की तरह keyboard पीटते हुए भी महसूस करता हूँ। मैं websites नहीं बनाता और XSLT भी ज़्यादा नहीं जानता। कभी-कभी XML के साथ थोड़ा hacking करता हूँ और users को कुछ दिखाना चाहता हूँ। File formats बहुत ज़्यादा हैं, दिमाग दुखने लगता है। फिर भी मुझे सुंदर चीज़ें पसंद हैं। शायद मैं भी इसे इस्तेमाल करूँ
    spec पढ़ने के लिए धन्यवाद, और tool बनाने के लिए भी धन्यवाद

  • लोग कहते हैं XML verbose और जटिल लगता है, लेकिन जब आप इसे वास्तव में इस्तेमाल करते हैं तो यह शानदार format है
    DTD से validation कर सकते हैं और XSLT से output को इंसानों के लिए पठनीय बना सकते हैं
    मेरे लिए XML किसी text format का C++ है। mature, 'batteries included', powerful, और लगभग किसी भी language से जुड़ सकने वाला
    जैसे पुरानी mature languages के साथ होता है, वैसे ही XML को भी लोग अजीब content कहकर ट्रोल करना trend बना चुके हैं—यह थोड़ा दुखद है। अगर काम के लिए सही न हो तो मत इस्तेमाल करें, लेकिन इतनी नफ़रत की भी ज़रूरत नहीं

    • DTD की जगह XSD क्यों नहीं इस्तेमाल करते, यह जानने की जिज्ञासा है

  • यह बात कि "browser में XSLT सीधे चलता है" मुझे चकित करती है। मैंने आख़िरी बार XSLT 20 साल पहले इस्तेमाल किया था, और तब भारी enterprise Java के नीचे उसकी अपनी सुंदरता दब सी जाती थी।
    लेकिन अगर XSLT browser में default से चलता है, तो क्या बिना किसी host framework के असली static templates की holy grail हमारे सामने ही थी?

    • Browsers सिर्फ़ XSLT 1.0 support करते हैं। और यह भी कहा जा रहा है कि शायद भविष्य में यह भी हट सकता है। अफ़सोस है—अगर browsers 3.0 तक support दें, तो static webpage generation के लिए यह बहुत काम का हो सकता है

    • ऐसा भी अनुभव रहा है जहाँ 'विशाल enterprise Java tower' की ज़रूरत नहीं पड़ी। हमने सिर्फ़ tomcat और कुछ apache libraries के साथ काम किया, और यह काफ़ी अच्छा चला। CMS से XML में बना HTML लिया जाता था, personalization XML tags के रूप में डाली जाती थी, और server-side caching proxy की वजह से transforms तेज़ थे, इसलिए भारी traffic भी संभाला जा सकता था। असली बात यह थी कि XSLT output stream को तुरंत client तक भेज दिया जाए और पूरे output को memory में buffer न किया जाए।
      आज wasm के कारण browser में लगभग कुछ भी चलाया जा सकता है, लेकिन शुरुआती JS बहुत कमज़ोर था, और designers से अगर Photoshop PSD सही-सलामत मिल जाए तो वही बहुत था। Google Maps और Gmail के समय जो javascript-heavy UI बनाए जाते थे, और साथ में Netscape व Internet Explorer दोनों को support करना पड़ता था—वह सचमुच नर्क था

    • XHTML का उभार भी असल में इसी 'static template holy grail' के कारण शुरू हुआ था। लेकिन जो लोग सच में जानते थे, वे इसे लगभग किसी गुप्त slang की तरह आधे-अधूरे शब्दों में ही कहते थे; कोई भी खुलकर बात नहीं करता था—अजीब-सा माहौल था

    • 2008 में मैंने browser-based XSLT site पर काम किया था, और उससे पहले 2000s की शुरुआत में भी यह support मौजूद था

    • Chrome में libxslt और Firefox में Transformiix नाम का 1.0 engine है। Chrome सिर्फ़ exsl:node-set support करता है, जबकि Firefox कई EXSLT extensions support करता है (हालाँकि सभी नहीं)
      मैंने एक छोटा tool भी जारी किया है जो simple XSLT processor info और उपलब्ध extensions की list दिखाता है।
      GitHub - xslt-detect-ext
      Browser में out/detect.xslt file drag करके जानकारी देखी जा सकती है (Chrome, Firefox)। Safari के पुराने Windows version में यह काम नहीं करता

  • 90s में जब मैं high school में था और खुद को "web designer" कहता था, तब मैं DSSSL dialect pipeline का उपयोग करके news feed से site auto-generate करता था। आज भी मुझे XSLT transforms पसंद हैं। bananas XI reader जैसे tools से मैं वास्तविक text transforms और template work भी खुद करता हूँ
    लेकिन ऐसे tooling को सच में पसंद करने वाले लोग बहुत कम थे, और जैसे ही मेरी जगह कोई और आता, अपनाई गई technology जल्दी गायब हो जाती
    bananas XI reader

  • अगर यह दिखाना हो कि 2000s की शुरुआत में XML और XSLT का craze कितना ज़्यादा था, तो मैं जिस कंपनी में काम करता था उसने real-time speed पर XML parse करने और chip पर सीधे XSLT चलाने वाला ASIC तक बनाया था। उस समय लोगों को सच में लगता था कि इंटरनेट का भविष्य पूरा XML/XSLT पर चलेगा।
    बाद में उस कंपनी को Intel ने acquire कर लिया, और वह technology SSE accelerators की दिशा में चली गई

    • अगर ASIC पर XML parsing और XSLT execution जैसा मॉडल मुख्यधारा बन गया होता, तो कल्पना कीजिए आज websites कितनी तेज़ होतीं

    • IBM अब भी ऐसा मिलता-जुलता hardware बेचता है (DataPower Gateway)