XSLT - ระบบบิลด์แบบเนทีฟ Zero-Config สำหรับเว็บ

 (github.com/pacocoursey)
2 คะแนน โดย GN⁺ 2025-06-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • XSLT เป็นเครื่องมือบิลด์ที่มีมาให้โดยพื้นฐาน สำหรับเว็บ ซึ่งใช้งานได้ทันทีโดยไม่ต้องมี ระบบบิลด์ที่ซับซ้อน
  • ระบบบิลด์สำหรับเว็บไซต์แบบสแตติกส่วนใหญ่มักมีปัญหาเรื่องความซับซ้อน ความเข้าใจยาก และการผูกติดกับเฟรมเวิร์ก
  • เมื่อใช้ XML และ XSLT ก็สามารถสร้าง HTML ได้โดยตรงในเบราว์เซอร์ ทำให้จัดการข้อมูลแบบไดนามิกและสร้างมาร์กอัปได้ง่าย
  • เบราว์เซอร์หลักทั้งหมดรองรับ การแปลงผลด้วย XSLT จึงใช้งานได้โดยไม่ต้องมี JavaScript เพิ่มเติมหรือเครื่องมือแยกต่างหาก
  • แม้จะไม่ใช่คำตอบที่สมบูรณ์แบบ แต่ก็มีคุณค่าในฐานะ ทางเลือกที่เรียบง่ายและยืดหยุ่นบนพื้นฐานของมาตรฐานเว็บ

บทนำและประเด็นปัญหา

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

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

  • แนวคิดนี้ตั้งต้นจากข้อเท็จจริงที่ว่า ตัวเว็บเบราว์เซอร์เองรองรับการแปลงข้อมูลหลายรูปแบบ (text/html, text/markdown, application/xml เป็นต้น)
  • จึงได้พิจารณาสเปกของเว็บอย่างลึกซึ้ง และหาวิธีแก้ปัญหาโดย ไม่พึ่งเครื่องมือภายนอกหรือเฟรมเวิร์กที่ไม่จำเป็น

การใช้งาน XSLT

  • ระหว่างที่อยากแสดง RSS feed ให้ดูสวยงาม จึงได้พบกับ สเปก XSLT
  • XSLT เป็นเทคโนโลยีมาตรฐานอย่างเป็นทางการที่ใช้ อธิบายทั้งข้อมูล XML และโครงสร้างผลลัพธ์ HTML
  • วิธีใช้งานนั้นง่ายมาก
    • ตัวอย่างเช่น จัดข้อมูลไว้ใน blog.xml
    • จากนั้นเชื่อมสไตล์ชีต XSLT แบบนี้
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • ใน blog.xsl ให้เขียนเทมเพลต HTML และกฎการแมปข้อมูล
  • รองรับ ฟังก์ชันส่วนใหญ่ของระบบบิลด์ เช่น เทมเพลต การวนซ้ำ ตัวแปร และการ import ไฟล์ภายนอก

วิธีรันและข้อดี

  • โดยไม่ต้องมีเครื่องมือเพิ่มเติม เพียงแค่ เปิดไฟล์ XML ด้วยเว็บเบราว์เซอร์ ก็จะแสดงผลลัพธ์ที่แปลงแล้วได้ทันที
  • ฟอร์แมต XML มีความคล้ายกับ HTML จึง เป็นมิตรกับมนุษย์และดูแลรักษาง่าย ใช้แทน JSON ก็แทบไม่รู้สึกว่าลำบาก
  • เว็บเบราว์เซอร์หลักทั้งหมด รองรับการแปลงด้วย XSLT แบบเนทีฟ ทำให้ฝั่งไคลเอนต์สามารถดูผลลัพธ์ที่แปลงแล้วได้โดยตรง
  • ไม่ต้องใช้ JavaScript, เครื่องมือบิลด์แยกต่างหาก หรือ bundler ถือเป็นจุดเด่นที่สำคัญมาก
  • แม้ XSLT จะไม่ใช่คำตอบ万能ขั้นสุดท้าย แต่ก็เป็น ทางเลือกการบิลด์เว็บที่เรียบง่ายและขยายต่อได้

