ผู้ผลิตเบราว์เซอร์กำลังพยายามยกเลิกการสนับสนุน XSLT (Extensible Stylesheet Language Transformations) จากเว็บเบราว์เซอร์อีกครั้ง ก่ให้เกิดการถกเถียงในชุมชนนักพัฒนาเกี่ยวกับอนาคตของเทคโนโลยีการแปลง XML นี้ การผลักดันครั้งล่าสุดมาจาก Mason Freed ของ Google ซึ่งเป็นการติดตามความพยายามก่อนหน้านี้ของ Mozilla และผู้พัฒนาเบราว์เซอร์อื่นๆ ในการยกเลิกฟีเจอร์นี้
แคมเปญการยกเลิกจากเบราว์เซอร์
ความพยายามในการกำจัด XSLT จากเบราว์เซอร์ไม่ใช่เรื่องใหม่ Chrome เคยพยายามยกเลิกและเอาการสนับสนุน XSLT ออกในปี 2013 และ 2015 แต่ทั้งสองครั้งล้มเหลวเนื่องจากการต่อต้านอย่างมากจากชุมชนนักพัฒนา ข้อเสนอล่าสุดของ Mozilla ในการประชุม WHATWG ได้จุดประกายการถกเถียงขึ้นใหม่ โดยผู้พัฒนาเบราว์เซอร์อ้างถึงภาระในการบำรุงรักษาและการใช้งานที่จำกัดเป็นเหตุผลในการยกเลิก
อย่างไรก็ตาม การตอบสนองจากชุมชนเผยให้เห็นมุมมองที่แตกต่างออกไป นักพัฒนาหลายคนยังคงพึ่งพา XSLT สำหรับกรณีการใช้งานเฉพาะ โดยเฉพาะในสภาพแวดล้อมองค์กรและไปป์ไลน์การแปลงข้อมูล ความล้มเหลวที่เกิดขึ้นซ้ำๆ ของความพยายามในการยกเลิกแสดงให้เห็นว่า XSLT ยังคงมีฐานผู้ใช้ที่ทุ่มเทซึ่งผู้พัฒนาเบราว์เซอร์ไม่สามารถเพิกเฉยได้
ไทม์ไลน์การยกเลิก XSLT ในเบราว์เซอร์
- 2013: Chrome พยายามยกเลิกการสนับสนุน XSLT ครั้งแรก (ล้มเหลว)
- 2015: Chrome พยายามลบ XSLT ครั้งที่สอง (ล้มเหลว)
- 2024: Mozilla เสนอข้อเสนอการยกเลิกในการประชุม WHATWG
- 2024: Mason Freed ของ Google สนับสนุนความพยายามยกเลิกครั้งใหม่
ความท้าทายในประสบการณ์นักพัฒนา
หนึ่งในคำวิจารณ์หลักของ XSLT มุ่งเน้นไปที่ประสบการณ์นักพัฒนา ไวยากรณ์ที่อิงบน XML ของภาษานี้สร้างความท้าทายด้านการอ่านอย่างมาก โดยเฉพาะสำหรับการแปลงที่ซับซ้อน การแปลง JSON ง่ายๆ ที่อาจใช้เพียงหนึ่งหรือสองบรรทัดใน JavaScript กลับต้องใช้โค้ด XSLT ที่ยาวเหยียดพร้อมการนำเข้าเนมสเปซหลายตัวและไวยากรณ์ที่ซับซ้อน
มีคนเขียน XSLT ของฉันใหม่ด้วย Python และฉันก็ให้กำลังใจเขา เพราะผลลัพธ์ที่ได้อ่านง่ายกว่ามาก ไม่ใช่น้อยเพราะขั้นตอนที่เป็นขั้นตอนพื้นฐานสามารถเขียนในภาษาขั้นตอนที่มีไวยากรณ์ดี แทนที่จะเป็นภาษาฟังก์ชันล้วนของ XSLT ที่ประสบปัญหาจากการฝังอยู่ใน XML
ประสบการณ์การดีบักเป็นอุปสรรคสำคัญอีกประการหนึ่ง ไม่เหมือนภาษาโปรแกรมมิ่งสมัยใหม่ที่มีเครื่องมือดีบักที่ซับซ้อน XSLT มีความสามารถในการดีบักที่จำกัด ทำให้การแก้ไขปัญหาเป็นประสบการณ์ที่น่าหงุดหงิดสำหรับนักพัฒนา
ฟีเจอร์สมัยใหม่ของ XSLT 3.0
แม้จะมีการวิจารณ์ แต่ XSLT 3.0 ได้นำเสนอฟีเจอร์สมัยใหม่หลายอย่างที่แก้ไขข้อจำกัดในอดีตบางประการ เวอร์ชันใหม่รวมถึงการสนับสนุน JSON ดั้งเดิม ช่วยให้สามารถแปลงระหว่างรูปแบบ JSON และ XML โดยตรงโดยไม่ต้องใช้วิธีการแก้ไขที่ซับซ้อน เทมเพลตค่าข้อความทำให้การแทรกสตริงง่ายขึ้น ลดความจำเป็นในการใช้ฟังก์ชัน concat() ที่ซับซ้อน
การเพิ่มฟังก์ชันที่ผู้ใช้กำหนดเองและการพิมพ์ที่เหมาะสมทำให้ XSLT ใกล้เคียงกับภาษาโปรแกรมมิ่งสมัยใหม่มากขึ้น ฟังก์ชันเหล่านี้สามารถจัดระเบียบเป็นแพ็คเกจพร้อมการควบคุมเวอร์ชัน ช่วยให้สามารถนำโค้ดกลับมาใช้ใหม่และบำรุงรักษาได้ดีขึ้น การสนับสนุนสตรีมมิ่งแก้ไขปัญหาประสิทธิภาพสำหรับชุดข้อมูลขนาดใหญ่ ในขณะที่โครงสร้าง try-catch ให้ความสามารถในการจัดการข้อผิดพลาดขั้นพื้นฐาน
คุณสมบัติหลักของ XSLT 3.0
- รองรับการแปลง JSON แบบดั้งเดิม
- เทมเพลตค่าข้อความสำหรับการแทรกสตริงที่ง่ายขึ้น
- ฟังก์ชันที่ผู้ใช้กำหนดเองพร้อมการกำหนดประเภทที่เหมาะสม
- แพ็กเกจฟังก์ชันพร้อมการควบคุมเวอร์ชัน
- รองรับการสตรีมมิ่งสำหรับชุดข้อมูลขนาดใหญ่
- โครงสร้างการจัดการข้อผิดพลาดแบบ try-catch
รูปแบบการใช้งานในอุตสาหกรรม
การใช้งานในโลกจริงเผยให้เห็นทั้งจุดแข็งและจุดอ่อนของ XSLT ในสภาพแวดล้อมการผลิต ในอุตสาหกรรมสตรีมมิ่งเพลง บริษัทที่ประมวลผลไฟล์ XML หลายล้านไฟล์พบว่า XSLT มีปัญหาในการจัดการการเปลี่ยนแปลงสคีมาระหว่างเวอร์ชันต่างๆ ของมาตรฐานอุตสาหกรรมเช่น DDEX ลักษณะที่แข็งแกร่งของการแปลง XSLT ทำให้เปราะบางเมื่อต้องจัดการกับรูปแบบข้อมูลที่พัฒนาไป
อย่างไรก็ตาม XSLT ยังคงประสบความสำเร็จในช่องทางเฉพาะที่การประมวลผล XML ยังคงเป็นหลัก ระบบองค์กร ไปป์ไลน์การเผยแพร่ และสถานการณ์การรวมข้อมูลยังคงได้รับประโยชน์จากแนวทางการประกาศของ XSLT ในการแปลง
อนาคตของเทคโนโลยี XML
ความพยายามในการยกเลิกจากเบราว์เซอร์สะท้อนถึงแนวโน้มอุตสาหกรรมที่กว้างขึ้นในการหันไปจากเทคโนโลยีที่อิงบน XML ไปสู่ JSON และรูปแบบข้อมูลที่ง่ายกว่า การพัฒนาเว็บสมัยใหม่ชอบแนวทางที่เบาและเป็นมิตรกับ JavaScript มากกว่าระบบนิเวศ XML ที่หนักหน่วงซึ่งครอบงำในช่วงต้นปี 2000
แต่การคงอยู่ของการใช้งาน XSLT แสดงให้เห็นว่าโดเมนปัญหาบางอย่างยังคงได้รับประโยชน์จากความสามารถเฉพาะของมัน ความท้าทายอยู่ที่การสร้างสมดุลระหว่างภาระการบำรุงรักษาของผู้พัฒนาเบราว์เซอร์กับความต้องการของผู้ใช้ที่มีอยู่ซึ่งพึ่งพาการประมวลผล XSLT ฝั่งไคลเอนต์
ในขณะที่การถกเถียงยังคงดำเนินต่อไป ผลลัพธ์น่าจะขึ้นอยู่กับว่าชุมชน XSLT สามารถแสดงให้เห็นการใช้งานที่เพียงพอเพื่อให้เหตุผลในการสนับสนุนเบราว์เซอร์ต่อไป หรือว่าโซลูชันทางเลือกจะทำให้การประมวลผล XSLT ฝั่งไคลเอนต์ล้าสมัยในที่สุด
อ้างอิง: Why You Should Be Using XSLT 3.0