XSLT - Web için yerel, sıfır yapılandırmalı derleme sistemi

 (github.com/pacocoursey)
2 puan yazan GN⁺ 2025-06-28 | 1 yorum | WhatsApp'ta paylaş
  • XSLT, web tarayıcısında çalışan istemci tarafı derleme sistemi gibi kullanılarak XML verilerini HTML’ye dönüştürebilir ve statik site oluşturucuların karmaşıklığını azaltabilir
  • Tipik bir statik site; .json, .md, .txt gibi verilerden, Hugo, Next.js, Astro gibi derleme sistemlerinden ve statik HTML çıktısından oluşur; ancak büyük framework’ler basit bir Markdown blogu için bile gereğinden fazla karmaşıklık yaratabilir
  • Yalnızca HTML ve CSS kullanmaya çalışırsanız, birden çok sayfanın header ve footer bölümlerini elle kopyalamanız gerekir; HTML import yoktur ve Web Component’ler JavaScript motoru gerektirir
  • Bir XML belgesine <?xml-stylesheet type="text/xsl" href="blog.xsl"?> ekleyip XSLT şablonları yazarsanız, tarayıcı ziyaret anında HTML çıktısı üretebilir
  • Bu yöntem JavaScript olmadan statik dosyalar olarak dağıtılabilir; ancak her şeyin yerini alan kusursuz bir çözüm değildir, web geliştirme araç kutusuna eklenebilecek başka bir seçenektir

Statik site derlemenin karmaşıklığı

  • Tipik bir statik web sitesi üretim akışı; veri, derleme sistemi ve statik HTML çıktısı olarak ayrılır
    • Veriler .json, .md, .txt gibi dosyalarda saklanır
    • Hugo, Next.js, Astro derleme sistemi örnekleridir
    • Nihai çıktı statik HTML’dir
  • Framework’leri kaldırıp yalnızca basit HTML ve CSS kullanmak isteseniz bile, sayfa sayısı arttıkça ortak header ve footer bölümlerini sürekli kopyalamanız gerekir
  • Alternatif olarak akla gelebilecek seçeneklerin her birinin kısıtları vardır
    • HTML import mevcut değildir
    • Web Component’ler JavaScript gerektirir; dolayısıyla bir JavaScript motoru gerekir

Tarayıcıyı derleme sistemi olarak kullanma fikri

  • Web tarayıcısı zaten text/html, text/markdown, application/xml gibi çeşitli formatları anlayabilir
  • Tarayıcıyı veriden HTML üreten bir sistem olarak kullanırsanız, ayrı bir derleme aracı olmadan web standartlarına dayalı bir akış oluşturabilirsiniz
  • RSS feed’lerini daha okunabilir göstermeye çalışırken, XSLT’nin XML belgeleri için stil sayfası olarak kullanılabileceği keşfedildi
  • XML, HTML’e benzer görünse de yalnızca web verileriyle sınırlı olmayan bir veri temsil yöntemidir ve XML spec üzerinden incelenebilir

XML’den HTML’ye dönüştürme yöntemi

  • XML belgeleri blog yazısı gibi verileri taşıyabilir
<?xml version="1.0"?>
<blog>
  <post id="42" publishedAt="2025-06-26">
    <title>Hello XSLT</title>
    <tags>…</tags>
  </post>
</blog>
  • XML belgesine XSL stil sayfasını bağlayan bir bildirim eklenebilir
<?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 şablonu XML girdisini alır ve HTML yapısı çıktılar
<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 biçiminde düşünülebilir ve döngüler, değişkenler, import gibi derleme sistemi özellikleri sağlar
  • Üst XML belgesindeki veriler XSLT içinden alınarak dinamik biçimde çıktılanabilir
<head>
  <xsl:value-of select="title" /> | Blog
</head>

Çalıştırma ve dağıtım yöntemi

  • XML dosyasını tarayıcıyla açarak XSLT dönüşümü çalıştırılabilir
open blog.xml -a Safari
  • Tüm web tarayıcıları sayfa ziyareti sırasında XSLT dönüşümünü destekler ve dönüşüm sonucu oluşan HTML’i gösterir
  • Bu yöntem, kullanıcının bilgisayarında çalışan istemci tarafı derleme sistemi gibi davranır
  • Statik dosya dağıtımı kolaydır ve JavaScript olmadan çalışır

