XSLT - Sistem Build Native Zero-Config untuk Web

 (github.com/pacocoursey)
2 poin oleh GN⁺ 2025-06-28 | 1 komentar | Bagikan ke WhatsApp
  • XSLT adalah alat build bawaan untuk web yang bisa langsung digunakan tanpa sistem build yang rumit
  • Sebagian besar sistem build situs statis memiliki masalah dalam hal kompleksitas, sulit dipahami, dan ketergantungan pada framework
  • Dengan memanfaatkan XML dan XSLT, HTML dapat langsung dihasilkan di browser, sehingga pemrosesan data dinamis dan pembuatan markup menjadi mudah
  • Semua browser utama mendukung transformasi berbasis XSLT, sehingga dapat digunakan tanpa JavaScript tambahan atau alat terpisah
  • Ini memang bukan solusi yang sempurna, tetapi sangat bernilai sebagai alternatif yang sederhana dan fleksibel berbasis standar web

Pengantar dan Latar Masalah

  • Sebagian besar proses pengembangan situs web statis terdiri dari file untuk data (.json, .md, .txt), sistem build terpisah (Hugo, Next.js, Astro, dll.), dan struktur keluaran HTML
  • Sistem build semakin bertambah kompleks, dan bahkan blog kecil pun makin sulit dipahami serta dijalankan
  • Saat mencoba menyingkirkan framework dan bekerja hanya dengan HTML, CSS, serta spesifikasi standar (HTTP, URI, HTML), muncul keterbatasan dalam pemeliharaan seperti pengulangan header atau footer
  • HTML import dan web component juga sempat dicoba, tetapi yang pertama tidak didukung, sedangkan yang kedua tidak menjadi alternatif karena masalah ketergantungan pada mesin JavaScript

Menjadikan Browser Web sebagai Sistem Build

  • Gagasan ini berangkat dari fakta bahwa browser web itu sendiri mendukung berbagai transformasi data (text/html, text/markdown, application/xml, dll.)
  • Dengan menelaah spesifikasi web secara mendalam, dicari cara memecahkan masalah tanpa alat eksternal dan framework yang tidak perlu

Pemanfaatan XSLT

  • Saat ingin menampilkan feed RSS dengan lebih menarik, ditemukanlah spesifikasi XSLT
  • XSLT adalah teknologi standar resmi yang dapat mengekspresikan baik data XML maupun struktur keluaran HTML
  • Cara pakainya sederhana
    • Misalnya, susun data di blog.xml
    • Lalu hubungkan stylesheet XSLT seperti berikut
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • Di blog.xsl, tulis template HTML dan aturan pemetaan data
  • Template, perulangan, variabel, import file eksternal, dan sebagian besar fitur sistem build didukung

Cara Menjalankan dan Kelebihannya

  • Tanpa alat tambahan, cukup buka file XML di browser web, maka hasil transformasinya akan langsung dirender
  • Format XML mirip dengan HTML sehingga ramah bagi manusia dan mudah dipelihara, dan tidak terlalu merepotkan bila digunakan menggantikan JSON
  • Semua browser web utama mendukung transformasi berbasis XSLT secara native, sehingga klien dapat langsung memeriksa hasil transformasinya
  • Fakta bahwa JavaScript, alat build terpisah, dan bundler tidak diperlukan adalah nilai plus yang sangat besar
  • XSLT memang bukan solusi serba bisa yang mutlak, tetapi merupakan alternatif build web yang sederhana sekaligus dapat dikembangkan

