XSLT - वेब के लिए native, zero-configuration build system

 (github.com/pacocoursey)
2 पॉइंट द्वारा GN⁺ 2025-06-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • XSLT को web browser में चलने वाले client-side build system की तरह इस्तेमाल करके XML data को HTML में बदला जा सकता है और static site generator की जटिलता घटाई जा सकती है
  • एक सामान्य static site .json, .md, .txt जैसे data, Hugo, Next.js, Astro जैसे build system, और static HTML output से बनी होती है, लेकिन बड़े framework एक साधारण Markdown blog के लिए भी अनावश्यक जटिलता पैदा कर सकते हैं
  • अगर केवल HTML और CSS इस्तेमाल करना चाहें, तो कई pages के header और footer को हाथ से copy करना पड़ता है; HTML import उपलब्ध नहीं है, और Web Component के लिए JavaScript engine की जरूरत होती है
  • XML document में <?xml-stylesheet type="text/xsl" href="blog.xsl"?> जोड़कर और XSLT template लिखकर browser visit के समय HTML output बना सकता है
  • यह तरीका JavaScript के बिना static files के रूप में deploy किया जा सकता है, लेकिन यह सब कुछ बदल देने वाला पूर्ण समाधान नहीं है; web development toolbox में जोड़ा जा सकने वाला एक और विकल्प है

static site build की जटिलता

  • सामान्य static website बनाने का flow data, build system और static HTML output में बंटा होता है
    • data .json, .md, .txt जैसी files में store होता है
    • build system के उदाहरणों में Hugo, Next.js, Astro आदि शामिल हैं
    • अंतिम result static HTML होता है
  • framework हटाकर सिर्फ सरल HTML और CSS इस्तेमाल करना चाहें, तब भी pages बढ़ने पर common header और footer बार-बार copy करने पड़ते हैं
  • विकल्प के रूप में सोचे जा सकने वाले हर रास्ते की अपनी सीमाएं हैं
    • HTML import मौजूद नहीं है
    • Web Component के लिए JavaScript चाहिए, और इसलिए JavaScript engine चाहिए

browser को build system की तरह इस्तेमाल करने का विचार

  • web browser पहले से ही text/html, text/markdown, application/xml जैसे कई formats समझ सकता है
  • अगर browser को data से HTML बनाने वाले system की तरह इस्तेमाल किया जाए, तो अलग build tool के बिना web standards पर आधारित flow बनाया जा सकता है
  • RSS feed को ज्यादा अच्छा दिखाने की कोशिश के दौरान पता चला कि XSLT को XML document के लिए stylesheet की तरह इस्तेमाल किया जा सकता है
  • XML, HTML जैसा दिखता है, लेकिन यह केवल web data तक सीमित data representation तरीका नहीं है; इसे XML spec में देखा जा सकता है

XML से HTML में बदलने का तरीका

  • XML document blog post जैसे data रख सकता है
<?xml version="1.0"?>
<blog>
  <post id="42" publishedAt="2025-06-26">
    <title>Hello XSLT</title>
    <tags>…</tags>
  </post>
</blog>
  • XML document में XSL stylesheet जोड़ने वाली declaration add की जा सकती है
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="blog.xsl"?>
<blog>
  <post id="42" publishedAt="2025-06-26">
    <title>Hello XSLT</title>
    <tags>…</tags>
  </post>
</blog>
  • XSLT template XML input लेकर HTML structure output करता है
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">;
  <xsl:output method="html" indent="yes" />
  <xsl:template match="/">
    <html>
      <head> … </head>
      <body> … </body>
    </html>
  </xsl:template>
</xsl:stylesheet>
  • XSLT को (XML) => HTML के रूप में देखा जा सकता है, और यह loops, variables, import जैसे build system features देता है
  • parent XML document का data XSLT में लाकर dynamically output किया जा सकता है
<head>
  <xsl:value-of select="title" /> | Blog
</head>

चलाने और deploy करने का तरीका

  • XML file को browser में खोलने पर XSLT transformation चलाया जा सकता है
open blog.xml -a Safari
  • सभी web browsers page visit के समय XSLT transformation support करते हैं और transformed HTML दिखाते हैं
  • यह तरीका user के computer पर चलने वाले client-side build system की तरह काम करता है
  • static file deployment आसान है और यह JavaScript के बिना काम करता है

सीमाएं और स्थान

  • blog data को JSON के बजाय XML में store करना पड़ता है, लेकिन XML HTML जैसा दिखता है, parse करना आसान है, flexible है और web में natively supported है
  • XSLT तरीका perfect नहीं है और सब कुछ replace नहीं करता
  • पुराने web standards, specs और browser features का उपयोग करके सरल static websites बनाने के लिए यह एक और tool बन जाता है

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

