XSLT - ระบบบิลด์แบบเนทีฟ ไม่ต้องตั้งค่า สำหรับเว็บ

 (github.com/pacocoursey)
2 คะแนน โดย GN⁺ 2025-06-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถใช้ XSLT เหมือนเป็น ระบบบิลด์ฝั่งไคลเอนต์ ที่ทำงานในเว็บเบราว์เซอร์ เพื่อแปลงข้อมูล XML เป็น HTML และลดความซับซ้อนของ static site generator ได้
  • เว็บไซต์แบบสแตติกทั่วไปประกอบด้วยข้อมูลอย่าง .json, .md, .txt, ระบบบิลด์ อย่าง Hugo, Next.js, Astro และผลลัพธ์เป็น HTML แบบสแตติก แต่เฟรมเวิร์กขนาดใหญ่อาจเพิ่มความซับซ้อนมากเกินไปแม้กับบล็อก Markdown ที่เรียบง่าย
  • แม้จะพยายามใช้แค่ HTML และ CSS ก็ยังมีข้อจำกัดว่าต้องคัดลอก header และ footer เองในหลายหน้า, ไม่มี HTML import และ Web Component ต้องใช้ JavaScript engine
  • หากเพิ่ม <?xml-stylesheet type="text/xsl" href="blog.xsl"?> ลงในเอกสาร XML และเขียนเทมเพลต XSLT เบราว์เซอร์ก็สามารถสร้าง ผลลัพธ์ HTML ได้ในตอนที่มีการเข้าชม
  • วิธีนี้สามารถ deploy เป็นไฟล์สแตติกได้โดยไม่ต้องใช้ JavaScript แต่ไม่ใช่คำตอบที่สมบูรณ์แบบสำหรับทุกอย่าง และเป็นอีกหนึ่งทางเลือกที่เพิ่มเข้าไปในชุดเครื่องมือพัฒนาเว็บ

ความซับซ้อนของการบิลด์เว็บไซต์แบบสแตติก

  • เวิร์กโฟลว์ทั่วไปของการสร้างเว็บไซต์แบบสแตติกแบ่งได้เป็นข้อมูล, ระบบบิลด์ และผลลัพธ์ HTML แบบสแตติก
    • ข้อมูลถูกเก็บในไฟล์อย่าง .json, .md, .txt
    • ตัวอย่างของระบบบิลด์มี Hugo, Next.js, Astro
    • ผลลัพธ์สุดท้ายคือ HTML แบบสแตติก
  • ต่อให้ตัดเฟรมเวิร์กออกและอยากใช้แค่ HTML และ CSS แบบเรียบง่าย หากจำนวนหน้าเพิ่มขึ้นก็ยังต้องคัดลอก header และ footer ที่ใช้ร่วมกันซ้ำไปเรื่อย ๆ
  • ตัวเลือกที่อาจนึกถึงเป็นทางเลือกต่างก็มีข้อจำกัดของตัวเอง
    • ไม่มี HTML import
    • Web Component ต้องใช้ JavaScript และจึงต้องมี JavaScript engine

แนวคิดการใช้เบราว์เซอร์เป็นระบบบิลด์

  • เว็บเบราว์เซอร์เข้าใจฟอร์แมตหลายแบบอยู่แล้ว เช่น text/html, text/markdown, application/xml
  • หากใช้เบราว์เซอร์เป็นระบบที่สร้าง HTML จากข้อมูล ก็จะสร้างเวิร์กโฟลว์บนมาตรฐานเว็บได้โดยไม่ต้องมีเครื่องมือบิลด์แยกต่างหาก
  • ระหว่างที่พยายามแสดง RSS feed ให้อ่านง่ายขึ้น จึงค้นพบว่าสามารถใช้ XSLT เป็น stylesheet สำหรับเอกสาร XML ได้
  • XML ดูคล้าย HTML แต่เป็นวิธีแสดงข้อมูลที่ไม่ได้จำกัดแค่ข้อมูลบนเว็บ และสามารถดูได้จาก XML spec