บทสรุป

  • เป็นการค้นพบคุณค่าของเทคโนโลยีจากอดีตอย่าง XSLT และ มาตรฐานที่ชัดเจน อีกครั้ง
  • แนวทางการใช้เว็บเบราว์เซอร์เป็นระบบบิลด์คือ ตัวเลือกที่มีประโยชน์และควรมีติดกล่องเครื่องมือของนักพัฒนาเว็บ

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

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

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

  • บริษัทที่ฉันเคยทำงานอยู่ใช้ XSLT กับ XML template เยอะมาก และก็น่าจะยังใช้กันอยู่จนถึงตอนนี้ พูดตามตรงมันไม่ใช่ตัวเลือกที่ดีนัก และถ้าเป็นไปได้ก็คงอยากย้ายไปใช้อย่างอื่น

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

    • XSLT/XPath พัฒนาไปเยอะพอสมควรหลัง 1.0 มีฟีเจอร์ต่าง ๆ อย่าง key(index) ที่ช่วยให้ประมวลผลเร็วขึ้นมาก ถ้าใช้ implementation คุณภาพดีอย่าง Saxon ปัญหา performance ก็จะน้อยลงมากด้วย เวลาจะแปลง XML ไปเป็นอย่างอื่น ก็มีไม่กี่อย่างที่จัดโครงสร้างเชิงตรรกะได้สะดวกเท่า XSLT

    • XSLT เรียนรู้ยากพอตัว มันเหมือน Prolog เวอร์ชันฝัน ๆ หน่อย ๆ และถ้าเก่งจริงก็จะให้ความรู้สึกสะใจแบบตอนแก้ Sudoku ได้ แต่ส่วนใหญ่แล้วไม่ได้ต้องการ template ที่ซับซ้อนขนาดนั้น เลยยากจะเป็นตัวเลือกมาตรฐาน และ XML เองก็ไม่ใช่ format ที่ทุกคนชอบ

    • ไม่ค่อยเข้าใจประเด็นที่ว่า XSLT 1.0 ยังถูกใช้เยอะ ในปี 2013 เอง 1.0 ก็แทบถูกมองว่าใกล้หมดสภาพแล้ว และ Saxon ที่ใช้ XSLT 2 ก็ฟรีและเร็วมาก ฉันไม่เคยเจอปัญหา performance เลย ไม่ว่าจะเป็นเอกสารใหญ่หรือเล็ก

    • ยุคที่ XSLT เกิดขึ้นมาเป็นช่วงที่การประมวลผล XML ขนาดใหญ่มากเป็นเรื่องปกติ แต่ถ้ามี nested loop แบบนี้ก็คงพังเป็นธรรมดา

    • อยากรู้ว่าคุณใช้ Saxon รุ่น commercial อยู่หรือเปล่า ราคาไม่ได้แพง และด้วยการรองรับมาตรฐานใหม่ ประสิทธิภาพ และฟีเจอร์ต่าง ๆ IMHO มันคุ้มเงินจริง ๆ เท่าที่เคยใช้จำได้ว่ามี optimization ที่ฉลาดมาก

  • ช่วงยุค 90-00s เบราว์เซอร์แต่ละตัวต่างกันสุด ๆ เลยเริ่มเอา JS มาใช้เพื่อทำให้พฤติกรรมสอดคล้องกัน
    จริง ๆ สิ่งที่เราอยากได้คือ CSS สวย ๆ แต่ตอนนั้นยังใช้ได้ไม่ดีพอ
    พอเวลาผ่านไป เบราว์เซอร์ตัวหนึ่งเริ่มครองตลาด และตัวอื่นก็คล้ายกันขึ้นมาก (กฎ Highlander แต่ Firefox ก็ยังสู้ได้ดีอยู่)
    พอ framework กลายเป็นเรื่องปกติ มันก็ลงเอยที่การทำ UI ให้เหมือนกันทุกเบราว์เซอร์ และทั้งกระบวนทัศน์ก็ย้ายไปสู่การ render ข้อมูล JSON
    ตอนนี้แม้จะสร้างเว็บเพจแบบดั้งเดิมจากฝั่งเซิร์ฟเวอร์ก็ยังเร็วและใช้หน่วยความจำน้อย
    ที่คิดแบบนี้เพราะช่วงหลังเพิ่งย้ายออกจากระบบ legacy แล้วได้กลับไปเจอเว็บที่ทำงานแบบ page-by-page HTTP request อีกครั้ง ซึ่งเป็นมาตรฐานยุค 2000s ทุก action ต้อง refresh หน้าใหม่ แต่กลับเร็วกว่า system ที่ใช้ React มาก
    เหตุผลคือ

    1. อินเทอร์เน็ตเร็วขึ้นมากแล้ว
    2. โทรศัพท์มีหน่วยความจำเหลือเฟือ แต่ JS framework ก็เอามาใช้เปลือง
    3. backend ไม่ว่าเมื่อก่อนหรือตอนนี้ก็ยังเป็น CRUD, CRUD, CRUD(+pagination, +transaction)

    • AJAX กับการอัปเดต DOM ไม่ได้เกิดขึ้นมาแค่เพื่อให้เร็วขึ้น แต่มันเกิดขึ้นเพื่อพาเว็บออกจากกระบวนทัศน์แบบ 'เว็บไซต์/เว็บเอกสาร' การ reload ทั้งหน้ามีความหมายในโลกที่ยึดเอกสารเป็นศูนย์กลาง ในตัวอย่างง่าย ๆ อย่าง HN โครงสร้างแบบนี้เหมาะมาก หลายเว็บไซต์ก็ทำงานได้ดีพออยู่แล้วโดยไม่ต้องใช้ JS framework
      แต่การบอกว่า "ทุกคนสามารถย้อนกลับไปใช้การ reload ทั้งหน้าได้" นั้นห่างไกลจากความจริง เพราะสำหรับ 'เว็บแอปพลิเคชัน' ที่ต้องการ interaction ซับซ้อน การ reload ทั้งหน้าเป็น UX ที่แย่มาก
      สรุปคือ
      'เว็บไซต์', 'เว็บเอกสาร', 'ฟอร์มง่าย ๆ' มักพอเพียงกับการ reload ทั้งหน้า
      แต่กรณีอย่าง 'เว็บแอปพลิเคชัน' ที่ต้องมีหน้าจอข้อมูล/การจัดการซับซ้อนนั้นไม่ใช่

    • ไทม์ไลน์ที่ฉันจำได้ต่างออกไปนิดหน่อย JS ไม่ได้ถูกใช้เพื่อทำให้พฤติกรรมเบราว์เซอร์เหมือนกันเป็นหลัก แต่ใช้เพื่อเพิ่มความ interactive ตั้งแต่แรกเลย (DHTML, AJAX ฯลฯ) ส่วนการจัด layout จริง ๆ แทบต้องพึ่งลูกเล่นเฉพาะทางกับการตรวจ agent ของเบราว์เซอร์ แม้ CSS จะเก่งขึ้น ปัญหาความสม่ำเสมอก็ไม่ได้หายง่าย ๆ CSS garden, semantic markup, การใช้ตารางพร่ำเพรื่อ ทั้งหมดนั้นคือบรรยากาศของยุคนั้น และกว่าจะผ่าน ACID test ตัวแรกได้ก็ใช้เวลานานมาก ฉันค่อนข้างสงสัยว่า framework มีผลต่อความสม่ำเสมอของ UI มากแค่ไหน—หลังยุค jQuery ไปแล้ว CSS เองต่างหากที่เป็นตัวหลักของความสม่ำเสมอด้านภาพ
      แน่นอนว่านี่อาจเป็นแค่ความทรงจำส่วนตัว

    • เห็นด้วยว่าใน modern stack การ render เว็บเพจแบบดั้งเดิมจากฝั่งเซิร์ฟเวอร์นั้นเร็วและเบา
      ใน stack .NET/Kestrel/SQLite ของฉัน SSR response จะให้เกิน 4ms นี่ยากมาก ส่วนใหญ่จะอยู่ระดับร้อยกว่าไมโครวินาที ใช้วิธีทำหลาย query และ join ซับซ้อนในแต่ละหน้าเพื่อปั้น shape ของข้อมูลให้ตรงกับ view
      แม้แต่เคสสุดโต่งอย่างสร้างตาราง 100,000 แถว ถ้าจัดการข้อมูลให้ดีก่อนประกอบเป็น HTML string ประสิทธิภาพจะดีขึ้นมาก LINQ ก็เร็วมากเช่นกัน แต่ถ้าสร้าง collection แยกต่อแถว พอข้อมูลเยอะขึ้นจะไม่มีประสิทธิภาพอย่างแรง
      จากประสบการณ์ของฉัน การเอา HTML template engine ไปไว้ใกล้กับฐานข้อมูลให้มากที่สุด ดีที่สุดต่อการ optimize performance สุดท้ายแล้ว DOM ก็เป็นแค่ byte stream ไม่จำเป็นต้องสร้าง AST/parser ซับซ้อน แค่ประกอบ StringBuilder กับ SQL query ก็พอแล้ว
      ข้อโต้แย้งต่อวิธีเรียบง่ายแบบนี้ที่เจอบ่อยที่สุดก็คือประเด็นจากฝ่าย security ที่ว่า "เชื่อใจนักพัฒนาเรื่อง HTML escaping ไม่ได้"

    • แนวคิดว่า "ด้วยเทคโนโลยีสมัยใหม่ การทำเว็บเพจคลาสสิกจากเซิร์ฟเวอร์ก็ยังพอรับมือได้" อาจเปลี่ยนไปเลยถ้า network latency สูง
      ลิงก์อ้างอิง

  • ช่วงทศวรรษ 2000 XML ฝั่ง enterprise พองตัวใหญ่เกินไปจนเทคโนโลยีดูเหมือนล้าสมัย สุดท้ายทุกคนก็ไปหลงใหลใน "ความเรียบสะอาด" ของ JSON แต่จริง ๆ แล้วเทคโนโลยีอย่าง XSLT, XPath นั้นสุกงอมมาก และเคยแก้ปัญหาหลายอย่างที่ทุกวันนี้เรายังปวดหัวกันอยู่
    ฉันเองก็เคยใช้ XSLT include แบบเกินพอดีเหมือนกัน โดยใช้ PHP stream wrapper ทำอะไรอย่าง <xsl:include href="mycorp://invoice/1234">
    พูดตรง ๆ ว่าตอนนี้มันอาจดูเชยไปหน่อย แต่การให้เบราว์เซอร์ประมวลผล XSLT ในเครื่องก็ยังให้ความรู้สึกไม่น่าไว้ใจ เพราะเมื่อก่อนมันเป็นสนามทุ่นระเบิดด้าน compatibility จริง ๆ

    • ยังคิดถึงองค์ประกอบ "พื้นฐาน" ของ XML ที่ JSON ยังขาดอยู่ เช่น ความเป็นสเปกมาตรฐานจริง ๆ หรือการนิยาม schema ซึ่ง XML เหนือกว่ามาก และ JSON ใช้เวลาเกือบ 10 ปีกว่าจะตามทัน
      ครั้งสุดท้ายที่ฉันแตะ XML แบบจริงจังคือกับเทคโนโลยีส่งข้อมูลชื่อ EXI มันเปลี่ยนเอกสาร XML ให้เป็น binary stream แบบบีบอัด ซึ่งกระบวนการโครงสร้าง ↔ ASCII ↔ บีบอัด/ส่ง ↔ แปลงกลับ ก็ยุ่งยากอยู่ ตอนนี้โลกไปทาง protobuf กับ gRPC แล้ว แต่ถ้า XML ยังเดินหน้าต่อ บางทีเราอาจได้โลกที่ทุกอย่างเข้ากันได้บนฐานมาตรฐานเดียวกัน (ในจินตนาการอุดมคติของฉัน) จริง ๆ แล้วกำแพงระหว่าง protobuf/gRPC กับ JSON API ตอนนี้สูงมาก แต่บางทีนั่นอาจจะดีกว่าแล้วก็ได้

    • ฉันคิดว่า XML เป็น format ที่โอเค มันยาวและ verbose ก็จริง แต่ถ้าเทียบกับ YAML แล้วมันแม่นยำและแสดงความหมายได้ดีกว่ามาก
      XPath คุ้นมือยาก แต่ถ้าลองเล่นไปสักพัก สุดท้ายก็ทำสิ่งที่ต้องการได้
      ส่วน XSLT ฉันคิดว่าเป็นแนวคิดที่เพี้ยนสุด ๆ ควรถูกขับออกไปได้แล้ว

    • เกมชื่อ Rimworld เก็บข้อมูลการตั้งค่าทั้งหมดไว้ใน XML และเปิดให้ mod ได้ด้วย XPath ซึ่งเป็นคู่ผสมที่ทรงพลังมาก สำหรับการปรับแต่งข้อมูลในเครื่องแทบไม่มีอะไรเทียบได้ แต่ดูเหมือนเกมส่วนใหญ่ไม่อยากใช้เพราะ XML ถูกตีตราว่า "ล้าสมัย"
      เอกสารทางการของ Rimworld เรื่อง XPath modding

    • เรื่องที่ว่า enterprise XML ช่วงต้นยุค 2000 พองตัวใหญ่เกินจริงนั้นเป็นเรื่องจริงมาก เดิม XML เป็นเวอร์ชันย่อของ SGML ที่ทำให้ใช้กับเว็บได้ เพื่อส่งต่อ markup/ขยาย vocabulary สุดท้ายมีแค่ SVG กับ MathML ที่รอดมาได้ แล้วพอกระแสเว็บบูม W3C/MS ก็ปล่อย SOAP, สเปก WS-* และอย่างอื่นออกมารัว ๆ ช่วงนั้นเป็นยุคคลั่งมาก ถึงขั้นเอาภาษาอย่าง XSLT ที่มีกระดูกเป็น Scheme ไปบังคับให้อยู่ในรูป XML แม้แต่ JavaScript เองก็ยังถูกตั้งชื่อให้พาดพิงกับ Java ตามบรรยากาศของยุคนั้น

    • Xpath น่าเสียดายตรงที่เพราะ namespace เลยต้องเขียน query ที่ยืดยาวจนน่ารำคาญ

  • ทุกวันนี้ฉันยังใช้ XSLT จัดสไตล์ feed ของตัวเองอยู่
    ตัวอย่าง RSS feed
    ตัวอย่าง XSLT

    • พอเห็นแบบนี้ก็อดคิดไม่ได้ว่าบล็อกจริง ๆ แล้วควรจะเป็นแค่ RSS feed หรือเปล่า

    • ฉันชอบลืมอยู่เสมอว่า XML เดิมทีทำอะไรแบบนี้ได้ มันให้ความรู้สึกแปลก ๆ แบบไม่ค่อยตรงสัญชาตญาณ

    • ทำออกมาได้สวยมาก อยากเห็นคนอื่นเอาแนวคิดตัวอย่างแบบนี้ไปใช้กันอย่างสร้างสรรค์อีกเยอะ ๆ

  • ตอนทำงานแรกของฉันตอนอายุ 19 เคยรับหน้าที่ปรับแต่ง Google Search Appliance เป็นโปรเจกต์ที่ลง CentOS บนเซิร์ฟเวอร์ Dell สีเหลืองราคาเป็นแสน แล้วเอา Python สไตล์กูเกิลมาทำ full-text search ให้เอกสารบน CIFS
    ราวปี 2011 XHTML กำลังนิยม และใน Google Search Appliance จะใช้ XSLT แปลงข้อมูล XML จาก backend เป็น XHTML ฉันระเบิด template ตัวอย่างทิ้งแล้วสร้าง UI ประหลาด ๆ ให้เข้ากับ intranet ภายในองค์กร เอาของจาก Coldfusion, StackOverflow, W3Schools และทรัพยากรเก่า ๆ อื่น ๆ มาปะติดปะต่อเข้าด้วยกัน
    ฉันรีบลบประสบการณ์นี้ออกจากเรซูเม่ เพราะหลังจากนั้นผู้รับเหมาช่วงของ DoD (กระทรวงกลาโหมสหรัฐ) ชอบติดต่อมาให้ไปทำโปรเจกต์ปรับปรุงระบบเอกสาร โดยเรียกว่าเป็น "ผู้เชี่ยวชาญ XML" จนเหนื่อย
    ครั้งหน้าถ้าคุณถอนหายใจเพราะต้องใช้ JSX วน array จาก JSON ไปเป็น TypeScript interface ก็ขอให้นึกถึงเรื่องของฉัน อย่างน้อยมันก็ดีกว่าต้องทำแบบนั้นด้วย XSLT

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

  • หลายคนบอกว่า XML ดูยืดยาวและซับซ้อน แต่ถ้าได้ลงมือใช้จริง มันเป็น format ที่ยอดเยี่ยม
    คุณสามารถ validate ด้วย DTD และใช้ XSLT สร้างผลลัพธ์ให้อ่านง่ายสำหรับมนุษย์ได้
    สำหรับฉัน XML เป็น text format แบบเดียวกับ C++: มัน mature, มี "batteries included", ทรงพลัง และต่อกับภาษาอะไรก็ได้
    เหมือนภาษารุ่นเก่าที่สุกงอมแล้ว XML ก็กลายเป็นสิ่งที่คนชอบด่าว่าเป็นคอนเทนต์ของพวกเพี้ยน ๆ ซึ่งน่าเสียดาย ถ้าไม่เหมาะกับงานก็ไม่ต้องใช้ แต่ก็ไม่มีเหตุผลให้เกลียดมันเกินพอดีขนาดนั้น

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

  • ไอเดียที่ว่า "XSLT รันในเบราว์เซอร์ได้โดยตรง" น่าทึ่งมาก ครั้งสุดท้ายที่ฉันใช้ XSLT คือเมื่อ 20 ปีก่อน ตอนนั้นความอลังการของ enterprise Java กลบสุนทรียะเฉพาะตัวของ XSLT ไปหมด
    แต่ถ้า XSLT ทำงานในเบราว์เซอร์ได้เป็นค่าเริ่มต้น งั้นจอกศักดิ์สิทธิ์ของ static template แบบไม่ต้องพึ่ง host framework ก็เคยอยู่ใกล้แค่นี้เองหรือ?

    • เบราว์เซอร์รองรับแค่ XSLT 1.0 และยังมีคนพูดกันด้วยว่าอนาคตอาจถูกถอดออก ถ้าเบราว์เซอร์รองรับถึง 3.0 ได้ มันจะกลายเป็นของที่ใช้ทำ static webpage generation ได้ยอดเยี่ยมมาก เสียดายจริง ๆ

    • ก็มีประสบการณ์ที่ไม่จำเป็นต้องใช้หอคอย "enterprise Java ขนาดใหญ่" แบบนั้นเหมือนกัน เราใช้แค่ tomcat กับ apache libraries ไม่กี่ตัว และมันทำงานได้ค่อนข้างดี HTML ที่สร้างจาก XML ใน CMS จะมี personalization ใส่มาเป็น XML tag และด้วย server-side caching proxy การแปลงจึงเร็วพอรองรับ traffic สูงได้ หัวใจสำคัญคือ stream เอา output ของ XSLT ส่งออกไปยัง client ทันที ไม่ต้อง buffer ทั้งหมดไว้ในหน่วยความจำ
      ทุกวันนี้เรารันอะไรก็ได้ในเบราว์เซอร์ผ่าน wasm แต่ช่วงแรก ๆ ของ JS นั้นเลวร้ายมาก และแค่นักออกแบบยอมส่งไฟล์ Photoshop PSD มาให้ก็ถือว่าดีแล้ว ยุคที่ Google Maps กับ Gmail เพิ่งออกมา แล้วเราต้องพยายามทำ UI หนัก javascript พร้อมรองรับทั้ง Netscape และ Internet Explorer มันคือนรกของจริง

    • ที่จริงกระแส XHTML บูมขึ้นมาก็เพราะ "จอกศักดิ์สิทธิ์ของ static template" นี่แหละ แต่คนที่รู้จริงมักพูดกันแบบภาษาวงใน ไม่มีใครพูดออกมาตรง ๆ เป็นบรรยากาศแปลกมาก

    • ฉันเคยทำงานกับเว็บไซต์ XSLT ในเบราว์เซอร์เมื่อปี 2008 และจริง ๆ ก่อนหน้านั้นช่วงต้นยุค 2000 ก็รองรับแล้ว

    • Chrome ใช้ libxslt ส่วน Firefox ใช้เอนจิน 1.0 ชื่อ Transformiix Chrome รองรับแค่ exsl:node-set ส่วน Firefox รองรับ EXSLT extension หลายตัว (แต่ไม่ทั้งหมด)
      ฉันยังปล่อยเครื่องมือเล็ก ๆ ที่บอกข้อมูล XSLT processor และรายการ extension ที่ใช้ได้แบบง่าย ๆ ด้วย
      GitHub - xslt-detect-ext
      คุณสามารถลากไฟล์ out/detect.xslt ลงในเบราว์เซอร์เพื่อดูข้อมูลได้ (Chrome, Firefox) ส่วน Safari ใช้ไม่ได้ในเวอร์ชัน Windows เก่า

  • ตอนเป็นนักเรียนมัธยมปลายในยุค 90s สมัยที่คนเรียกกันว่า "เว็บดีไซเนอร์" ฉันเคยใช้ DSSSL dialect pipeline สร้างเว็บไซต์อัตโนมัติจาก newsfeed และจนถึงทุกวันนี้ฉันก็ยังชอบการแปลงด้วย XSLT อยู่ ใช้เครื่องมืออย่าง bananas XI reader เพื่อทำงานแปลงข้อความและ template จริงด้วยตัวเอง
    แต่คนที่ชอบ tooling แบบนี้จริง ๆ มีน้อยมาก และพอมีคนมาแทนตำแหน่งฉัน เทคโนโลยีที่นำเข้ามาก็มักหายไปอย่างรวดเร็ว
    bananas XI reader

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

    • ถ้าโครงสร้างแบบที่ ASIC ตีความ XML และ XSLT ได้โดยตรงกลายเป็นกระแสหลัก ป่านนี้เราอาจได้เว็บที่เร็วสุด ๆ ก็ได้

    • IBM ยังขายฮาร์ดแวร์ที่มีความสามารถคล้าย ๆ กันในตัวอยู่จนถึงตอนนี้ (DataPower Gateway)