- XSLT dapat digunakan seperti sistem build sisi klien yang berjalan di browser web untuk mengubah data XML menjadi HTML, sekaligus mengurangi kompleksitas generator situs statis
- Situs statis pada umumnya terdiri dari data seperti
.json, .md, .txt, sistem build seperti Hugo, Next.js, Astro, dan keluaran HTML statis, tetapi framework besar bisa menciptakan kompleksitas berlebihan bahkan untuk blog Markdown yang sederhana
- Jika hanya ingin memakai HTML dan CSS, header dan footer di banyak halaman harus disalin secara manual; HTML import tidak ada, dan Web Component memiliki batasan karena membutuhkan mesin JavaScript
- Dengan menambahkan
<?xml-stylesheet type="text/xsl" href="blog.xsl"?> ke dokumen XML dan menulis template XSLT, browser dapat menghasilkan keluaran HTML saat halaman dikunjungi
- Pendekatan ini dapat dideploy sebagai file statis tanpa JavaScript, tetapi bukan solusi sempurna yang menggantikan semuanya; ini adalah opsi lain yang dapat ditambahkan ke kotak alat pengembangan web
Kompleksitas build situs statis
- Alur pembuatan situs web statis pada umumnya terbagi menjadi data, sistem build, dan keluaran HTML statis
- Data disimpan sebagai file seperti
.json, .md, .txt
- Contoh sistem build mencakup Hugo, Next.js, Astro, dan lainnya
- Hasil akhirnya adalah HTML statis
- Meski ingin menghapus framework dan hanya memakai HTML dan CSS sederhana, saat jumlah halaman bertambah, header dan footer bersama harus terus disalin
- Opsi alternatif yang bisa terpikir masing-masing memiliki batasan
- HTML import tidak ada
- Web Component membutuhkan JavaScript, sehingga membutuhkan mesin JavaScript
Gagasan memakai browser sebagai sistem build
- Browser web sudah dapat memahami berbagai format seperti
text/html, text/markdown, application/xml
- Dengan memakai browser sebagai sistem yang membuat HTML dari data, kita dapat membuat alur berbasis standar web tanpa alat build terpisah
- Dalam proses menampilkan feed RSS dengan lebih baik, ditemukan bahwa XSLT dapat digunakan sebagai stylesheet untuk dokumen XML
- XML terlihat mirip HTML, tetapi merupakan cara merepresentasikan data yang tidak terbatas hanya pada data web, dan dapat dipelajari melalui XML spec
Cara mengubah XML menjadi HTML
- Dokumen XML dapat memuat data seperti tulisan blog
<?xml version="1.0"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- Deklarasi untuk menghubungkan stylesheet XSL dapat ditambahkan ke dokumen 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>
- Template XSLT menerima input XML dan menghasilkan struktur 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 dapat dilihat sebagai bentuk
(XML) => HTML, dan menyediakan fitur sistem build seperti loop, variabel, dan import
- Data dari dokumen XML induk dapat diambil di XSLT dan ditampilkan secara dinamis
<head>
<xsl:value-of select="title" /> | Blog
</head>
Cara menjalankan dan deployment
- Transformasi XSLT dapat dijalankan dengan membuka file XML di browser
open blog.xml -a Safari
- Semua browser web mendukung transformasi XSLT saat halaman dikunjungi, lalu menampilkan HTML hasil transformasi
- Pendekatan ini bekerja seperti sistem build sisi klien yang berjalan di komputer pengguna
- File statis mudah dideploy dan berjalan tanpa JavaScript
Batasan dan posisinya
- Data blog harus disimpan sebagai XML, bukan JSON, tetapi XML terlihat seperti HTML, mudah diparse, fleksibel, dan didukung secara native di web
- Pendekatan XSLT tidak sempurna dan tidak menggantikan semuanya
- Ini menjadi alat lain yang dapat digunakan untuk membuat situs web statis sederhana dengan memanfaatkan standar web lama, spesifikasi, dan fitur browser
1 komentar
Komentar Hacker News
Saya pernah bekerja di perusahaan yang banyak memakai XSLT untuk template XML, dan itu tidak bagus; kalau bisa, mungkin kami sudah pindah
Meski ada standar baru, XSLT 1.0 masih dominan, dan dibanding standar modern ia terbatas dan aneh
Memecahkan masalah performa pada template XSLT nyaris seperti neraka. Ini bahasa bergaya fungsional yang Turing-complete, tetapi performanya sangat diabstraksikan; template yang berjalan baik pada kebanyakan dokumen bisa meledak hanya karena satu tabel 100 baris. Ternyata template pemrosesan tabelnya O(N^2) atau lebih, dan XPath untuk tiap baris mungkin juga O(N) atau lebih, sehingga cara optimasinya pun tidak jelas. Seingat saya, memproses satu dokumen dengan XSLT memakan waktu lebih dari 7 menit
JS punya masalah lain, tetapi gagal menyelesaikan masalah kompleksitas algoritmik bukan salah satunya
Sekarang ada fitur seperti key(indeks) yang bisa sangat mempercepat pemrosesan, dan implementasi XSLT yang bagus seperti Saxon juga jelas membantu dari sisi performa
Saat mengubah XML ke format lain, XSLT cukup nyaman karena logikanya bisa distrukturkan
Pada 2013 saya banyak memakai XSLT, dan saat itu 1.0 sudah benar-benar mati di mana pun saya melihatnya. Saxon gratis untuk XSLT 2 dan sangat bagus
Saya mengonversi baik dokumen raksasa maupun banyak dokumen kecil, tetapi sama sekali tidak ada masalah performa
Setelah dikuasai, ia memberi kepuasan seperti memecahkan Sudoku, tetapi biasanya alat yang jauh lebih sedikit sudah cukup untuk mencapai tujuan, sehingga sulit menjadi pendekatan standar untuk build atau template
Selain itu, XML juga bukan format yang disukai semua orang
Kalau ingatan saya benar, ia juga melakukan optimasi yang cukup cerdas
Ini mungkin tebakan yang cukup berlebihan, tetapi pada 1990–2000-an browser berbeda-beda, jadi orang mulai memakai JS untuk membuat perilaku yang sama, padahal yang sebenarnya dibutuhkan adalah gaya CSS yang baik dan perilaku yang konsisten
Seiring waktu, browser mulai berperilaku mirip, tetapi kita sudah telanjur terbiasa dengan framework yang membuat halaman tampak sama di semua browser, lalu bergeser ke paradigma merender data JSON
Dengan tingkat teknologi sekarang, halaman web gaya lama yang dibuat server pun sudah lebih dari cukup; jejaknya kecil, lebih cepat, dan memakai memori lebih sedikit
Baru-baru ini saat memigrasikan sistem legacy, saya melihat struktur ala 2000-an, “satu halaman per permintaan HTTP”, dan meski semua tindakan seperti tambah/hapus mengharuskan refresh, itu jauh lebih cepat daripada sistem React. Internet sudah lebih cepat, memori ponsel dihamburkan oleh framework JS, dan backend pada dasarnya masih didominasi CRUD, pagination, dan transaksi
Di tempat sederhana seperti HN, refresh seluruh halaman memang cocok, dan ada banyak kasus di mana situs web sederhana sudah cukup tanpa framework JS
Namun tidak benar bahwa semua orang bisa kembali ke refresh seluruh halaman. Pada aplikasi web nyata, ada kasus ketika refresh penuh menjadi pengalaman pengguna yang buruk
Secara umum situs web, dokumen web, dan formulir web bisa saja memakai refresh penuh, tetapi itu tidak cocok untuk aplikasi web yang harus menampilkan dan memanipulasi hal-hal kompleks
Saat itu orang mengandalkan deteksi user agent dan urutan berbagai quirks untuk menyesuaikan layout, dan sepertinya JS juga tidak mudah mengakses elemen terkait layout
CSS pun tidak langsung menghadirkan konsistensi. Bahkan setelah fiturnya lengkap, kondisinya masih kacau; itu era ketika semua orang terkagum-kagum pada CSS Zen Garden tetapi kode nyata masih dibuat dengan tabel
Saya juga tidak tahu apakah framework punya pengaruh besar pada “tampilan yang konsisten”. Saat mulai beralih dari jQuery, CSS sudah menangani tampilan
Itu dalam kondisi tiap halaman menjalankan beberapa query dan banyak memakai join kompleks untuk membuat bentuk respons khusus view. Jika data diambil dalam bentuk yang tepat sebelum diinterpolasikan ke string HTML, performa sangat terbantu pada kasus batas seperti tabel 100 ribu baris
Dari pengalaman saya, semakin dekat HTML template engine dengan database, semakin baik. Pada akhirnya DOM terstruktur pun hanyalah byte stream yang harus dikirim ke klien
Saya melihat munculnya industri yang tidak bermakna dan menjadi tujuan itu sendiri, sibuk memikirkan pendekatan AST/parser yang rumit untuk hal-hal yang cukup diselesaikan dengan StringBuilder dan query SQL yang cerdas. Argumen penentangnya biasanya berujung pada sikap ala pengawas keamanan yang menganggap developer tidak bisa memakai fungsi escape HTML dengan benar
Sangat disayangkan bahwa karena kebesaran XML enterprise pada tahun 2000-an, teknologinya jadi tampak usang dan semua orang beralih ke JSON yang lebih “rapi”
XSLT dan XPath sudah sangat matang, dan sudah memecahkan banyak masalah yang masih dialami format lain
Dulu saya juga punya kenangan indah menyalahgunakan wrapper stream PHP dan XSLT include
Mungkin ini prasangka lama, tetapi membiarkan browser memprosesnya secara lokal masih terasa sedikit mengkhawatirkan. Dulu itu ladang ranjau kompatibilitas
Hal-hal seperti skema di sisi XML jauh lebih terdefinisi dengan baik, dan rasanya butuh hampir 10 tahun bagi sisi JSON untuk mengejar
Teknologi XML terakhir yang benar-benar saya tangani adalah EXI, sebuah cara transmisi yang mengubah dokumen XML menjadi stream data biner terkompresi. Karena memang agak konyol mengubah struktur data menjadi ASCII, mengompresnya, mengirimkannya lewat HTTP, lalu mengembalikannya lagi
Sekarang keluarga protobuf lebih populer, tetapi kalau XML terus bertahan, mungkin kita akan punya dunia standar-standar kompatibel yang saling terhubung. Sebaliknya, antara protobuf/gRPC dan JSON API ada tembok yang kokoh; mungkin itu justru lebih baik
XPath juga tidak buruk. Sulit mengingat semua sintaksnya, tetapi dengan sedikit eksperimen biasanya bisa sampai ke tempat yang diinginkan
XSLT adalah omong kosong gila total dan seharusnya dibakar sampai musnah
Sebagai kombinasi yang memungkinkan modifikasi lokal data yang relatif stabil, XML + XPath sangat diremehkan. Mungkin karena XML punya reputasi “kuno”, saya jarang melihatnya di game lain, tetapi untuk kegunaan ini sistemnya sangat tangguh
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
Namun ketika demam web membesar, W3C dan MS membuat hal-hal seperti SOAP dan WS-*, dan muncul juga beberapa bahasa pemrograman berbasis XML termasuk XSLT
Jangan bilang ke orang-orang HN, tetapi XSLT awalnya adalah Scheme, hanya saja harus berupa XML; itu era kegilaan yang sama seperti JavaScript harus meminjam nama Java
Belakangan ini saya memakai XSLT untuk mempercantik feed
Contohnya https://susam.net/feed.xml dan https://susam.net/feed.xsl
Salah satu proyek pertama saya sebagai software engineer profesional pada usia 19 tahun adalah mengustomisasi dua Google Search Appliance yang dibeli perusahaan
Perusahaan mengira proses pengembangan bisnis akan membaik jika mereka bisa melakukan pencarian full-text pada repositori dokumen CIFS yang sangat besar, lalu menghabiskan ratusan ribu dolar untuk rak server Dell berpanel depan kuning yang menjalankan CentOS dan Python ala Google
Sekitar 2011, XHTML sedang tren, dan GSA bekerja dengan mengubah hasil pencarian yang disediakan sebagai XML dari backend menjadi XHTML menggunakan XSLT
Saya mengambil template bawaan dan membuat semacam monster mirip portal intranet perusahaan dengan halaman aplikasi ColdFusion yang dirender, StackOverflow, serta aset dan markup yang dicuri dari tutorial W3Schools
Setelah itu, beberapa kontraktor DoD menghubungi saya di LinkedIn setelah melihat “keahlian XML” untuk mengajak saya ikut proyek modernisasi dokumen, dan saya cepat belajar bahwa pengalaman ini sebaiknya saya hapus dari resume
Saat menghela napas sambil melakukan iterasi array interface TypeScript yang dideserialisasi dari respons JSON ke JSX, bayangkan saya dulu melakukan hal yang sama dengan XSLT
Banyak orang mengeluh XML bertele-tele dan dari jauh tampak rumit, tetapi saya suka bahwa kita bisa membuat format file yang bagus berbasis XML, memvalidasinya dengan DTD, lalu memformatnya agar mudah dibaca manusia dengan XSLT jika perlu
XML itu seperti C++ untuk format file berbasis teks. Matang, sudah termasuk baterai, kuat, dan kalau mau bisa dipakai dari bahasa apa pun
Sama seperti bahasa-bahasa tua dan matang dicaci karena keanehan masing-masing, mencaci XML juga sudah menjadi tren. Kalau tidak cocok untuk kebutuhan Anda, jangan pakai, tetapi tidak perlu memperlakukannya seperti monster
Sebagai contoh sejauh apa XML dan XSLT melangkah pada awal 2000-an, perusahaan tempat saya dulu bekerja membuat ASIC yang mem-parse XML pada line rate dan memproses XSLT secara native di chip
Karena saat itu diperkirakan masa depan internet seluruhnya adalah XML/XSLT. Intel mengakuisisi perusahaan itu, dan teknologi internalnya masuk ke akselerator SSE
Terkejut dengan “keajaiban” bahwa XSLT berjalan secara native di browser
Terakhir kali saya memakai XSLT sekitar 20 tahun lalu, tetapi saat itu saya menggunakannya sangat banyak selama beberapa tahun. Pada masa itu, untuk membuatnya berjalan diperlukan menara Java enterprise yang besar dan goyah, yang mengurangi keanggunan XSLT itu sendiri
Namun jika XSLT benar-benar berjalan di browser, berarti cawan suci berupa template statis yang bisa di-host di mana saja selama ini sudah ada tepat di depan mata
Kalau saja dukungan v3 masuk, sepertinya akan lebih mudah menyediakan halaman web statis dengan dukungan template native
CMS menghasilkan file XML berisi HTML tertanam, dan caching-nya sangat baik. Personalisasi dan rendering HTML/JS ditangani di sisi server bersama proxy caching
Transformasi XSL dijalankan di belakang cache dan cukup cepat untuk mengikuti trafik yang besar. Di sini tujuan XML adalah memasukkan HTML yang sudah siap sebagai blob, dan hanya menyisakan bagian yang perlu personalisasi sebagai tag XML
Transformasi akhir cukup cepat, dan kuncinya adalah tidak menaruh output transformator XSL ke buffer memori penuh, melainkan langsung mengalirkannya ke stream output respons. Untuk respons besar, ini masih teknik yang bagus sampai sekarang, tetapi banyak framework memilih buffering memori sebagai default sehingga bagian ini terlewat
Sekarang tentu saja kita bisa menjalankan apa pun yang diinginkan di browser dengan wasm. Tetapi saat itu JavaScript berantakan, dan desainer paling banter menyerahkan file Photoshop. Kami harus memotongnya menjadi frame dan table, dan pada masa Google Maps serta Gmail baru saja muncul, kami membuat UI CMS yang cukup JavaScript-heavy sambil mendukung Netscape dan Internet Explorer
Firefox punya bug yang sangat menjengkelkan: ketika perlu
disable-output-escapinguntuk merender HTML di dalam dokumen sebagai DOM sungguhan, itu tidak bekerja dengan benar dan malah dirender sebagai teks HTML mentahDahulu sekali, dalam sebuah proyek distopia yang sangat jauh, seseorang yang pesimistis bahwa tim bisa menyelaraskan pengembangan Java dengan workbook yang berubah cepat secara paralel mengajukan solusi
Strukturnya adalah workbook yang dibuat dengan Excel diubah oleh Visual Basic menjadi XML, lalu file-file XSLT secara otomatis menghasilkan class Java yang menangani action Struts yang didefinisikan di XML tersebut
https://raganwald.com/2008/02/21/mouse-trap.html
Diskusi HN: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952