วิธีแปลงจาก XML เป็น HTML

  • เอกสาร XML สามารถเก็บข้อมูลอย่างโพสต์บล็อกได้
<?xml version="1.0"?>
<blog>
  <post id="42" publishedAt="2025-06-26">
    <title>Hello XSLT</title>
    <tags>…</tags>
  </post>
</blog>
  • สามารถเพิ่มคำประกาศเพื่อเชื่อมต่อ XSL stylesheet เข้ากับเอกสาร XML ได้
<?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 จะรับอินพุต XML แล้วส่งออกเป็นโครงสร้าง HTML
<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 และมี ความสามารถแบบระบบบิลด์ เช่น loop, variable, import
  • สามารถดึงข้อมูลจากเอกสาร XML แม่มาแสดงแบบไดนามิกใน XSLT ได้
<head>
  <xsl:value-of select="title" /> | Blog
</head>

วิธีการรันและ deploy

  • เมื่อเปิดไฟล์ XML ด้วยเบราว์เซอร์ ก็สามารถรันการแปลง XSLT ได้
open blog.xml -a Safari
  • เว็บเบราว์เซอร์ทุกตัวรองรับการแปลง XSLT ตอนที่มีการเข้าชมหน้า และจะแสดงผลเป็น HTML ที่แปลงแล้ว
  • วิธีนี้ทำงานคล้าย ระบบบิลด์ฝั่งไคลเอนต์ ที่รันบนคอมพิวเตอร์ของผู้ใช้
  • แจกจ่ายเป็นไฟล์สแตติกได้ง่ายและทำงานได้โดยไม่ต้องใช้ JavaScript