Sınırlamalar ve konumlandırma

  • Blog verilerini JSON yerine XML olarak saklamak gerekir; ancak XML, HTML gibi görünür, ayrıştırması kolaydır, esnektir ve web’de yerel olarak desteklenir
  • XSLT yöntemi kusursuz değildir ve her şeyin yerini almaz
  • Eski web standartlarından, spesifikasyonlardan ve tarayıcı özelliklerinden yararlanarak basit statik web siteleri üretmek için kullanılabilecek başka bir araç hâline gelir

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-28
Hacker News yorumları

  • XML şablonlarında XSLT’yi yoğun kullanan bir şirkette çalışmıştım; iyi değildi ve mümkün olsaydı muhtemelen başka bir şeye geçerdik.
    Yeni standartlar olsa da XSLT 1.0 hâlâ baskın ve daha yeni standartlara kıyasla sınırlı ve tuhaf.
    XSLT şablonlarındaki performans sorunlarını çözmek cehenneme yakın. Turing-tam, fonksiyonel tarzda bir dil ama performans büyük ölçüde soyutlanmış durumda; çoğu belgede düzgün çalışan bir şablon, 100 satırlık tek bir tabloda patlayabiliyor. Meğerse tablo işleme şablonu O(N^2) ya da daha kötüymüş; her satırda XPath ayrıca O(N) ya da daha kötü olabiliyor ve nasıl optimize edileceği de pek belli değildi. Hatırladığım kadarıyla tek bir belgeyi XSLT ile işlemek 7 dakikadan uzun sürmüştü.
    JS’in başka sorunları olabilir ama algoritmik karmaşıklık sorunlarını çözememek bunlardan biri değil.

    • XSLT/XPath, XSLT 1.0’dan sonra gelişti.
      Artık key (indeks) gibi özelliklerle işlemeyi ciddi ölçüde hızlandırabiliyorsunuz; Saxon gibi iyi XSLT uygulamaları da performans açısından kesinlikle yardımcı oluyor.
      XML’i başka biçimlere dönüştürürken mantığı yapılandırabildiği için XSLT oldukça kullanışlı.
    • “XSLT 1.0 hâlâ baskın” derken bunun nerede geçerli olduğunu bilmiyorum.
      2013’te XSLT’yi yoğun kullanıyordum; o zaman bile 1.0 her açıdan tamamen ölmüş durumdaydı. Saxon, XSLT 2 için ücretsizdi ve harikaydı.
      Hem devasa belgeleri hem de çok sayıda küçük belgeyi dönüştürdük ama hiç performans sorunu yaşamadık.
    • XSLT kolay değil. Benzetmek gerekirse halüsinojen mantar yemiş Prolog gibi; öğrenme eğrisi dik.
      Alışınca Sudoku çözmüş gibi bir tatmin veriyor ama genellikle hedefe ulaşmak için çok daha az araç yeterli olduğundan, build ya da şablonlama için standart yaklaşım olması zor.
      Üstelik XML de herkesin sevdiği bir format değil.
    • XSLT, uzun kaynak XML’leri işlemenin olağan kabul edildiği bir dönemde yapılmış gibi duruyor; iç içe döngülerin patlaması ise fazla bariz göründüğü için tuhaf.
    • Saxon’un ticari sürümünü kullanıp kullanmadığınızı merak ediyorum. Pahalı değil ve desteklediği özellikler ile performansı düşününce değerli olduğunu düşünüyorum.
      Yanlış hatırlamıyorsam epey akıllı optimizasyonlar da yapıyordu.

  • Epey zorlama bir tahmin olabilir ama 1990–2000’lerde tarayıcılar birbirinden çok farklı olduğu için aynı davranışı elde etmek adına JS kullanmaya başladık; aslında ihtiyaç duyulan şey iyi CSS stilleri ve tutarlı davranıştı.
    Zamanla tarayıcılar benzer davranmaya başladı ama biz zaten sayfaları tüm tarayıcılarda aynı gösteren framework’lere alışmıştık ve JSON verisini render etme paradigmasına geçmiştik.
    Bugünkü teknoloji seviyesiyle sunucunun ürettiği eski usul web sayfaları da gayet kaldırılabilir; ayak izi daha küçük, daha hızlı ve daha az bellek kullanıyor.
    Yakın zamanda bir legacy sistem geçişi yaparken 2000’ler tarzı “her HTTP isteğine bir sayfa” yapısını gördüm; ekleme/silme gibi tüm işlemler yenileme gerektirse bile React sisteminden çok daha hızlıydı. İnternet hızlandı, telefon belleğini JS framework’leri israf ediyor ve backend hâlâ çoğunlukla CRUD, sayfalama ve transaction’lardan ibaret.

    • AJAX ve DOM güncellemeleri yalnızca “daha hızlı” yapmak için gelmedi; belge gösteren web sitesi/web belgesi paradigmasını değiştirmek için geldi.
      HN gibi basit yerlerde tam sayfa yenileme iyi uyuyor; JS framework yerine basit bir web sitesinin yeterli olduğu pek çok örnek de var.
      Ama herkesin tam sayfa yenilemeye dönebileceği doğru değil. Gerçek web uygulamaları arasında tam yenilemenin berbat bir kullanıcı deneyimi yarattığı durumlar var.
      Genel olarak web siteleri, web belgeleri ve web formları tam yenilemeyle yapılabilir; ancak karmaşık şeyleri gösterip manipüle etmesi gereken web uygulamaları için uygun değil.
    • Bence o zaman çizelgesi doğru değil. JS, davranışı standartlaştırmaktan çok başlangıçta etkileşimlilik için kullanılıyordu; DHTML ve sonrasındaki AJAX bunun örnekleriydi.
      O dönemde düzeni tutturmak için user agent algılamasına ve türlü quirks sıralarına bel bağlanırdı; JS’in düzenle ilgili öğelere kolayca erişebildiğini de sanmıyorum.
      CSS de tutarlılığı hemen getirmedi. Özellikler tamamlandıktan sonra bile ortalık karışıktı; herkes CSS Zen Garden’a hayran kalırken gerçek kodların tablolarla yazıldığı dönemdi.
      Framework’lerin “tutarlı görünüm” üzerinde büyük etkisi olup olmadığından da emin değilim. jQuery’den uzaklaşmaya başladığımız sıralarda görünüm zaten CSS’in işiydi.
    • .NET/Kestrel/SQLite stack’iyle sunucu tarafı render yanıtlarını en fazla yaklaşık 4 milisaniye içinde üretebiliyorum. Release build’de ortalama yanıt süresi yüzlerce mikrosaniye seviyesinde.
      Her sayfa için birden çok sorgu çalıştırılan ve görünüme özel yanıt biçimleri oluşturmak için çok sayıda karmaşık join kullanılan koşullardan bahsediyorum. HTML string’ine interpolate etmeden önce veriyi doğru biçimde getirirseniz, 100 bin satırlık tablo gibi uç durumlarda performansa büyük faydası oluyor.
      Deneyimime göre HTML şablon motoru ile veritabanı ne kadar yakınsa o kadar iyi. Sonuçta yapılandırılmış DOM da istemciye gönderilmesi gereken bir byte akışından ibaret.
      StringBuilder ve akıllı SQL sorgularının yeterli olduğu yerlerde sofistike AST/parser yaklaşımları düşünülürken anlamsız ve kendi kendini amaç edinen bir endüstri oluştuğunu düşünüyorum. Karşı argüman genelde geliştiricilerin HTML escape fonksiyonunu düzgün kullanamayacağını varsayan güvenlik denetçisi tavrına varıyordu.
    • Mevcut teknolojiyle sunucu tarafından üretilen eski usul web sayfalarının kaldırılabileceği iddiasının yüksek gecikmeli internet bağlantıları için istisnası var: https://news.ycombinator.com/item?id=44326816

  • 2000’lerde kurumsal XML’in hantallığı yüzünden teknolojinin eski görünmesi ve herkesin daha “temiz” JSON’a yönelmesi üzücü.
    XSLT ve XPath çok olgunlaşmıştı ve başka biçimlerde hâlâ yaşanan birçok sorunu çoktan çözmüştü.
    Eskiden PHP stream wrapper’larını ve XSLT include’larını suistimal ettiğim güzel anılarım da var.
    Eski bir önyargı olabilir ama tarayıcının yerelde işlemesine izin vermek hâlâ biraz tedirgin ediyor. Çünkü eskiden uyumluluk tam bir mayın tarlasıydı.

    • Eski olsa da JSON’da XML’in bazı “temel” şeylerini hâlâ özlüyorum. Her şeyden önce doğru düzgün bir standartlaştırma kuruluşu vardı.
      XML tarafındaki şema gibi şeyler çok daha iyi tanımlanmıştı; JSON tarafının yetişmesi neredeyse 10 yıl sürdü gibi geliyor.
      En son ciddi biçimde uğraştığım XML teknolojisi EXI idi; XML belgelerini sıkıştırılmış ikili veri akışına dönüştüren bir aktarım biçimiydi. Çünkü veri yapısını ASCII’ye çevirip sıkıştırarak HTTP üzerinden göndermek ve sonra geri çevirmek biraz komik bir iş.
      Şimdi protobuf ailesi daha popüler ama XML varlığını sürdürseydi, birbirine geçen uyumlu standartların dünyası haline gelebilirdi. Buna karşılık protobuf/gRPC ile JSON API’leri arasında sağlam bir duvar var; belki de bu daha iyidir, kim bilir.
    • XML fena değil. Biraz uzun yazdırıyor ama YAML’a kıyasla kesinliği ve ifade gücü hoşuma gidiyor.
      XPath de kötü değil. Söz diziminin tamamını hatırlamak zor ama biraz deneme yapınca genelde istediğiniz yere ulaşıyorsunuz.
      XSLT ise tamamen delice bir saçmalık; yanıp yok olmalı.
    • Rimworld oyunu tüm oyun yapılandırma verilerini XML’de tutuyor ve modlama için XPath kullanıyor; gerçekten çok iyi.
      Veride nispeten kararlı yerel değişiklikleri mümkün kılan bir kombinasyon olarak XML + XPath ciddi biçimde hafife alınıyor. XML’in “eski moda” ünü yüzünden mi bilmiyorum, başka oyunlarda pek görmedim ama bu kullanım için çok sağlam bir sistem.
      https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
    • XML aslında SGML’in basitleştirilmiş bir alt kümesiydi; web’de işaretleme taşımak ve tarayıcının işaretleme sözlüğünü ve yeteneklerini geliştirmek amaçlanıyordu.
      Ama web furyası büyüyünce W3C ve MS SOAP, WS-* gibi şeyler geliştirdi; XSLT dâhil XML tabanlı birkaç programlama dili de ortaya çıktı.
      HN’deki insanlara söylememek gerek ama XSLT aslında Scheme’di, yalnız mutlaka XML olmak zorundaydı; JavaScript’in Java adını ödünç almak zorunda kaldığı aynı çılgınlık dönemiydi.
    • XPath’te her sorgunun her bölümüne namespace’leri titizlikle eklemek zorunda kalmasaydık iyi olurdu.

  • Bu aralar feed’leri süslemek için XSLT kullanıyorum.
    Örneğin https://susam.net/feed.xml ve https://susam.net/feed.xsl.

    • Bunu görünce, bir blogun neden doğrudan RSS feed’i olamayacağını düşünmeye başladım.
    • XML’in böyle şeyler yapabildiğini hep unutuyorum. Nedense garip geliyor.
    • Aynı şekilde yapıyorum: https://adithyanair.com/feed.xml

  • 19 yaşımda profesyonel yazılım mühendisi olarak ilk üstlendiğim projelerden biri, şirketin satın aldığı iki Google Search Appliance cihazını özelleştirmekti.
    Şirket, devasa CIFS belge deposunda tam metin arama yapabilmenin iş geliştirme sürecini iyileştireceğini düşünerek, CentOS ve Google tarzı Python çalışan sarı ön panelli Dell sunucu raflarına yüz binlerce dolar harcamıştı.
    2011 civarında XHTML modaydı ve GSA, arka uçta XML olarak sağladığı arama sonuçlarını XSLT ile XHTML’e dönüştürüyordu.
    Varsayılan şablonları alıp render edilmiş ColdFusion uygulama sayfalarından, StackOverflow’dan ve W3Schools eğitimlerinden çaldığım varlıklar ve işaretlemeyle şirket intranet portalına benzeyen bir canavar oluşturdum.
    Sonrasında LinkedIn’de birçok DoD yüklenicisi “XML uzmanlığımı” görüp belge modernizasyonu projelerine katılmam için bana ulaştı; bu deneyimi özgeçmişimden çıkarmam gerektiğini çabucak öğrendim.
    JSON yanıtından deserialize edilmiş TypeScript arayüzleri dizisini JSX içinde döndürürken iç çektiğinizde, aynı işi XSLT ile yapan beni hatırlayın.

  • Birçok kişi XML’in uzun yazdırmasından şikâyet ediyor ve uzaktan bakınca karmaşık görünüyor; ama XML tabanlı iyi dosya biçimleri oluşturup bunları DTD ile doğrulayabilmek, gerekirse XSLT ile insan tarafından okunabilir biçimde formatlayabilmek hoşuma gidiyor.
    XML, metin tabanlı dosya biçimlerinin C++’ı gibi. Olgun, pilleri dâhil geliyor, güçlü ve isterseniz her dilde kullanabiliyorsunuz.
    Eski ve olgun diller nasıl kendi tuhaflıkları yüzünden eleştiriliyorsa, XML’i kötülemek de moda oldu. Amacınıza uygun değilse kullanmazsınız; ama canavar muamelesi yapmak gerekmiyor.

    • Neden XSD değil de DTD kullandığınızı merak ediyorum.

  • 2000’lerin başında XML ve XSLT’nin ne kadar ileri gittiğine bir örnek olarak, eskiden çalıştığım şirket XML’i hat hızında ayrıştıran ve XSLT’yi çip üzerinde yerel olarak işleyen bir ASIC yapmıştı.
    Çünkü internetin geleceğinin tamamen XML/XSLT olacağını öngörmüşlerdi. Intel o şirketi satın aldı ve iç teknoloji SSE hızlandırıcısına girdi.

    • O yoldan gidilseydi web sitelerinin ne kadar hızlı render edileceğini hayal ediyorum.
    • IBM hâlâ bu açıklamaya aşağı yukarı uyan bir donanım olan DataPower Gateway’i satıyor.

  • “XSLT tarayıcıda yerel olarak çalışıyor” sihrinin ne olduğuna şaşırıyorum
    XSLT’yi en son yaklaşık 20 yıl önce kullanmıştım ama o dönem birkaç yıl boyunca çok yoğun kullanmıştım. O zamanlar çalıştırmak için devasa ve sallantılı bir kurumsal Java kulesi gerekiyordu; bu da XSLT’nin kendi zarafetini gölgeliyordu
    Ama XSLT gerçekten tarayıcıda çalışıyorsa, her yerde barındırılabilen statik şablonlar gibi bir kutsal kâse zaten hep burnumuzun dibindeymiş demektir

    • Tarayıcılar yalnızca XSLT v1.0 destekliyor ve duyduğuma göre kullanımdan kaldırılması da konuşulmuştu
      Keşke v3 desteği gelse; yerel şablon desteğiyle statik web sayfaları sunmak kolaylaşırdı
    • “Devasa ve sallantılı bir kurumsal Java kulesi” denecek kadar değildi. Tomcat ve birkaç Apache kütüphanesiyle gayet iyi kullanıyorduk
      CMS, içinde gömülü HTML bulunan XML dosyaları üretiyordu ve bunlar çok iyi önbellekleniyordu. Kişiselleştirme ve HTML/JS render işlemleri sunucu tarafında, önbellekleme proxy’siyle birlikte ele alınıyordu
      XSL dönüşümü önbelleğin arkasında çalışıyordu ve yüksek trafiğe yetişecek kadar hızlıydı. Burada XML’in amacı, hazır HTML’i blob olarak koymak ve yalnızca kişiselleştirme gereken kısımları XML etiketi olarak bırakmaktı
      Son dönüşüm epey hızlıydı; kilit nokta, XSL dönüştürücüsünün çıktısını tümüyle bellek tamponuna almak yerine doğrudan yanıt çıktı akışına akıtmaktı. Büyük yanıtlarda bugün bile iyi bir teknik; birçok framework varsayılan olarak bellekte tamponlamayı seçtiği için kaçırılan bir nokta
      Bugün elbette wasm ile tarayıcıda istediğinizi çalıştırabilirsiniz. Ama o dönemde JavaScript berbattı ve tasarımcılar en iyi ihtimalle Photoshop dosyası teslim ediyordu. Onu frame’lere ve table’lara bölmek gerekiyordu; Google Maps ve Gmail’in yeni çıktığı dönemde, hem Netscape’i hem Internet Explorer’ı destekleyerek oldukça JavaScript-heavy bir CMS arayüzü yapıyorduk
    • 2008’de tarayıcıda XSLT kullanan bir siteyle ilgilenmiştim; desteğin kendisi 2000’lerin başına kadar gidiyor gibi görünüyor
    • XSLT çalışıyor ama tarayıcıların hepsi eski bir spesifikasyon sürümüne takılı kalmış gibi
      Firefox’ta özellikle can sıkıcı bir bug var: Belge içindeki HTML’i gerçek DOM olarak render etmek için disable-output-escaping gerektiğinde düzgün çalışmıyor ve ham HTML metni olarak render ediliyor
    • Kurumsal Java kulesine ihtiyaç duyulduğunu anlamıyorum. classic ASP’de VBScript’in yaklaşık üç satırıyla XML dönüştürüyorduk

  • Uzun zaman önce, çok uzak bir distopik projede, ekibin Java geliştirmeyi hızla değişen workbook’larla paralel şekilde koordine edemeyeceği konusunda karamsar olan biri bir çözüm bulmuştu
    Excel’de hazırlanmış workbook’u Visual Basic XML’e dönüştürüyor, XSLT dosyaları da bu XML’de tanımlanan Struts action’larını işleyecek Java sınıflarını otomatik üretiyordu
    https://raganwald.com/2008/02/21/mouse-trap.html
    HN tartışması: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952