Kesimpulan

  • Menemukan kembali nilai dari teknologi lama (XSLT) dan standar yang jelas
  • Memanfaatkan browser web sebagai sistem build adalah opsi berguna yang layak ditambahkan ke kotak peralatan pengembangan web

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-28
Komentar Hacker News

  • Perusahaan tempat aku dulu bekerja sangat banyak menggunakan XSLT pada template XML, dan kemungkinan besar sampai sekarang pun masih begitu. Sejujurnya itu bukan pilihan yang bagus, dan kalau memungkinkan mereka mungkin ingin pindah ke hal lain

    1. XSLT punya standar yang lebih baru, tetapi versi 1.0 masih yang paling dominan, padahal versi ini terbatas dan punya banyak keanehan dibanding standar yang lebih baru
    2. Masalah performa pada template XSLT sangat sulit diselesaikan. Karena sifat XSLT sebagai bahasa bergaya fungsional yang Turing-complete, performanya sulit terlihat. Untuk kebanyakan dokumen memang baik-baik saja, tetapi begitu masuk 100 baris, tiba-tiba meledak. Kode yang memproses tabel bisa punya performa O(N^2) dan hampir mustahil dioptimalkan. Misalnya, bisa saja ada XPath O(N) di setiap baris. Kalau tidak salah ingat, template itu butuh lebih dari 7 menit untuk memproses satu dokumen.
      JS juga punya masalah, tapi setidaknya kita tidak dipaksa menerima kompleksitas algoritme seperti ini tanpa bisa memperbaikinya

    • XSLT/XPath sudah berkembang cukup jauh setelah 1.0. Berbagai fitur seperti key(index) muncul dan sangat mempercepat pemrosesan. Jika memakai implementasi XSLT berkualitas seperti Saxon, masalah performa juga jauh berkurang. Saat mengubah XML ke format lain, menurutku jarang ada yang senyaman XSLT untuk menata struktur logika

    • XSLT cukup sulit dipelajari. Rasanya seperti Prolog yang melamun, dan kalau sudah benar-benar mahir, ada sensasi menyenangkan seperti saat memecahkan Sudoku. Tapi dalam kebanyakan kasus, template tidak perlu serumit itu, jadi sulit menjadi pilihan standar. Dan XML sendiri juga bukan format yang disukai semua orang

    • Aku agak bingung dengan bagian bahwa XSLT 1.0 masih banyak dipakai. Bahkan pada 2013, 1.0 sudah hampir dianggap usang, dan Saxon yang bisa memakai XSLT 2 gratis serta performanya juga sangat bagus. Aku belum pernah mengalami masalah performa saat transformasi, baik untuk dokumen besar maupun kecil

    • Saat XSLT muncul, memang wajar memproses XML dengan isi yang sangat panjang. Jadi, kalau loop berulang seperti ini sampai bertumpuk, ya memang tinggal menunggu meledak

    • Aku penasaran apakah yang dipakai adalah Saxon versi komersial. Harganya juga tidak terlalu mahal, dan menurutku dukungan standar baru, performa, serta berbagai fiturnya benar-benar sepadan. Waktu dulu memakainya, setahuku ada optimisasi yang cukup cerdas

  • Browser era 90-00-an semuanya berbeda-beda, jadi JS mulai diperkenalkan agar perilakunya bisa diseragamkan
    Sebenarnya yang kami inginkan hanyalah styling CSS yang keren, tetapi waktu itu belum benar-benar bisa dipakai
    Seiring waktu, satu browser mulai memimpin dan browser lain juga makin mirip satu sama lain (aturan Highlander, meski Firefox juga lumayan bertahan)
    Framework sudah menjadi hal yang lumrah, lalu menetap sebagai cara untuk menyamakan UI di semua browser. Dan paradigmanya sendiri bergeser ke rendering data JSON
    Sekarang kita hidup di zaman ketika halaman web tradisional yang dibuat di server pun cepat dan hemat memori
    Aku memikirkan ini karena baru-baru ini saat migrasi dari sistem legacy, aku kembali merasakan situs yang bekerja dengan model request HTTP per halaman seperti standar tahun 2000-an. Setiap aksi memang butuh refresh, tetapi justru terasa jauh lebih cepat daripada sistem yang memakai React
    Alasannya

    1. Internet sekarang sangat cepat
    2. Memori ponsel melimpah, tetapi framework JS membuang-buangnya
    3. Backend, dulu maupun sekarang, tetap CRUD, CRUD, CRUD (+pagination, +transaction)

    • AJAX dan pembaruan DOM tidak muncul semata-mata untuk jadi lebih cepat. Itu muncul untuk keluar dari paradigma web, yaitu dari 'website/web document'. Reload satu halaman penuh adalah mekanisme yang bermakna dalam paradigma yang berpusat pada dokumen. Untuk contoh sederhana seperti HN, struktur seperti ini sangat cocok. Banyak situs sebenarnya bisa berjalan cukup baik dengan pendekatan ini tanpa framework JS.
      Tetapi mengatakan bahwa "semua orang bisa kembali ke reload halaman penuh" cukup jauh dari realitas. Pada 'web application' yang benar-benar memerlukan interaksi kompleks, reload seluruh halaman adalah UX yang sangat buruk.
      Ringkasnya,
      untuk 'website', 'web document', 'form sederhana', dan sejenisnya, reload satu halaman penuh sering kali sudah cukup
      tetapi untuk 'web application' yang membutuhkan tampilan/manipulasi data kompleks, tidak demikian

    • Timeline yang kuingat dari masa itu sedikit berbeda. JS sejak awal lebih dipakai untuk elemen interaktif (DHTML, AJAX, dll.) daripada untuk menyeragamkan perilaku browser. Untuk layout yang benar-benar rapi, semuanya nyaris bergantung pada trik-trik dan deteksi user agent. Bahkan ketika CSS menjadi lebih kuat, masalah konsistensi tidak mudah terselesaikan. CSS garden, semantic markup, penggunaan tabel berlebihan, semua itu adalah suasana zaman tersebut, dan bahkan sampai lulus uji ACID pertama pun butuh waktu lama sekali. Aku skeptis framework banyak berpengaruh terhadap konsistensi UI—sejak setelah jQuery, justru CSS sendiri yang paling menentukan konsistensi visual.
      Tentu saja ini juga bisa cuma ingatan pribadiku

    • Di stack teknologi modern, aku setuju bahwa halaman web tradisional dengan server-side rendering itu cepat dan ringan
      Pada stack .NET/Kestrel/SQLite milikku, respons SSR sulit melewati 4ms. Kebanyakan malah di kisaran 100 mikrodetik. Setiap halaman membentuk data sesuai kebutuhan view dengan beberapa query dan join yang kompleks
      Bahkan pada kasus ekstrem seperti membuat tabel 100.000 baris, performa meningkat tajam jika pengolahan datanya dilakukan dengan baik sebelum menyusun string HTML. Performa LINQ juga sangat bagus, tetapi kalau membuat collection per baris, justru jadi sangat tidak efisien ketika jumlah data membesar
      Menurut pengalamanku, untuk optimisasi performa terbaik, template engine HTML dan database harus diletakkan sedekat mungkin. Pada akhirnya DOM hanyalah aliran byte. Tidak perlu repot membuat AST/parser yang rumit; cukup gabungkan StringBuilder dan query SQL saja sudah memadai.
      Keberatan terhadap pendekatan sederhana seperti ini biasanya selalu cuma perdebatan dari pihak keamanan yang bilang "aku tidak percaya developer bisa melakukan HTML escaping dengan benar"

    • Pernyataan bahwa "dengan teknologi modern, pendekatan klasik halaman web dari server sudah cukup" bisa menjadi cerita yang sangat berbeda kalau latensi jaringan tinggi
      tautan referensi

  • Saat XML enterprise tahun 2000-an membengkak terlalu besar, teknologinya jadi terlihat ketinggalan zaman, dan akhirnya semua orang jatuh cinta pada 'kerapian' JSON. Padahal teknologi seperti XSLT dan XPath sebenarnya sudah sangat matang dan telah menyelesaikan banyak masalah yang sampai hari ini masih kita pikirkan
    Aku juga dulu pernah sangat menyalahgunakan include di XSLT, misalnya dengan PHP stream wrapper seperti <xsl:include href="mycorp://invoice/1234">
    Sejujurnya sekarang terasa agak kuno, tetapi tetap saja aku kurang nyaman membiarkan browser memproses XSLT lokal. Dulu itu benar-benar ladang ranjau kompatibilitas

    • Elemen-elemen "dasar" XML masih terasa dirindukan di JSON. Misalnya spesifikasi yang benar-benar standar, atau definisi skema; dalam hal ini XML jauh lebih unggul dan JSON butuh hampir 10 tahun untuk mengejar.
      Terakhir kali aku benar-benar menyentuh XML adalah lewat teknologi transmisi bernama EXI. Itu mengubah dokumen XML menjadi stream biner terkompresi, jadi alurnya struktur ↔ ASCII ↔ kompresi/transmisi ↔ balik lagi, yang tentu merepotkan. Sekarang protobuf dan gRPC lebih dominan, tetapi kalau XML terus dipakai, mungkin saja kita hidup di dunia ideal versiku di mana semuanya berbasis standar dan saling kompatibel. Kenyataannya memang ada jurang besar antara protobuf/gRPC dan JSON API, tapi mungkin itu justru lebih baik

    • Menurutku XML adalah format yang cukup bagus. Memang panjang dan verbose, tetapi dibanding YAML, XML jauh lebih unggul dalam presisi dan daya ekspresi
      XPath sulit dibiasakan, tetapi setelah bereksperimen, pada akhirnya kita bisa melakukan apa yang kita inginkan
      XSLT menurutku konsep yang benar-benar gila. Harus disingkirkan

    • Game bernama Rimworld menyimpan semua data pengaturannya dalam XML dan memungkinkan modding lewat XPath. Kombinasi ini benar-benar kuat. Untuk kustomisasi data lokal, sulit mencari yang lebih baik. Namun kebanyakan game tampaknya enggan memakai ini karena XML sudah dicap "kuno"
      Dokumentasi resmi modding XPath Rimworld

    • Cerita bahwa XML enterprise di awal 2000-an membesar tak terkendali itu memang benar. Awalnya XML adalah versi sederhana dari SGML agar bisa dipakai di web, untuk penyampaian markup dan perluasan vocabulary. Pada akhirnya yang bertahan hanya SVG dan MathML. Lalu karena tersapu ledakan web, W3C/MS mulai menggelontorkan SOAP, spesifikasi WS-*, dan lain-lain. Ada masa yang penuh kegilaan ketika bahasa seperti XSLT yang bertulang Scheme pun dipaksa masuk ke XML. Bahkan JavaScript juga lahir di era ketika setidaknya namanya dibuat menumpang pada Java

    • XPath agak disayangkan karena namespace membuat query-nya jadi sangat panjang sampai menjengkelkan

  • Sampai sekarang aku masih menata feed-ku dengan XSLT.
    Contoh feed RSS
    Contoh XSLT

    • Kalau melihat hal seperti ini, jadi terpikir apakah blog seharusnya memang cuma berupa feed RSS

    • Aku selalu lupa bahwa XML memang dari awal bisa melakukan hal seperti ini. Entah kenapa secara intuitif terasa agak janggal

    • Ini benar-benar dibuat dengan sangat keren. Andai lebih banyak orang mengadopsi contoh seperti ini secara kreatif

  • Di pekerjaan pertamaku (saat umur 19), aku pernah ditugaskan mengustomisasi Google Search Appliance. Itu proyek memasang CentOS di server Dell kuning mahal, lalu menerapkan pencarian full-text dokumen CIFS dengan Python ala Google.
    Sekitar tahun 2011, XHTML sedang populer, dan di Google Search Appliance, data XML dari backend diubah menjadi XHTML dengan XSLT. Aku membongkar template contohnya dan membuat UI aneh yang disesuaikan untuk intranet perusahaan, sambil mencomot dan menyambung aset lama dari Coldfusion, StackOverflow, W3Schools, dan lain-lain
    Pengalaman ini segera kuhapus dari CV. Setelah itu, para kontraktor DoD terus memanggilku sebagai "ahli XML" untuk proyek modernisasi sistem dokumentasi, dan itu melelahkan
    Jadi lain kali saat kamu menghela napas karena harus memutar array di JSX dari JSON ke interface TypeScript, ingatlah ceritaku. Setidaknya itu masih lebih baik daripada melakukan hal yang sama dengan XSLT

  • Aku memang orang yang mencari kesederhanaan. Aku suka dokumen yang mudah seperti readme manusia gua. Kadang rasanya seperti memukul keyboard seperti manusia gua juga. Aku tidak mengerjakan website dan tidak terlalu paham XSLT. Kadang aku mengutak-atik XML, dan ingin menampilkan sesuatu untuk pengguna. Format file terlalu banyak sampai bikin pusing. Tapi aku tetap suka sesuatu yang enak dilihat. Mungkin aku juga akan memakai ini
    Terima kasih sudah membaca spesifikasinya, dan terima kasih sudah membuat tool ini

  • Banyak orang bilang XML itu verbose dan tampak rumit, tetapi kalau benar-benar dipakai, itu format yang hebat
    Kita bisa memvalidasi dengan DTD dan menghasilkan output dengan XSLT agar mudah dibaca manusia
    Bagiku XML adalah format teks seperti C++. Matang, 'sudah lengkap baterainya', kuat, dan bisa dihubungkan ke bahasa apa pun
    Seperti bahasa tua yang matang pada umumnya, aku agak sedih karena sekarang jadi tren untuk menghina XML sebagai konten aneh. Kalau tidak cocok untuk kebutuhanmu, ya jangan dipakai, tetapi tidak perlu dibenci berlebihan

    • Aku penasaran, kenapa pakainya DTD dan bukan XSD?

  • Menarik sekali mendengar bahwa "XSLT bisa langsung jalan di browser". Terakhir kali aku memakai XSLT itu 20 tahun lalu, dan waktu itu rasanya semua estetika khas XSLT tenggelam di bawah Java enterprise yang sangat rumit.
    Tetapi kalau XSLT memang berjalan bawaan di browser, apakah berarti cawan suci template statis sejati tanpa host framework sebenarnya sudah sangat dekat?

    • Browser hanya mendukung XSLT 1.0. Dan kabarnya dukungan ini pun suatu saat bisa hilang. Seandainya browser mendukung sampai 3.0, itu pasti akan sangat berguna untuk membuat halaman web statis

    • Aku juga punya pengalaman bahwa kita tidak selalu harus memakai menara 'Java enterprise besar'. Kami memakainya hanya dengan tomcat dan beberapa library apache, dan hasilnya cukup baik. Dari CMS, HTML yang dibuat dalam XML diberi personalisasi dalam bentuk tag XML, lalu berkat server-side caching proxy, transformasinya cepat dan mampu menangani trafik besar. Kuncinya adalah langsung mengalirkan output stream XSLT ke klien tanpa buffering seluruhnya di memori.
      Sekarang, berkat wasm, kita bisa menjalankan hampir apa saja di browser, tetapi di masa awal JS itu benar-benar menyiksa, dan para desainer saja sudah bagus kalau mau menyerahkan PSD Photoshop dengan rapi. Masa-masa Google Maps dan Gmail keluar, membuat UI berat JavaScript sambil harus mendukung Netscape dan Internet Explorer sekaligus benar-benar neraka

    • Booming XHTML sebenarnya juga mulai karena 'cawan suci template statis' ini. Tapi orang-orang yang benar-benar paham justru bicara setengah berbisik, seperti jargon internal, dan tak ada yang mengatakannya terang-terangan—suasananya agak aneh

    • Aku pernah bekerja pada situs XSLT di dalam browser pada 2008, dan bahkan pada awal 2000-an pun sebenarnya itu sudah didukung

    • Chrome memakai libxslt, Firefox memakai engine 1.0 bernama Transformiix. Chrome hanya mendukung exsl:node-set, sedangkan Firefox mendukung berbagai ekstensi EXSLT (meski tidak semuanya)
      Aku juga merilis tool kecil yang memberi tahu informasi sederhana tentang prosesor XSLT dan daftar ekstensi yang tersedia.
      GitHub - xslt-detect-ext
      Kamu bisa menyeret file out/detect.xslt ke browser untuk memeriksa informasinya (Chrome, Firefox). Safari tidak bisa pada versi Windows lama

  • Saat masih SMA di tahun 90-an dan disebut "web designer", aku pernah memakai pipeline dialek DSSSL untuk menghasilkan situs secara otomatis dari newsfeed. Sampai sekarang pun aku masih suka transformasi XSLT. Aku juga memakai tool seperti bananas XI reader untuk transformasi teks nyata dan pekerjaan template
    Namun, orang yang benar-benar menyukai tooling seperti ini sangat sedikit, dan ketika posisiku digantikan orang lain, teknologi yang sempat diperkenalkan biasanya cepat menghilang
    bananas XI reader

  • Untuk menunjukkan seberapa parah demam XML dan XSLT di awal 2000-an, perusahaan tempatku bekerja bahkan sampai membuat ASIC yang bisa mem-parsing XML pada kecepatan real-time dan memproses XSLT langsung di chip. Saat itu kami benar-benar percaya masa depan internet akan berjalan sepenuhnya di atas XML/XSLT.
    Pada akhirnya perusahaan itu diakuisisi Intel, dan teknologinya masuk ke sisi akselerator SSE

    • Kalau struktur semacam itu—bisa menginterpretasikan XML dan langsung memproses XSLT di ASIC—menjadi arus utama, aku membayangkan sekarang website akan sangat-sangat cepat

    • IBM sampai sekarang masih menjual hardware dengan kemampuan serupa yang tertanam di dalamnya (DataPower Gateway)