1 टिप्पणियां

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

  • मैंने एक ऐसी कंपनी में काम किया था जहाँ XML templates के लिए XSLT का बहुत इस्तेमाल होता था; अनुभव अच्छा नहीं था और अगर संभव होता तो शायद हम उससे हट चुके होते
    नए standards होने के बावजूद XSLT 1.0 अब भी हावी है, और आधुनिक standards की तुलना में सीमित और अजीब है
    XSLT templates की performance समस्याएँ सुलझाना लगभग नर्क जैसा है। यह Turing-complete functional-style language है, लेकिन performance बहुत abstracted रहती है; जो template ज़्यादातर documents पर ठीक चलता था, वह 100 rows वाली एक table पर फट पड़ता था। बाद में पता चला कि table processing template O(N^2) या उससे भी ऊपर है, और हर row के लिए XPath फिर से O(N) या उससे ऊपर हो सकता है, इसलिए optimization का तरीका भी साफ़ नहीं था। याद है कि एक document को XSLT से process करने में 7 मिनट से ज़्यादा लग गए थे
    JS में भी दूसरी समस्याएँ होंगी, लेकिन algorithmic complexity की समस्याएँ हल न कर पाना उनमें से एक नहीं है

    • XSLT/XPath, XSLT 1.0 के बाद आगे बढ़े हैं
      अब key (index) जैसी सुविधाओं से processing काफी तेज़ की जा सकती है, और Saxon जैसे अच्छे XSLT implementations भी performance में साफ़ मदद करते हैं
      XML को दूसरे formats में बदलते समय logic को structure करना आसान होता है, इसलिए XSLT काफी सुविधाजनक है
    • “XSLT 1.0 अब भी हावी है” — यह कहाँ सच है, समझ नहीं आता
      2013 में मैं XSLT का बहुत इस्तेमाल कर रहा था, और तब तक 1.0 हर जगह पूरी तरह मृत दिखता था। Saxon, XSLT 2 के लिए free था और शानदार था
      हमने विशाल documents और बहुत सारे छोटे documents दोनों transform किए, लेकिन performance की कोई समस्या नहीं आई
    • XSLT आसान नहीं है। उपमा दें तो यह hallucinogenic mushrooms खाया हुआ Prolog जैसा है, और learning curve बहुत steep है
      इसे सीख लेने के बाद Sudoku हल करने जैसी संतुष्टि मिलती है, लेकिन आम तौर पर लक्ष्य हासिल करने के लिए इससे कहीं कम tools काफी होते हैं, इसलिए build या template का standard approach बनना मुश्किल है
      ऊपर से XML भी ऐसा format नहीं है जिसे हर कोई पसंद करता हो
    • XSLT शायद उस दौर में बना था जब लंबे source XML को process करना स्वाभाविक माना जाता था, इसलिए nested loops का फटना इतना obvious लगता है कि अजीब है
    • जिज्ञासा है कि क्या आप Saxon का commercial version इस्तेमाल करते हैं। यह महँगा नहीं है, और supported features व performance को देखते हुए मुझे इसकी कीमत वाजिब लगती है
      अगर मुझे ठीक याद है, तो यह काफी smart optimizations भी करता था

  • यह शायद काफी खिंचा हुआ अनुमान हो सकता है, लेकिन 1990–2000 के दशक में browsers अलग-अलग थे, इसलिए समान व्यवहार पाने के लिए लोगों ने JS इस्तेमाल करना शुरू किया; असल में ज़रूरत अच्छी CSS styling और consistent behavior की थी
    समय के साथ browsers एक जैसे व्यवहार करने लगे, लेकिन हम पहले ही ऐसे frameworks के आदी हो चुके थे जो सभी browsers में pages को एक जैसा दिखाते थे, और paradigm JSON data render करने की तरफ बदल गया
    आज की technology से server-generated पुराने अंदाज़ के web pages भी आराम से संभाले जा सकते हैं; उनका footprint छोटा होता है, वे तेज़ होते हैं और memory भी कम इस्तेमाल करते हैं
    हाल ही में एक legacy system migration करते समय मैंने 2000s-style “हर HTTP request पर एक page” architecture देखा; add/delete जैसी हर action में refresh चाहिए था, फिर भी वह React system से कहीं तेज़ था। Internet तेज़ हो चुका है, phone memory JS frameworks बर्बाद कर रहे हैं, और backend अब भी ज़्यादातर CRUD, pagination और transactions ही है

    • AJAX और DOM updates सिर्फ़ “तेज़” बनाने के लिए नहीं आए थे, बल्कि documents दिखाने वाले web site/web document paradigm को बदलने के लिए आए थे
      HN जैसी सरल जगहों पर full-page refresh अच्छा बैठता है, और कई cases में JS framework की जगह simple website काफी होती है
      लेकिन यह सही नहीं कि हर कोई full-page refresh पर वापस जा सकता है। असली web applications में कुछ cases ऐसे होते हैं जहाँ full refresh भयानक user experience बन जाता है
      कुल मिलाकर websites, web documents और web forms full refresh से चल सकते हैं, लेकिन जहाँ जटिल चीज़ें दिखानी और manipulate करनी हों, ऐसी web applications के लिए यह ठीक नहीं है
    • वह timeline सही नहीं लगती। JS व्यवहार standardize करने से ज़्यादा शुरुआत में interactivity के लिए इस्तेमाल हुआ, DHTML और बाद का AJAX इसके उदाहरण थे
      उस समय layout मिलाने के लिए user-agent detection और तरह-तरह के quirks के क्रम पर भरोसा किया जाता था, और मुझे नहीं लगता कि JS को layout-related elements तक आसानी से access मिलता था
      CSS ने भी तुरंत consistency नहीं दी। features आने के बाद भी हालत गड़बड़ थी; सब CSS Zen Garden देखकर प्रभावित होते थे, लेकिन असली code tables से ही लिखा जाता था
      मुझे यह भी नहीं पता कि frameworks ने “consistent appearance” पर बड़ा असर डाला था या नहीं। jQuery से आगे निकलते-निकलते CSS पहले ही appearance संभाल रहा था
    • .NET/Kestrel/SQLite stack से server-side rendering responses लगभग अधिकतम 4 milliseconds के भीतर निकाले जा सकते हैं। release builds में average response time सैकड़ों microseconds के स्तर पर है
      यह उस condition में है जहाँ हर page पर कई queries चलती हैं, और view-specific response shape बनाने के लिए कई complex joins भी इस्तेमाल होते हैं। HTML string में interpolate करने से पहले data को सही shape में ला लेना 100,000 rows वाली table जैसे edge cases में performance के लिए बहुत मददगार होता है
      मेरे अनुभव में HTML template engine और database जितने पास हों, उतना अच्छा है। आखिरकार structured DOM भी client को भेजी जाने वाली byte stream ही है
      जहाँ StringBuilder और smart SQL query से काम चल सकता है, वहाँ sophisticated AST/parser approach पर सोचते-सोचते एक अर्थहीन और self-serving industry बन गई है। विरोधी तर्क अक्सर इस security-watchdog attitude पर आकर टिकते थे कि developers HTML escaping function सही से इस्तेमाल नहीं कर सकते
    • यह बात कि आज की technology से server-generated पुराने web pages संभाले जा सकते हैं, high-latency internet connections पर अपवाद रखती है: https://news.ycombinator.com/item?id=44326816

  • यह अफसोस की बात है कि 2000 के दशक के enterprise XML की भारी-भरकम बनावट की वजह से यह तकनीक पुरानी लगने लगी और सब लोग ज्यादा “साफ-सुथरे” JSON की ओर भाग गए
    XSLT और XPath बहुत mature हैं, और इन्होंने कई ऐसी समस्याएं पहले ही हल कर दी थीं जिनसे दूसरे formats आज भी जूझते हैं
    पुराने दिनों में PHP stream wrappers और XSLT include का जरूरत से ज्यादा इस्तेमाल करने की अच्छी यादें भी हैं
    यह पुराना पूर्वाग्रह भी हो सकता है, लेकिन browser को local में process करने देना अब भी थोड़ा असहज लगता है। पुराने समय में यह compatibility की बारूदी सुरंगों जैसा था

    • पुराना है, लेकिन JSON में XML की कुछ “बुनियादी” चीजें अब भी याद आती हैं। सबसे पहले, एक ठीक-ठाक standardization body थी
      XML वाली schemas जैसी चीजें कहीं ज्यादा अच्छी तरह defined थीं, और लगता है JSON को पकड़ बनाने में लगभग 10 साल लग गए
      आखिरी XML technology जिसे मैंने ठीक से handle किया था वह EXI थी, जो XML documents को compressed binary data stream में बदलने का transport तरीका था। Data structure को ASCII में बदलना, compress करके HTTP से भेजना और फिर वापस बदलना थोड़ा हास्यास्पद ही है
      आज protobuf परिवार ज्यादा लोकप्रिय है, लेकिन अगर XML बना रहता तो शायद यह आपस में जुड़ने वाले compatible standards की दुनिया बन सकता था। दूसरी ओर protobuf/gRPC और JSON API के बीच एक मजबूत दीवार है, और शायद वही बेहतर भी हो
    • XML ठीक है। थोड़ा verbose है, लेकिन YAML की तुलना में इसकी precision और expressiveness पसंद आती है
      XPath भी बुरा नहीं है। syntax पूरा याद रखना मुश्किल है, लेकिन थोड़ा प्रयोग करने पर आम तौर पर मनचाही जगह पहुंच जाते हैं
      XSLT तो पूरी तरह पागलपन भरी बकवास है और इसे जलकर खत्म हो जाना चाहिए
    • गेम Rimworld अपने सभी game configuration data को XML में store करता है, और modding के लिए XPath इस्तेमाल करता है, जो वाकई बढ़िया है
      Data में relatively stable local modifications संभव कराने वाले combination के रूप में XML + XPath को गंभीर रूप से कम आंका गया है। शायद XML की “old-fashioned” reputation की वजह से दूसरे games में यह ज्यादा नहीं दिखता, लेकिन इस use case के लिए यह बहुत robust system है
      https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
    • XML मूल रूप से SGML का simplified subset था, जिसका मकसद web पर markup deliver करना और browser की markup vocabulary और capabilities को evolve करना था
      लेकिन web boom बढ़ने पर W3C और MS ने SOAP, WS-* जैसी चीजें बनाईं, और XSLT समेत कई XML-based programming languages भी आईं
      HN वालों से यह नहीं कहना चाहिए, लेकिन XSLT मूल रूप से Scheme था, बस उसे XML होना अनिवार्य था; यह वही पागल दौर था जब JavaScript को Java का नाम उधार लेना पड़ा था
    • XPath अच्छा होता अगर हर query के हर हिस्से पर namespace सावधानी से लगाना जरूरी न होता

  • आजकल feeds को सजाने के लिए XSLT इस्तेमाल करता हूं
    उदाहरण के लिए https://susam.net/feed.xml और https://susam.net/feed.xsl हैं

    • यह देखकर सोचने पर मजबूर होता हूं कि blog सिर्फ RSS feed क्यों नहीं हो सकता
    • मैं हमेशा भूल जाता हूं कि XML ऐसा कर सकता है। किसी वजह से यह अजीब लगता है
    • मैं भी इसी तरीके से कर रहा हूं: https://adithyanair.com/feed.xml

  • 19 साल की उम्र में professional software engineer के रूप में मेरे शुरुआती projects में से एक कंपनी द्वारा खरीदे गए दो Google Search Appliance को customize करना था
    कंपनी को लगा कि अगर विशाल CIFS document repository में full-text search हो सके तो business development process बेहतर होगा, और उसने पीले front वाले Dell server rack पर, जिसमें CentOS और Google-शैली की Python चलती थी, सैकड़ों हजार dollars खर्च किए
    2011 के आसपास XHTML चलन में था, और GSA backend से XML में दिए गए search results को XSLT से XHTML में बदलता था
    मैंने default template उठाया और rendered ColdFusion application pages, StackOverflow, और W3Schools tutorials से चुराए गए assets और markup से कंपनी intranet portal जैसा एक monster बना दिया
    बाद में LinkedIn पर कई DoD contractors ने “XML expertise” देखकर document modernization projects में शामिल होने के लिए संपर्क किया, और मैंने जल्दी सीख लिया कि इस अनुभव को resume से हटा देना चाहिए
    जब JSON response से deserialized TypeScript interfaces की array को JSX में iterate करते हुए आप आह भरें, तो मुझे याद कर लेना जो यही काम XSLT में करता था

  • बहुत लोग शिकायत करते हैं कि XML verbose है और दूर से देखने पर complex लगता है, लेकिन मुझे यह बात पसंद है कि XML पर आधारित अच्छा file format बनाया जा सकता है, उसे DTD से validate किया जा सकता है, और जरूरत पड़ने पर XSLT से इंसानों के पढ़ने लायक format किया जा सकता है
    XML text-based file formats का C++ जैसा है। mature है, batteries included हैं, शक्तिशाली है, और चाहें तो किसी भी language से इस्तेमाल किया जा सकता है
    जैसे पुरानी और mature languages को उनकी अपनी अजीबताओं के कारण कोसा जाता है, वैसे ही XML को कोसना भी fashion बन गया है। अगर use case में fit नहीं बैठता तो मत इस्तेमाल करें, लेकिन इसे monster मानने की जरूरत नहीं

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

  • 2000 के दशक की शुरुआत में XML और XSLT कितनी दूर तक गए थे, इसका उदाहरण यह है कि मेरी पुरानी कंपनी ने ऐसा ASIC बनाया था जो XML को line speed पर parse करता था और XSLT को chip पर natively process करता था
    क्योंकि अनुमान था कि internet का भविष्य पूरा XML/XSLT ही होगा। Intel ने उस कंपनी को acquire किया, और internal technology SSE accelerator में चली गई

    • कल्पना करता हूं कि अगर वह रास्ता अपनाया गया होता तो websites कितनी तेजी से render होतीं
    • IBM अब भी DataPower Gateway बेचता है, जो उस description से मोटे तौर पर मेल खाने वाला hardware है

  • “XSLT browser में natively चलता है” — यह जादू असल में क्या है, यह सोचकर हैरानी होती है
    आखिरी बार मैंने XSLT करीब 20 साल पहले इस्तेमाल किया था, लेकिन उस समय कई सालों तक इसका बहुत ज्यादा इस्तेमाल किया था। तब इसे चलाने के लिए एक विशाल और डगमगाता enterprise Java tower चाहिए होता था, जिससे XSLT की अपनी elegance कम हो जाती थी
    लेकिन अगर XSLT सचमुच browser में चलता है, तो हर जगह host किए जा सकने वाले static templates की वह holy grail तो हमेशा से हमारी नाक के नीचे ही थी

    • Browser केवल XSLT v1.0 support करते हैं, और सुना है कि इसे हटाने की बात भी हुई थी
      इसके बजाय अगर v3 support आ जाए, तो native template support के साथ static webpages serve करना आसान हो सकता है
    • “विशाल और डगमगाता enterprise Java tower” जैसा कुछ नहीं था। Tomcat और कुछ Apache libraries के साथ हमने इसे ठीक से इस्तेमाल किया था
      CMS embedded HTML वाले XML files निकालता था और cache बहुत अच्छी तरह होता था। Personalization और HTML/JS rendering server side पर caching proxy के साथ handle की जाती थी
      XSL transformation cache के पीछे चलती थी और भारी traffic संभालने जितनी तेज थी। यहां XML का मकसद था तैयार HTML को blob की तरह डालना, और जिन हिस्सों को personalization चाहिए उन्हें ही XML tags के रूप में रखना
      अंतिम transformation काफी तेज था, और key बात यह थी कि XSL transformer के output को पूरी memory buffer में रखने के बजाय सीधे response output stream में बहा दिया जाता था। बड़े responses में यह आज भी अच्छी technique है, लेकिन कई frameworks default में memory buffering चुनते हैं और यही चीज छूट जाती है
      आजकल तो बेशक wasm से browser में जो चाहें चला सकते हैं। लेकिन उस समय JavaScript बदहाल था, और designer ज्यादा से ज्यादा Photoshop file थमा देते थे। उसे frames और tables में काटना पड़ता था, और जब Google Maps और Gmail अभी-अभी आए थे, उस दौर में Netscape और Internet Explorer दोनों को support करते हुए हम काफी JavaScript-heavy CMS UI बना रहे थे
    • 2008 में मैंने एक ऐसी site पर काम किया था जो browser में XSLT इस्तेमाल करती थी, और support खुद शायद 2000 के दशक की शुरुआत तक जाता है
    • XSLT चलता तो है, लेकिन लगता है कि सभी browsers पुराने spec versions से बंधे हुए हैं
      Firefox में एक खास तौर पर परेशान करने वाला bug है: जब document के अंदर HTML को वास्तविक DOM के रूप में render करने के लिए disable-output-escaping चाहिए होता है, तो यह ठीक से काम नहीं करता और raw HTML text के रूप में render हो जाता है
    • यह समझ नहीं आता कि enterprise Java tower क्यों चाहिए था। classic ASP में VBScript की करीब तीन lines से XML transform कर लेते थे

  • बहुत पहले के एक बेहद दूरस्थ dystopian project में, किसी ने यह सोचकर एक solution निकाला कि team तेजी से बदलते workbook के साथ parallel में Java development को coordinate नहीं कर पाएगी
    structure यह था कि Visual Basic, Excel में बने workbook को XML में बदलता था, और XSLT files उस XML में defined Struts actions को handle करने वाली Java classes अपने आप generate करती थीं
    https://raganwald.com/2008/02/21/mouse-trap.html
    HN discussion: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952