ข้อจำกัดและตำแหน่งของมัน

  • แม้จะต้องเก็บข้อมูลบล็อกเป็น XML แทน JSON แต่ XML มีหน้าตาคล้าย HTML, parse ได้ง่าย, ยืดหยุ่น และรองรับแบบเนทีฟบนเว็บ
  • แนวทางแบบ XSLT ไม่ได้สมบูรณ์แบบและไม่สามารถแทนที่ทุกอย่างได้
  • มันเป็นอีกหนึ่งเครื่องมือสำหรับการสร้างเว็บไซต์แบบสแตติกอย่างเรียบง่าย โดยอาศัยมาตรฐานเว็บ, สเปก และความสามารถของเบราว์เซอร์ที่มีมานานแล้ว

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

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

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

  • เคยทำงานในบริษัทที่ใช้ XSLT กับเทมเพลต XML เยอะมาก ซึ่งไม่ดีเลย และถ้าเป็นไปได้ก็คงย้ายออกไปแล้ว
    แม้จะมีมาตรฐานใหม่ แต่ XSLT 1.0 ก็ยังครองตลาดอยู่ และเมื่อเทียบกับมาตรฐานสมัยใหม่แล้วก็มีข้อจำกัดและแปลกประหลาด
    การแก้ปัญหาประสิทธิภาพของเทมเพลต XSLT แทบจะเหมือนตกนรก มันเป็นภาษาเชิงฟังก์ชันที่ Turing-complete แต่ประสิทธิภาพถูกทำให้เป็นนามธรรมไปมาก เทมเพลตที่ทำงานได้ดีกับเอกสารส่วนใหญ่กลับอาจระเบิดเมื่อเจอตาราง 100 แถวเพียงตารางเดียว สุดท้ายพบว่าเทมเพลตที่ประมวลผลตารางมีความซับซ้อน O(N^2) หรือมากกว่า และ XPath ในแต่ละแถวก็อาจเป็น O(N) หรือมากกว่าอีก ทำให้ไม่มีวิธีเพิ่มประสิทธิภาพที่ชัดเจน เท่าที่จำได้ การประมวลผลเอกสารหนึ่งฉบับด้วย XSLT ใช้เวลามากกว่า 7 นาที
    JS อาจมีปัญหาอย่างอื่น แต่การแก้ปัญหาความซับซ้อนของอัลกอริทึมไม่ได้เป็นหนึ่งในนั้น

    • XSLT/XPath พัฒนาต่อมาหลังจาก XSLT 1.0 แล้ว
      ตอนนี้มีฟีเจอร์อย่าง key(ดัชนี) ที่ช่วยเร่งการประมวลผลได้มาก และ implementation ของ XSLT ที่ดีอย่าง Saxon ก็ช่วยเรื่องประสิทธิภาพได้ชัดเจน
      เวลาจะแปลง XML ไปเป็นรูปแบบอื่น XSLT ค่อนข้างสะดวก เพราะจัดโครงสร้างลอจิกได้
    • ไม่รู้ว่า “XSLT 1.0 ยังครองตลาดอยู่” นี่หมายถึงที่ไหน
      ในปี 2013 ผมใช้ XSLT เยอะมาก และตอนนั้น 1.0 ก็ตายสนิทแล้วไม่ว่าจะมองจากตรงไหน Saxon สำหรับ XSLT 2 ใช้ได้ฟรีและยอดเยี่ยมมาก
      แปลงทั้งเอกสารขนาดมหึมาและเอกสารขนาดเล็กจำนวนมาก แต่ไม่เคยมีปัญหาประสิทธิภาพเลย
    • XSLT ไม่ง่ายเลย ถ้าจะเปรียบก็คงเหมือน Prolog ที่กินเห็ดหลอนประสาท และมี learning curve ที่ชัน
      พอเรียนรู้จนเข้าใจแล้วก็ให้ความรู้สึกพึงพอใจเหมือนแก้ซูโดกุได้ แต่โดยทั่วไปแล้วเป้าหมายมักใช้เครื่องมือที่น้อยกว่านี้มากก็พอ จึงยากที่จะกลายเป็นแนวทางมาตรฐานของการ build หรือ templating
      แถม XML ก็ไม่ใช่รูปแบบที่ทุกคนชอบด้วย
    • XSLT ดูเหมือนถูกสร้างขึ้นในยุคที่การประมวลผล XML ต้นฉบับยาว ๆ เป็นเรื่องปกติ แต่การที่ลูปซ้อนกันระเบิดได้นี่ดูชัดเจนเกินไปจนแปลก
    • สงสัยว่าใช้ Saxon เวอร์ชันเชิงพาณิชย์หรือเปล่า มันไม่แพง และเมื่อดูจากฟีเจอร์ที่รองรับกับประสิทธิภาพแล้ว คิดว่าคุ้มค่า
      ถ้าจำไม่ผิด มันยังทำ optimization ที่ค่อนข้างฉลาดให้ด้วย

  • อาจเป็นการเดาที่ค่อนข้างฝืน แต่ในช่วงทศวรรษ 1990–2000 เบราว์เซอร์แต่ละตัวทำงานไม่เหมือนกัน เลยเริ่มใช้ JS เพื่อทำให้พฤติกรรมเหมือนกัน ทั้งที่จริง ๆ สิ่งที่ต้องการคือสไตล์ CSS ที่ดีและพฤติกรรมที่สม่ำเสมอ
    เมื่อเวลาผ่านไป เบราว์เซอร์เริ่มทำงานคล้ายกัน แต่เราก็คุ้นชินกับเฟรมเวิร์กที่ทำให้หน้าเว็บดูเหมือนกันในทุกเบราว์เซอร์ไปแล้ว และเปลี่ยนไปสู่แพรไดม์การเรนเดอร์ข้อมูล JSON
    ด้วยระดับเทคโนโลยีตอนนี้ หน้าเว็บแบบเก่าที่สร้างจากเซิร์ฟเวอร์ ก็รับมือได้สบาย footprint เล็กกว่า เร็วกว่า และใช้หน่วยความจำน้อยกว่า
    ช่วงหลัง ๆ ตอนย้ายระบบเลกาซี ผมเห็นโครงสร้างแบบยุค 2000 ที่เป็น “หนึ่งหน้าต่อหนึ่ง HTTP request” ซึ่งแม้ทุกการทำงานอย่างเพิ่ม/ลบจะต้อง refresh หน้าใหม่ แต่ก็ยังเร็วกว่าระบบ React มาก อินเทอร์เน็ตเร็วขึ้น หน่วยความจำในมือถือถูก JS framework ใช้อย่างสิ้นเปลือง และ backend ก็ยังคงเป็น CRUD, pagination, transaction เป็นส่วนใหญ่

    • AJAX และการอัปเดต DOM ไม่ได้ถูกนำมาใช้เพียงเพื่อทำให้ “เร็วขึ้น” แต่เพื่อเปลี่ยนแพรไดม์จาก เว็บไซต์/เอกสารเว็บ ที่ใช้แสดงเอกสาร
      ในที่เรียบง่ายอย่าง HN การ refresh ทั้งหน้าก็เหมาะดี และมีหลายกรณีที่เว็บไซต์แบบเรียบง่ายก็เพียงพอแทน JS framework
      แต่การบอกว่าทุกคนสามารถกลับไปใช้การ refresh ทั้งหน้าได้นั้นไม่ถูกต้อง ใน เว็บแอปพลิเคชัน จริง ๆ บางประเภท การ refresh ทั้งหน้าจะเป็นประสบการณ์ผู้ใช้ที่เลวร้ายมาก
      โดยทั่วไป เว็บไซต์ เอกสารเว็บ และเว็บฟอร์มสามารถทำได้ด้วยการ refresh ทั้งหน้า แต่ไม่เหมาะกับเว็บแอปพลิเคชันที่ต้องแสดงและจัดการสิ่งซับซ้อน
    • ไทม์ไลน์นั้นดูไม่น่าถูกต้อง JS ถูกใช้ในช่วงแรกเพื่อ การโต้ตอบ มากกว่าการทำให้พฤติกรรมเป็นมาตรฐาน ตัวอย่างก็คือ DHTML และต่อมาคือ AJAX
      ตอนนั้นเราอาศัยการตรวจจับ user agent และลำดับของ quirks ต่าง ๆ เพื่อจัด layout และผมก็ไม่คิดว่า JS เข้าถึงองค์ประกอบที่เกี่ยวกับ layout ได้ง่ายด้วยซ้ำ
      CSS ก็ไม่ได้ทำให้เกิดความสม่ำเสมอในทันที แม้หลังจากมีฟีเจอร์ครบแล้วก็ยังยุ่งเหยิง และเป็นยุคที่ทุกคนทึ่งกับ CSS Zen Garden แต่โค้ดจริงก็ยังเขียนด้วยตารางอยู่
      ผมก็ไม่แน่ใจว่าเฟรมเวิร์กมีผลมากกับ “รูปลักษณ์ที่สม่ำเสมอ” แค่ไหน พอเราเริ่มออกจาก jQuery กัน CSS ก็รับหน้าที่เรื่องรูปลักษณ์อยู่แล้ว
    • ด้วยสแต็ก .NET/Kestrel/SQLite สามารถสร้าง response แบบ server-side rendering ได้ภายในประมาณไม่เกิน 4 มิลลิวินาที ใน release build เวลา response เฉลี่ยอยู่ในระดับหลายร้อยไมโครวินาที
      ทั้งหมดนี้อยู่ภายใต้เงื่อนไขที่แต่ละหน้าส่ง query หลายรายการ และใช้ join ซับซ้อนจำนวนมากเพื่อสร้างรูปแบบ response เฉพาะสำหรับ view หากดึงข้อมูลมาให้อยู่ในรูปทรงที่ถูกต้องก่อนจะ interpolate ลงในสตริง HTML จะช่วยประสิทธิภาพได้มากในกรณีสุดขั้วอย่างตาราง 100,000 แถว
      จากประสบการณ์ ยิ่ง HTML template engine อยู่ใกล้ฐานข้อมูลเท่าไรก็ยิ่งดี สุดท้ายแล้ว DOM ที่มีโครงสร้างก็เป็นเพียง byte stream ที่ต้องส่งไปยัง client อยู่ดี
      ผมมองว่าเกิดอุตสาหกรรมที่ไร้ความหมายและเป็นเป้าหมายในตัวเองขึ้นมา จากการคิดมากเรื่องแนวทาง AST/parser ที่ประณีต ทั้งที่หลายจุดแค่ StringBuilder กับ SQL query ที่ฉลาดก็พอแล้ว เหตุผลโต้แย้งมักลงเอยเป็นท่าทีแบบผู้คุมความปลอดภัยที่ถือว่านักพัฒนาใช้ฟังก์ชัน escape HTML ให้ถูกต้องไม่ได้
    • ข้อที่ว่าเทคโนโลยีปัจจุบันสามารถรับมือกับหน้าเว็บแบบเก่าที่สร้างจากเซิร์ฟเวอร์ได้นั้นมีข้อยกเว้นเมื่อเป็น การเชื่อมต่ออินเทอร์เน็ตที่ latency สูง: https://news.ycombinator.com/item?id=44326816

  • น่าเสียดายที่ความเทอะทะของ XML ฝั่งองค์กรในยุค 2000 ทำให้เทคโนโลยีนี้ดูเก่า และทุกคนก็แห่ไปหา JSON ที่ “สะอาดกว่า”
    XSLT และ XPath นั้นสุกงอมมาก และได้แก้ปัญหาหลายอย่างที่ฟอร์แมตอื่น ๆ ยังเจอกันอยู่ไปแล้ว
    เมื่อก่อนก็มีความทรงจำดี ๆ จากการใช้ PHP stream wrapper กับ XSLT include แบบเกินพอดี
    อาจเป็นอคติเก่า ๆ แต่การปล่อยให้เบราว์เซอร์ประมวลผลในเครื่องเองยังทำให้รู้สึกไม่ค่อยสบายใจอยู่บ้าง เพราะเมื่อก่อนมันเป็นทุ่งกับระเบิดเรื่องความเข้ากันได้

    • ถึงจะเก่าแล้ว แต่ยังคิดถึง “พื้นฐาน” บางอย่างของ XML ที่ JSON ไม่มี อย่างแรกคือมี องค์กรกำหนดมาตรฐาน ที่จริงจัง
      สิ่งอย่าง schema ฝั่ง XML ถูกนิยามไว้ดีกว่ามาก และรู้สึกว่าฝั่ง JSON ใช้เวลาเกือบ 10 ปีกว่าจะไล่ทัน
      เทคโนโลยี XML ที่ได้จับจริงจังครั้งสุดท้ายคือ EXI ซึ่งเป็นวิธีส่งข้อมูลที่แปลงเอกสาร XML เป็นสตรีมข้อมูลไบนารีที่บีบอัดแล้ว เพราะการแปลงโครงสร้างข้อมูลเป็น ASCII แล้วบีบอัด ส่งผ่าน HTTP จากนั้นค่อยแปลงกลับนั้นก็ดูตลกอยู่เหมือนกัน
      ตอนนี้ตระกูล protobuf ได้รับความนิยมมากกว่า แต่ถ้า XML ยังอยู่ต่อไป อาจกลายเป็นโลกของมาตรฐานที่เข้ากันได้และเชื่อมต่อกันเป็นชุดก็ได้ ในทางกลับกัน ระหว่าง protobuf/gRPC กับ JSON API มีกำแพงที่แข็งมากกั้นอยู่ ซึ่งบางทีนั่นอาจจะดีกว่าก็ได้
    • XML ก็โอเคนะ ถึงจะยืดยาวไปหน่อย แต่ชอบ ความแม่นยำและพลังในการสื่อความ เมื่อเทียบกับ YAML
      XPath ก็ไม่เลว จำไวยากรณ์ทั้งหมดได้ยาก แต่ถ้าลองผิดลองถูกนิดหน่อย โดยมากก็ไปถึงจุดที่ต้องการได้
      ส่วน XSLT เป็นเรื่องเพ้อเจ้อบ้าคลั่งโดยสมบูรณ์ ควรถูกเผาทิ้งให้หมด
    • เกม Rimworld เก็บข้อมูลการตั้งค่าเกมทั้งหมดไว้ใน XML และใช้ XPath สำหรับม็อด ซึ่งดีมากจริง ๆ
      ในฐานะชุดเครื่องมือที่ทำให้แก้ไขข้อมูลในเครื่องได้ค่อนข้างเสถียร XML + XPath ถูกประเมินค่าต่ำไปอย่างหนัก อาจเพราะ XML มีชื่อเสียงว่า “เชย” เลยไม่ค่อยเห็นในเกมอื่น ๆ แต่สำหรับงานลักษณะนี้มันเป็นระบบที่แข็งแรงมาก
      https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
    • เดิมที XML เป็นซับเซ็ตที่ทำให้ง่ายลงของ SGML ตั้งใจใช้ส่งมาร์กอัปบนเว็บ และพัฒนาคำศัพท์กับความสามารถด้านมาร์กอัปของเบราว์เซอร์
      แต่พอกระแสเว็บโตขึ้น W3C กับ MS ก็สร้างสิ่งอย่าง SOAP, WS-* ขึ้นมา และก็เกิดภาษาโปรแกรมมิงบนฐาน XML หลายตัวรวมถึง XSLT
      อาจไม่ควรพูดกับคน HN แต่เดิมที XSLT คือ Scheme เพียงแต่มันต้องเป็น XML ให้ได้ เป็นยุคแห่งความบ้าคลั่งแบบเดียวกับที่ JavaScript ต้องยืมชื่อ Java มาใช้
    • XPath คงจะดีถ้าไม่จำเป็นต้องใส่ namespace อย่างพิถีพิถันในทุกส่วนของทุก query

  • ทุกวันนี้ใช้ XSLT เพื่อตกแต่ง feed
    ตัวอย่างเช่น https://susam.net/feed.xml และ https://susam.net/feed.xsl

    • เห็นแบบนี้แล้วทำให้นึกว่า มีเหตุผลอะไรที่บล็อกจะเป็นแค่ RSS feed เฉย ๆ ไม่ได้
    • มักลืมอยู่เสมอว่า XML ทำอะไรแบบนี้ได้ รู้สึกแปลก ๆ อย่างบอกไม่ถูก
    • ทำแบบเดียวกันอยู่: https://adithyanair.com/feed.xml

  • ตอนอายุ 19 หนึ่งในโปรเจกต์แรก ๆ ที่ได้รับในฐานะวิศวกรซอฟต์แวร์มืออาชีพ คือการปรับแต่ง Google Search Appliance สองเครื่องที่บริษัทซื้อมา
    บริษัทคิดว่าถ้าค้นหาแบบ full-text ในคลังเอกสาร CIFS ขนาดมหึมาได้ กระบวนการพัฒนาธุรกิจจะดีขึ้น จึงใช้เงินหลายแสนดอลลาร์กับแร็กเซิร์ฟเวอร์ Dell หน้าสีเหลืองที่รัน CentOS กับ Python แบบ Google
    ราวปี 2011 XHTML กำลังเป็นที่นิยม และ GSA ใช้วิธีนำผลการค้นหาที่ backend ส่งมาเป็น XML ไปแปลงเป็น XHTML ด้วย XSLT
    ผมเอาเทมเพลตพื้นฐานมา แล้วสร้างสัตว์ประหลาดที่ดูคล้ายพอร์ทัลอินทราเน็ตของบริษัท ด้วยแอสเซ็ตและมาร์กอัปที่ขโมยมาจากหน้าแอปพลิเคชัน ColdFusion ที่เรนเดอร์แล้ว, StackOverflow และบทเรียนของ W3Schools
    หลังจากนั้น ผู้รับเหมาของ DoD หลายรายใน LinkedIn ติดต่อมาให้ไปร่วมโปรเจกต์ปรับปรุงเอกสารให้ทันสมัย เพราะเห็น “ความเชี่ยวชาญ XML” และผมก็เรียนรู้อย่างรวดเร็วว่าควรถอดประสบการณ์นี้ออกจากเรซูเม่
    เวลาถอนหายใจขณะวนลูป array ของ TypeScript interface ที่ deserialize มาจาก JSON response แล้วแสดงเป็น JSX ก็ให้นึกถึงตัวผมที่เคยทำสิ่งเดียวกันด้วย XSLT ได้เลย

  • หลายคนบ่นว่า XML ยืดยาว และมองไกล ๆ ก็ดูซับซ้อน แต่สิ่งที่ชอบคือสามารถสร้างฟอร์แมตไฟล์ที่ดีบนฐาน XML แล้ว ตรวจสอบด้วย DTD จากนั้นถ้าจำเป็นก็ใช้ XSLT จัดรูปแบบให้อ่านง่ายสำหรับมนุษย์ได้
    XML เหมือน C++ ของฟอร์แมตไฟล์แบบข้อความ มันสุกงอม มาพร้อมแบตเตอรี่ ทรงพลัง และถ้าต้องการก็ใช้ได้จากภาษาใดก็ได้
    เหมือนกับภาษาที่เก่าและสุกงอมทั้งหลายที่ถูกด่าเพราะความประหลาดเฉพาะตัว การด่า XML ก็กลายเป็นแฟชั่นไปแล้ว ถ้าไม่เหมาะกับงานก็ไม่ต้องใช้ แต่ไม่ควรมองมันเป็นสัตว์ประหลาด

    • สงสัยว่าทำไมใช้ DTD ไม่ใช้ XSD

  • ตัวอย่างที่แสดงว่า XML และ XSLT ไปไกลแค่ไหนในช่วงต้นยุค 2000 คือบริษัทที่เคยทำงานด้วยสร้าง ASIC ที่ พาร์ส XML ได้ที่ความเร็วสายสัญญาณ และประมวลผล XSLT แบบเนทีฟในชิป
    เพราะคาดกันว่าอนาคตของอินเทอร์เน็ตทั้งหมดจะเป็น XML/XSLT แล้ว Intel ก็ซื้อบริษัทนั้นไป และเทคโนโลยีภายในถูกนำไปใส่ในตัวเร่งความเร็ว SSE

    • ทำให้นึกภาพว่าถ้าไปทางนั้น เว็บไซต์จะเรนเดอร์ได้เร็วแค่ไหน
    • IBM ยังขาย DataPower Gateway ซึ่งเป็นฮาร์ดแวร์ที่ยังค่อนข้างตรงกับคำอธิบายนั้นอยู่

  • น่าทึ่งกับ “เวทมนตร์ที่ว่า XSLT ทำงานแบบเนทีฟในเบราว์เซอร์” ว่ามันคืออะไร
    ครั้งสุดท้ายที่ใช้ XSLT น่าจะราว 20 ปีก่อน แต่ตอนนั้นใช้มันหนักมากอยู่หลายปี ตอนนั้นถ้าจะให้มันทำงานได้ ต้องมีหอคอย Java ฝั่งองค์กรขนาดมหึมาและง่อนแง่น ซึ่งบั่นทอนความสง่างามของตัว XSLT เอง
    แต่ถ้า XSLT ทำงานในเบราว์เซอร์ได้จริง ก็แปลว่าจอกศักดิ์สิทธิ์อย่าง เทมเพลตแบบสแตติก ที่โฮสต์ได้ทุกที่นั้นอยู่ตรงหน้าเรามาตลอด

    • เบราว์เซอร์รองรับแค่ XSLT v1.0 และเท่าที่ได้ยินมาก็เคยมีการคุยกันว่าจะเลิกใช้ด้วย
      ถ้ามีการรองรับ v3 เข้ามาแทน ก็น่าจะทำให้เสิร์ฟหน้าเว็บแบบสแตติกด้วยการรองรับเทมเพลตแบบเนทีฟได้ง่ายขึ้น
    • ไม่ถึงขั้นเป็น “หอคอย Java ฝั่งองค์กรขนาดมหึมาและง่อนแง่น” หรอก ใช้ Tomcat กับไลบรารี Apache บางตัวก็ไปได้ดี
      CMS คายไฟล์ XML ที่มี HTML ฝังอยู่ภายในออกมา และแคชได้ดีมาก การปรับแต่งเฉพาะบุคคลกับการเรนเดอร์ HTML/JS จัดการฝั่งเซิร์ฟเวอร์ร่วมกับ caching proxy
      การแปลง XSL ทำงานอยู่หลังแคช และเร็วพอจะรับทราฟฟิกจำนวนมากได้ จุดประสงค์ของ XML ตรงนี้คือใส่ HTML ที่เตรียมไว้เป็น blob แล้วเหลือเฉพาะส่วนที่ต้องปรับแต่งเฉพาะบุคคลไว้เป็นแท็ก XML
      การแปลงขั้นสุดท้ายค่อนข้างเร็ว และหัวใจคือไม่เอาเอาต์พุตของ XSL transformer ไปเก็บไว้ในบัฟเฟอร์หน่วยความจำทั้งหมด แต่ปล่อยไหลตรงไปยัง response output stream เลย สำหรับ response ขนาดใหญ่ เทคนิคนี้ทุกวันนี้ก็ยังดีอยู่ แต่หลายเฟรมเวิร์กเลือกทำ memory buffering เป็นค่าเริ่มต้นเลยพลาดจุดนี้ไป
      แน่นอนว่าสมัยนี้ใช้ wasm รันอะไรก็ได้ที่ต้องการในเบราว์เซอร์ แต่ตอนนั้น JavaScript เละเทะมาก และดีไซเนอร์อย่างมากก็ส่งไฟล์ Photoshop มาให้ ต้องเอามาหั่นเป็นเฟรมกับตาราง และในช่วงที่ Google Maps กับ Gmail เพิ่งออกมา เรากำลังทำ CMS UI ที่ค่อนข้าง JavaScript-heavy โดยต้องรองรับทั้ง Netscape และ Internet Explorer
    • เคยดูแลไซต์ที่ใช้ XSLT ในเบราว์เซอร์เมื่อปี 2008 แต่ดูเหมือนว่าการรองรับเองจะย้อนกลับไปได้ถึงช่วงต้นทศวรรษ 2000
    • XSLT ทำงานได้ก็จริง แต่ดูเหมือนเบราว์เซอร์ทั้งหมดจะติดอยู่กับสเปกเวอร์ชันเก่า
      Firefox มีบั๊กที่น่ารำคาญเป็นพิเศษ คือเวลาต้องใช้ disable-output-escaping เพื่อเรนเดอร์ HTML ภายในเอกสารให้เป็น DOM จริง มันกลับทำงานไม่ถูกและเรนเดอร์เป็นข้อความ HTML ดิบแทน
    • ไม่เข้าใจว่าทำไมถึงต้องใช้หอคอย Java ฝั่งองค์กร แค่ใน classic ASP ก็แปลง XML ได้ด้วย VBScript สักสามบรรทัด

  • ในโปรเจกต์ดิสโทเปียที่เก่าแก่มากและไกลแสนไกล มีคนที่มองโลกในแง่ร้ายว่าทีมคงไม่สามารถประสานการพัฒนา Java ให้ไปพร้อมกับ workbook ที่เปลี่ยนแปลงเร็วได้ จึงเสนอทางออกขึ้นมา
    โครงสร้างคือ Visual Basic แปลง workbook ที่เขียนด้วย Excel ให้เป็น XML แล้วไฟล์ XSLT จะสร้างคลาส Java สำหรับจัดการ Struts action ที่นิยามไว้ใน XML นั้นโดยอัตโนมัติ
    https://raganwald.com/2008/02/21/mouse-trap.html
    การอภิปรายใน HN: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952